The AWS key you leaked years ago probably still works
If your business runs anything on Amazon Web Services, and most that build software now do, there is a fair chance that somewhere out there is a key to it that you have forgotten. A developer pasted it into a script years ago. A contractor committed it to a repository. It ended up in a Docker image, a log file, or a training dataset. You may never have known, and here is the uncomfortable finding: if it leaked, it is probably still working.
What the researchers found
Truffle Security scanned the public internet for exposed AWS access keys, the username-and-password pair that lets code, or a person, control an AWS account. They found 64,000 unique keys sitting in places they should never have been: old code, git history, public datasets, container images, and continuous-integration logs. Then they did the part that matters. They took the keys they could fully verify and checked whether they still worked. Eighty-eight percent of them still authenticated.
Not eighty-eight percent had leaked recently. The opposite: the median leaked key was around five years old, and the oldest was over 17 years. These are not fresh mistakes. They are old mistakes nobody ever cleaned up, still live, still valid, years after they escaped.
The severity climbs from there. Among the corporate keys, 526 were root keys, the master credential for an entire AWS account, and 242 belonged to accounts with full administrator rights. A single one of those gives an attacker complete control: read or delete all your data, take over your servers, create their own hidden admin accounts, and run up an enormous bill mining cryptocurrency on your tab. Truffle found that only about one account in ten had a billing alert that would even notice.
The real problem is not the leak. It is the silence after it
Keys leak. That is a permanent fact of building software, and we covered a sharp example only last week in the leaked key that emptied a charity's CRM. What this larger study exposes is the second failure, the one that turns a slip into a standing liability: almost nobody deactivates the leaked key afterwards. Of the accounts the researchers could inspect, 86% had never rotated the exposed key at all. No newer key beside it, no sign anyone had noticed or cared.
The reason is mundane and human. An AWS access key, once created, works forever unless someone deliberately switches it off. It has no expiry date. So a key made in 2019 for a project that shipped, a contractor who left, or a script that was retired keeps working in 2026, long after everyone who knew about it has moved on. Nobody turns it off because turning it off is nobody's job, and nothing forces the issue. The credential just quietly waits.
This is the same shape as a problem we have written about before: the things you stopped using are still attacking you. A retired key is a retired thing that never went away.
What to do about it
You do not need to be an AWS expert to get most of the benefit here. The following are either quick jobs for whoever runs your cloud, or plain questions to put to them.
Delete your root access keys. The master key for an AWS account should almost never exist as an access key at all. AWS itself recommends against it. If your account has root access keys, the safest state is to delete them, and there is a button for exactly that in the account's security settings. This one step removes the most dangerous keys entirely.
Find the old keys and turn them off. Every AWS account can list its access keys and when each was last used. Anything old, or belonging to a person or project no longer around, is a candidate for switching off. AWS lets you disable a key before deleting it, so you can turn it off, wait to see if anything breaks, and delete it once you are sure. The one-line question for your provider: which of our AWS keys are more than a year old, and do we still need them.
Stop creating long-lived keys where you can avoid them. The deeper fix is to lean on credentials that expire on their own rather than keys that live forever. For the technical detail this is what AWS's own guidance on temporary credentials and roles is for, and it is the single change that most reduces this whole class of risk. If you build on AWS, this belongs on your list this quarter.
Set a billing alarm today. Separate from the security fix, a budget alert is the tripwire that tells you when a leaked key is being abused, usually by a spike in charges. It takes minutes to set up and it is the reason a compromise costs you a phone call rather than a five-figure bill. We wrote about why the alarm matters, and why the default is not enough, in a filing on AWS billing alarms.
How Steelwise can help
Working out what credentials your cloud account is holding, which of them are old, over-powered, or forgotten, and closing them off without breaking what still runs, is the kind of infrastructure review we do. Get in touch.
Further reading
- AWS: Managing access keys for IAM users
- AWS: Security best practices in IAM
- NCSC: Small Business Guide