The Median Leaked AWS Key Was Five Years Old. It Still Worked.
A cloud access key can be discovered in a public repository within minutes. The more consequential question is how long it remains useful after that exposure.
New research from Truffle Security says the answer is often measured in years. The company re-checked 64,024 unique AWS keys found in public code, container images and datasets. It says 88 percent were still active, the median leaked key had been active for five years and only 14 percent had ever been rotated.
Among the subset Truffle Security could examine closely, 84 percent had full administrator access and one in six was a root key. Those figures describe different denominators and should not be collapsed into a claim that 84 percent of all 64,024 keys were administrators. Even with that limitation, the findings point to a serious identity-management failure: organisations are letting long-lived machine credentials survive both public exposure and years of opportunity to remove them.
The failure is persistence, not discovery
Security teams have spent years adding secret scanners to source-control workflows. That is useful, but discovery is only the first stage of incident response. Removing a credential from the latest commit does not invalidate the copy preserved in Git history, a fork, a package, a container layer, a cached build or a public dataset.
An AWS access key remains valid until it is disabled or deleted. Unlike temporary credentials issued through an IAM role, a long-term key does not expire automatically. If a team cleans the repository but leaves the identity active, the security finding disappears from the visible code while the attacker opportunity remains.
The reported five-year median is therefore more important than the raw number of exposed keys. It suggests that many organisations do not have a closed-loop process connecting detection, ownership, revocation, investigation and verification.
A warning did not always become a revocation
Truffle Security says 929 keys in its research had been flagged by AWS’s compromised-key quarantine policy. Some had carried that status for more than three years, yet all 929 still authenticated.
A quarantine policy can restrict a key’s capabilities and create a strong signal for the account owner. It should not be interpreted as automatic disposal of the credential. AWS’s own support guidance tells customers to delete an exposed access key as soon as possible and investigate the account for unauthorised activity.
The gap between a platform warning and the customer’s final remediation is a governance problem. Somebody must own the identity, understand the workload that depends on it, replace it safely, revoke the exposed value and confirm that the old key no longer works. Without that ownership chain, a warning can become a permanent exception.
A leaked key inherits the permissions behind it
A secret does not have an independent severity. Its risk comes from the identity it represents, the policies attached to that identity and the paths available from the initial permissions.
A narrowly scoped key for one object in one storage bucket has a different immediate impact from a root key or an administrator identity. A key that can modify IAM policies, create access keys, assume roles or change logging can also turn apparently limited access into persistence and wider control.
This is why prioritisation based only on the presence of an AWS key is incomplete. Responders need to know which account issued it, whether it is active, what it can access, when it was last used, which trust relationships it can traverse and whether recent API activity matches the workload’s normal behaviour.
Public AI data has widened the search surface
Source repositories are no longer the only obvious place to look. Truffle Security says a separate scan of 7.6 petabytes of public AI training data on Hugging Face found 3,343 live AWS keys. More than 900 could list S3 buckets containing at least 51.7 terabytes of non-public data.
Datasets can preserve secrets from source code, configuration files, logs, notebooks, archives and synthetic data pipelines. Once the material is incorporated into a public corpus, deleting the original repository may not remove the copies that other people have already downloaded or mirrored.
That changes the defensive assumption. Exposure monitoring has to cover the places where development artefacts are republished, not only the system where they were first created.
The research is also a product launch
The figures were published alongside the launch of TruffleHog AWS Analyze, a commercial capability that adds permission and access context to discovered credentials. That does not make the findings irrelevant, but it does make methodology and denominators important.
The company explains where the keys were found and gives several aggregate results, but the public announcement does not provide a complete independent dataset or enough detail to reproduce every percentage. The administrator and root figures explicitly apply to keys examined closely, not necessarily to the full set.
Security leaders should use the research as a prompt to test their own estate rather than as a universal prevalence estimate. The measurable question is straightforward: how many long-term AWS credentials does the organisation have, how many are exposed, how many are overprivileged and how quickly can each one be made unusable?
What AWS customers should do
- Delete exposed keys, then investigate. Treat any public secret as compromised. Disable or delete it promptly, preserve the relevant evidence and review CloudTrail and other account telemetry for use that cannot be attributed to the legitimate workload.
- Search beyond the current repository. Include Git history, forks, CI logs, build artefacts, container layers, packages, object storage, public datasets and internal collaboration systems. A clean default branch is not proof that the secret is gone.
- Replace long-term keys with temporary credentials. AWS recommends IAM roles and temporary credentials for both people and workloads wherever possible. Expiring credentials reduce the useful lifetime of a copied value and avoid distributing a permanent secret.
- Remove root access keys. A root key grants account-wide authority and should not exist for routine operations. Protect the root user, require phishing-resistant multifactor authentication and use delegated identities for administrative work.
- Measure effective permissions. A key’s attached policy is only part of the picture. Examine role-assumption paths, resource policies, permissions boundaries and organisation-level controls to understand what the identity can actually reach.
- Close the remediation loop. Record an owner, deadline and verification step for every exposed credential. The incident is not complete until the old key fails authentication and any unauthorised activity has been scoped.
A secret scanner cannot expire a credential
The most uncomfortable part of the research is not that credentials reached public systems. Organisations already know that developers, pipelines and datasets can leak secrets.
The uncomfortable part is that many of the exposed keys reportedly remained valid for years, sometimes with enough privilege to control the account behind them.
Detection without revocation is an alert, not a control. The durable fix is to reduce the number, lifetime and authority of long-term credentials, then prove that every exposed key has stopped working.
