What Should Your Team Do in the First Hour After an AWS Access Key Leaks?

In the first hour: name an incident owner, identify the key and the principal it belongs to, deactivate it rather than deleting it, revoke any temporary credentials already issued from it, and preserve CloudTrail evidence before you change anything else. Then work out what the key did, replace it with role-based credentials where you can, and write down every action and timestamp. Rehearse this before it happens, because the person who can disable the key at 2 a.m. may not be the person who wrote the runbook.

Static AWS credentials leak in ordinary ways: a repository, a build log, a contractor's laptop, a shared chat thread. The clock matters because long-term access keys for IAM users and the root user remain valid until you manually revoke them. Nothing expires on its own. The first hour is about stopping use of the key without destroying the evidence you need to learn what it did.

This guide gives a practical sequence based on AWS documentation, with notes on what to rehearse. It does not replace your incident response plan. It is a starting template for the credential-exposure scenario, which is one of the easiest to tabletop and one of the most common to get wrong under pressure.

Step 1: Declare the incident and identify the key

Assign one incident owner and open a running log: who noticed, when, and where the key was exposed. Then establish what the key is. IAM access keys for users begin with the prefix AKIA, and temporary security credentials begin with ASIA. If a key appears in code or a ticket and you do not know which account issued it, AWS documents that you can pass the access key ID to the GetAccessKeyInfo operation to learn which account it belongs to. If it is yours, a credentials report shows which IAM user owns it, and the GetAccessKeyLastUsed API shows when and where it was last used.

Step 2: Contain without destroying options

AWS's security incident response guide notes that a compromised access key can be deactivated or deleted. It also lists the differences that matter in an emergency: a deactivated key can be reactivated, while a deleted key is not recoverable, and anything using the key loses access either way. Our recommendation, which is a judgment call rather than an AWS requirement, is to deactivate first. That stops use, keeps the key record for investigation, and lets you restore a production workload quickly if you deactivated the wrong key. Delete it once you have confirmed the replacement and finished your review.

Check for temporary credentials as well. Temporary credentials issued to roles expire on their own, but if an attacker used a compromised user key to create temporary security credentials, the guide describes two options for revoking them: attach an inline policy to the IAM user that denies access based on the token issue time, or delete and recreate the user. Decide in advance who is allowed to do that, because both actions disrupt something.

Step 3: Preserve and read the evidence

CloudTrail is your record of what the key did. Its Event history gives you a searchable, immutable record of the past 90 days of management events in an AWS Region, and it does not show data events such as object-level access to storage. For a longer or fuller record, AWS recommends creating a trail or event data store. That has an uncomfortable implication: if no trail was configured before the leak, you may be unable to answer what the key read or copied. Export the relevant events early, and confirm during rehearsal that a multi-Region trail exists and where its logs are retained.

Then look for what an attacker would do next. AWS Support's guidance on exposed access keys says to check each service console for suspicious resources, with particular attention to running EC2 instances, Spot Instance requests, access keys, and IAM users. Add new roles, changed policies, and disabled logging to your list. For temporary credentials with the ASIA prefix, AWS notes you can view the related STS events in CloudTrail to learn who requested them.

Step 4: Replace, then remove the cause

Do not simply issue a new long-term key to the same workload. AWS recommends that workloads use temporary credentials delivered through IAM roles rather than long-lived IAM user credentials, and describes options for workloads running outside AWS. Where you truly need long-term keys, for example for some third-party clients, AWS recommends updating them when needed and using last-used information to remove them safely. Also rotate any secrets the leaked key could read, since access to a secrets store turns one leak into many.

Step 5: Record, report, and learn

Write down each action with a timestamp and the person responsible, since your regulators, insurers, or customers may ask for the sequence later. If the exposure may touch covered defense information, DFARS 252.204-7012 requires you to rapidly report a cyber incident to DoD, meaning within 72 hours of discovery, and to preserve images of affected systems and relevant monitoring data for at least 90 days from submission of the report. Other obligations depend on your sector and contracts. Our write-up of GitHub workflow secret exposure covers how secrets stored in workflows and credentials in Git history are exposed, and what to revoke and review.

A 60-minute tabletop checklist

• Who is authorized to deactivate an access key at any hour, and do they have the permissions today?
• Can we list every long-term access key in the account, its owner, and its last-used date within minutes?
• Which workloads would break if the most privileged key were deactivated, and who owns them?
• Is a multi-Region CloudTrail trail enabled, and for how long are its logs retained?
• Can we find keys committed to our repositories or pasted into build output?
• Which vendors or contractors hold keys to our account, and how do we revoke them?
• Who decides whether to disrupt production to revoke temporary credentials?

Our guide to Microsoft 365 incident logs makes the same point about log retention for another platform: the evidence you need must exist before the incident.

Where managed security fits

A managed provider can watch for the signals around a leaked key, help you design the revocation runbook, and run the tabletop. Cyberuptive's managed AWS security and incident response services are starting points, and your own leaders keep the decisions on production impact.

Frequently asked questions about leaked AWS access keys

What should you do first when an AWS access key leaks?

Name an incident owner, identify the key and its IAM principal, deactivate the key, and preserve CloudTrail evidence. Deactivation stops use and can be reversed, while deletion cannot, so many teams deactivate first and delete after confirming a replacement.

Should you deactivate or delete a compromised access key?

AWS documents that a deactivated key can be reactivated and a deleted key is not recoverable. Deactivating first stops use while preserving the record and your ability to restore a workload if you chose the wrong key. Delete it once the investigation and replacement are complete.

How long do leaked AWS access keys stay valid?

Long-term access keys for IAM users and the root user remain valid until you manually revoke them. They do not expire on their own, which is why exposure response matters.

How long does CloudTrail keep the evidence?

CloudTrail Event history covers the past 90 days of management events in a Region and does not show data events. For a longer or fuller record, you need a trail or event data store configured in advance.

What if the attacker already created temporary credentials from the leaked key?

AWS describes two ways to revoke them: attach an inline policy to the IAM user that denies access based on the token issue time, or delete and recreate the IAM user. Decide in advance who may do this, since both actions disrupt workloads.

How can we avoid long-term access keys in the first place?

AWS recommends that workloads use temporary credentials from IAM roles rather than long-lived IAM user keys, with alternatives for workloads outside AWS. Where long-term keys are unavoidable, update them when needed and remove unused ones using last-used information.