Notifications
Clear all
Topic starter
21/08/2026 4:44 pm
TL;DR: A re-verification of leaked AWS key pairs found 768 live corporate keys with full control of AWS accounts, including 526 root keys and 242 IAM users with AdministratorAccess, according to TruffleHog. The median live leaked key was five years old and 86% of enumerated keys were never rotated, showing that leaked NHI credentials remain an active governance failure.
NHIMG editorial — based on content published by TruffleHog: 768 Leaked Corporate AWS Keys Held Full Admin Rights
By the numbers:
- The median live leaked key was created 1,831 days ago.
- Only 13.7% of the keys where access keys could be enumerated had any newer key alongside the leaked one.
Questions worth separating out
Q: What breaks when a leaked AWS key is still active?
A: When a leaked AWS key is still active, the compromise is no longer about disclosure alone.
Q: Why do old AWS keys create such high risk for cloud teams?
A: Old keys are risky because age is a proxy for forgotten ownership, weak rotation discipline, and wider public exposure.
Q: How do security teams know if AWS key rotation is actually working?
A: Rotation is working when old keys disappear, replacement keys are issued quickly, and no credential remains live without a clear owner and business purpose.
Practitioner guidance
- Delete root access keys immediately Inventory every AWS account and remove any root access key that still exists.
- Sort NHI secrets by age and rotate stale keys first Build a review queue that prioritises keys older than your accepted maximum age, because long-lived credentials are the ones most likely to have escaped into public corpora and forgotten environments.
- Turn AWSCompromisedKeyQuarantine into an operational trigger Feed quarantine policy events into incident response, ownership validation, and credential replacement workflows so that exposure signals result in actual cleanup rather than passive alerting.
What's in the full report
TruffleHog's full research covers the operational detail this post intentionally leaves for the source:
- How TruffleHog re-verified 10,616 leaked AWS keys across public repositories, datasets, images, and CI logs
- The method used to classify live keys by principal type, policy attachment, and account ownership
- The account-level reach analysis that shows what a leaked key can do inside AWS
- The re-verification and notification workflow for identified owners
👉 Read TruffleHog’s research on 768 leaked AWS keys with full admin rights →
Leaked AWS keys with admin rights: what should teams do now?
Explore further
21/08/2026 5:04 pm
Leaked cloud credentials are not just secrets exposure, they are standing non-human identities. Once an AWS key is public and still authenticates, it behaves like an unmanaged NHI with unbounded lifecycle risk. That shifts the governance question from where the secret was stored to whether the identity was ever brought under lifecycle control. Practitioners should treat leaked keys as identities that escaped governance, not as isolated security incidents.
A few things that frame the scale:
- Only 13.7% of the keys where access keys could be enumerated had any newer key alongside the leaked one, according to The State of Non-Human Identity Security.
- Lack of credential rotation is cited as the top cause of NHI-related attacks by 45% of organisations, followed by inadequate monitoring and logging at 37%.
A question worth separating out:
Q: Who is accountable when an exposed AWS key is used for extortion?
A: Accountability usually spans application owners, cloud platform teams, and identity governance teams because the failure sits at the intersection of deployment practice and access control. NIST Cybersecurity Framework 2.0 helps structure the response across identify, protect, detect, respond, and recover. The practical question is whether the organisation can prove who owned the secret and how quickly it was revoked.
👉 Read our full editorial: 768 leaked AWS keys show full admin rights still persist
