Long-lived AWS access keys — the AKIA... ID and its secret — are the most abused credential in cloud security, because a single leaked pair grants programmatic access to whatever the associated IAM principal can do, from anywhere on the internet, with no second factor. The Uber 2016 breach started with AWS keys found in a private GitHub repository and ended with 57 million records exposed. The Capital One breach in 2019 took a different path to the same place: a server-side request forgery flaw let an attacker reach the EC2 instance metadata service, pull the temporary credentials attached to the instance role, and read over 100 million records from S3. Both breaches share a root cause that is entirely preventable in 2026 — credentials that were more powerful, more persistent, and more reachable than they needed to be. This guide covers how to eliminate access keys where you can and harden the ones you cannot.
How AWS keys get compromised
There are three dominant paths. The first is source-code leakage: keys committed to git, baked into container images, or embedded in mobile apps, then scraped by bots that test them within minutes. The second is the instance metadata service (IMDS): before IMDSv2, any SSRF or local file-read bug on an EC2 instance could fetch the role credentials from http://169.254.169.254/, exactly as Capital One's attacker did. The third is simply keys that never expire — a developer creates an access key for a quick script in 2021, it lands in a dotfile, and it is still valid and forgotten in 2026. AWS itself reports that the overwhelming majority of credential-abuse cases it sees involve long-lived keys, which is why the strongest control is to stop creating them.
Best practices, with commands
Prefer roles and short-lived credentials over access keys entirely. For human access, use IAM Identity Center (formerly AWS SSO), which issues session credentials that expire automatically. For workloads on EC2, ECS, EKS, or Lambda, attach an IAM role — the SDK fetches rotating temporary credentials with no static key to leak. For CI/CD, use OIDC federation instead of storing an AKIA key as a build secret.
# Configure the CLI to use IAM Identity Center instead of a static key
aws configure sso
aws sso login --profile prod
# The resulting credentials are temporary and expire on their own
Enforce IMDSv2 so metadata credentials cannot be stolen by SSRF. IMDSv2 requires a session token obtained with a PUT request, which a naive SSRF cannot forge, and you should require it rather than merely allowing it:
# Require IMDSv2 (token) and block IMDSv1 on an existing instance
aws ec2 modify-instance-metadata-options \
--instance-id i-0abc123 \
--http-tokens required \
--http-endpoint enabled \
--http-put-response-hop-limit 1
If you must keep an access key, scope it tightly and rotate it. Grant the minimum IAM policy, never attach AdministratorAccess to a programmatic user, and rotate on a schedule using the create-before-delete pattern:
# Create the new key first, deploy it, then deactivate the old one
aws iam create-access-key --user-name ci-uploader
aws iam update-access-key --user-name ci-uploader \
--access-key-id AKIAOLD --status Inactive
# After verifying no errors, delete permanently
aws iam delete-access-key --user-name ci-uploader --access-key-id AKIAOLD
Audit for old and unused keys continuously. The IAM credential report tells you the age and last-used date of every key in the account:
aws iam generate-credential-report
aws iam get-credential-report --query Content --output text | base64 -d > report.csv
# Flag any access_key_1_last_used_date older than 90 days for removal
AWS access key hardening checklist
| Control | What it prevents |
|---|---|
| IAM Identity Center for humans | Long-lived keys in developer dotfiles |
| IAM roles for EC2/ECS/EKS/Lambda | Static keys on compute you own |
| OIDC federation for CI/CD | AKIA keys stored as build secrets |
| IMDSv2 required, hop limit 1 | SSRF-to-metadata credential theft (Capital One pattern) |
| Least-privilege IAM policies | Full-account blast radius from one key |
| 90-day key rotation and unused-key removal | Forgotten, indefinitely valid credentials |
| MFA on all human principals | Credential replay from stolen passwords |
How Safeguard's secret scanning helps
The best control is not creating access keys, but real environments always have a few, and they leak. Safeguard's secret scanning detects AKIA/ASIA key pairs across your repositories and full git history, not just the current tip, and reports the exact commit and author so you can rotate and purge in one pass. Griffin AI validates whether a detected key is live and classifies its likely privilege, so an active production key is triaged ahead of an expired sandbox one. Because credential exposure rarely travels alone, Safeguard's software composition analysis puts leaked keys, vulnerable dependencies, and misconfigurations in one prioritized view, and developers catch an accidental key commit before it merges by running the Safeguard CLI in pre-commit. If you are weighing tools, the Safeguard vs Snyk comparison covers how detection and prioritization differ.
Bring continuous secret and dependency scanning to your AWS repositories — get started free or read the documentation.
Frequently Asked Questions
Should I ever create a long-lived AWS access key in 2026?
Only as a last resort, and never for anything you can attach a role to. Human access should go through IAM Identity Center, workloads on AWS compute should use IAM roles, and CI/CD should use OIDC federation — all of which issue short-lived credentials with nothing static to leak. Reserve access keys for the rare integration that genuinely cannot use any of those, then scope and rotate it aggressively.
What does enforcing IMDSv2 actually protect against?
It closes the exact attack path used in the Capital One breach. IMDSv1 served instance role credentials to any request that could reach the metadata endpoint, so a server-side request forgery bug in your application was enough to exfiltrate them. IMDSv2 requires a session token obtained with a PUT request that a typical SSRF cannot forge, and setting the hop limit to 1 keeps the token from escaping the instance.
How often should access keys be rotated?
Every 90 days at most, and immediately on any suspicion of exposure. Use the create-before-delete pattern so rotation never causes an outage, and generate the IAM credential report regularly to find keys that are old or have not been used at all — unused keys are pure liability and should be deleted rather than rotated.
Is a key leaked to a private repository actually a problem?
Yes. The Uber 2016 breach began with AWS keys in a private repository that attackers reached through other credentials. Private source control is not an access-control boundary for secrets — treat any key that left your secrets manager as compromised, rotate it, and rely on scanning to prevent the commit from happening again.