A Leaked AWS Key Is Only the Start of the Incident

A secret scanner can tell you that an AWS access key escaped. Detection alone does not revoke the key.

That distinction matters because persistent IAM access keys do not expire after a session. They remain valid until somebody disables or deletes them. If ownership is unclear or a team is afraid of breaking an unknown dependency, detection can produce an alert without producing revocation.

Truffle Security tested 10,616 complete AWS key pairs again after they had appeared publicly between August 2022 and August 2026. On August 10, 2026, 9,308 of them, or 88%, still authenticated.

The uncomfortable part is not only that the credentials leaked. It is how long many of them stayed usable and how much authority some retained.

What the active keys could do

For 2,903 active keys that allowed iam:ListAccessKeys, AWS returned exact creation dates. The median was 1,831 days: just over five years. Only 25 had been created in the previous 30 days, and just 13.7% had a newer access key attached to the same IAM user.

That measures age since creation, not time since exposure.

The permission data raised the stakes:

1. Truffle Security classified 817 active keys as linked to businesses.
2. Of those, 526 were root access keys.
3. Another 242 belonged to IAM users with AdministratorAccess.
4. Those sets did not overlap, so 768 keys provided full control of a company AWS account.
5. The study also identified 130 active root keys belonging to AWS Organizations management accounts.

AWS strongly recommends not creating access keys for the root user. A root key is not merely an old credential with broad permissions; it authenticates as the identity with full account access.

The median comes from the 2,903 keys with known creation dates; the 768 figure describes corporate account control. Read them as separate findings about persistence and blast radius, not a measured median age for the corporate admin keys.

Why quarantine is not revocation

The research also found 929 active IAM users with the AWSCompromisedKeyQuarantine policy attached. AWS had identified those credentials as exposed and restricted them, but the credentials still authenticated.

For 112 users, the attached policy was the original version that AWS stopped applying in 2023. That indicates they had been flagged at least three years earlier.

A quarantine policy can reduce what a credential can do. Someone still has to identify its owner and legitimate consumers, decide whether a replacement is needed, coordinate consumer changes, and confirm revocation.

Without an assigned owner for that work, the alert can sit in a queue while the authentication path remains available.

Credentials without automatic expiry make drift durable

Traditional IAM access keys are persistent credentials. AWS states that they remain valid until manually revoked. Temporary credentials obtained through IAM roles or AWS STS have a defined session lifetime and expire automatically.

That difference changes the failure mode.

A temporary session eventually becomes unusable even if nobody remembers it. A persistent key can survive the application, experiment, developer, pipeline, or account structure that originally justified it. Organizational change removes the surrounding context without removing the credential.

Rotation can limit the age of one credential value, but it does not establish whether the IAM user should exist, whether the permissions remain appropriate, or whether the old value was actually revoked. The AWS Config access-keys-rotated rule uses 90 days as its default maximum age, but a calendar cannot map dependencies or prove removal.

Copies outlive the original file

The same research found 8,482 unique live AWS keys across 3,394 public Hugging Face datasets. Public repositories are only one propagation path. Snapshots of source code can be copied into training datasets, images, archives, forks, caches, registries, and downstream projects.

Deleting the original line does not restore secrecy. Once a credential has been public, the safe response is to assume it has been copied and revoke it.

This is why discovery and lifecycle management are separate controls. Scanning tells you where a credential appeared. Lifecycle ownership determines whether the credential behind that copy is still valid and who must remove it.

Make the response verifiable

An exposed key is compromised, not merely overdue for routine rotation. Coordinate containment, revocation, consumer recovery, and activity review. Completing a migration must not become an automatic prerequisite for disabling the exposed key.

Establish scope

Resolve the IAM identity, permissions, owner, known consumers, expected activity, and affected accounts. Root keys and users with administrator access deserve immediate attention because their authority spans the account.

Contain and revoke

Prioritize restricting access and disabling or deleting the exposed key. Coordinate the availability impact with the workload owner. Neither a quarantine policy nor removal of the public file is evidence of revocation.

Restore legitimate consumers

For consumers that still need access, prefer a role, workload identity, federation, or STS session where the architecture allows temporary credentials. Create a replacement persistent key only when necessary, and verify that each workload uses the intended identity.

Verify and investigate

Verify that the exposed key no longer authenticates, and review its activity and permissions. Revocation removes this authentication path; it is not proof that every consequence of the exposure has been resolved.

A practical control set

The broader program is not “scan harder.” It connects preventive, detective, and lifecycle controls:

1. Prefer temporary credentials for people and workloads.
2. Remove root access keys from every account, including old development, sandbox, and management accounts.
3. Inventory every persistent key that remains.
4. Give each key a named owner and an explicit review or rotation deadline.
5. Apply least privilege instead of granting administration across an entire account.
6. Scan repositories, CI/CD systems, images, registries, and datasets for exposure.
7. Complete routine rotation only after the replacement works and the old key is disabled or deleted.

The central review question is not only “Has this key leaked?” or “Is this key older than 90 days?” It is also:

Why does this credential still exist, and what evidence will let us remove it?

A leaked credential is a security incident. A credential that remains active for years after exposure is also a lifecycle failure.

Originally published on TokenTimer.