Infra Audit5 min readUpdated November 4, 2026

The Most Dangerous IAM User Is the One Nobody Uses

A contractor left, the key stayed. No alerts fire on an unused key until someone uses it. The Cisco incident: one dormant credential, 450 servers.

List every IAM user with aws iam list-users, check each access key's LastUsedDate. A key unused for 90+ days is a dormant credential: disable it, rotate it, or delete it. Dormant keys have no monitoring because nothing watches for first use.

An active key is watched: its usage appears in CloudTrail, anomalies can be caught. A dormant key has no baseline, so its first use in a year generates no alarm. The attacker who finds it in a leak or an old laptop gets a quiet credential with whatever permissions it kept.

See How We Work

In This Guide

Why dormant beats active in danger

An active key is watched: its usage appears in CloudTrail, anomalies can be caught. A dormant key has no baseline, so its first use in a year generates no alarm. The attacker who finds it in a leak or an old laptop gets a quiet credential with whatever permissions it kept.
An active key is watched: its usage appears in CloudTrail, anomalies can be caught. A dormant key has no baseline, so its first use in a year generates no alarm. The attacker who finds it in a leak or an old laptop gets a quiet credential with whatever permissions it kept. Cisco 2018: a former employee's credentials, dormant for months, reached 450 servers. Illuminate's case: 3.5 years dormant, 10.1 million records.

The check

Three commands: aws iam list-users, aws iam list-access-keys --user-name X, aws iam get-access-key-last-used --access-key-id Y. Flag every key older than 90 days since last use, every key never used, and every user with no MFA.
Three commands: aws iam list-users, aws iam list-access-keys --user-name X, aws iam get-access-key-last-used --access-key-id Y. Flag every key older than 90 days since last use, every key never used, and every user with no MFA. The audit skill runs all three and reports ages in the findings, so the fix list is a table, not a hunt.

If it stays

The key ages, the permissions stay, and the offboarding that should have removed it recedes further into history. Every backup, every exported CSV, every old laptop that contains the key extends the exposure surface. The fix costs minutes; the incident costs the breach.
The key ages, the permissions stay, and the offboarding that should have removed it recedes further into history. Every backup, every exported CSV, every old laptop that contains the key extends the exposure surface. The fix costs minutes; the incident costs the breach.

Get the skill

The checks in this guide come from the roqy audit skill, open source at https://github.com/roncoo-2/roqy-audit. It runs read-only against your own account, produces findings with verdicts (confirmed, needs_validation, rejected), and was validated on a live canary AWS account where 9 planted misconfigurations were detected 9 out of 9 times.
The checks in this guide come from the roqy audit skill, open source at https://github.com/roncoo-2/roqy-audit. It runs read-only against your own account, produces findings with verdicts (confirmed, needs_validation, rejected), and was validated on a live canary AWS account where 9 planted misconfigurations were detected 9 out of 9 times. The full canary report is in the repository under docs/runs. Copy the skill into any coding agent, point it at your stack, and get the same report for your account.

4 Tips to Get Started

1

aws iam list-users + list-access-keys + get-access-key-last-used covers the whole check in three calls.

2

Disable before delete: deactivation for 30 days catches the one legitimate cron job nobody remembered.

3

Contractor offboarding is the top source of dormant keys. Tie key review to offboarding.

4

Root account keys are a separate finding: they should not exist at all.

Ready to Stop Worrying About Infra?

Knowledge is the first step. Get a free 1-hour diagnostic and see where your infrastructure leaks time, money, and focus.

Related Guides

Is My S3 Bucket Public? How to Check in One Command

One command tells you if your S3 bucket is public, and one curl proves it. The policy check shows intent, the anonymous request shows reality.

The Most Common AWS Misconfiguration (It Is One Line of Config)

Public buckets and Principal * policies cause most disclosed AWS incidents. Each is one line of config with account-wide blast radius. Here is the pattern.

Terraform State File Leak: Every Secret in Plaintext

terraform.tfstate stores database passwords, IAM keys and TLS private keys in plaintext. sensitive=true hides nothing. Here is how leaks happen and the check.

Docker Socket Mounted in a Container: Root on the Host, No Exploit Needed

A container with /var/run/docker.sock mounted controls the host daemon and can mount your entire filesystem. No kernel exploit required. Here is the mechanism and the check.

R

Ron Cohen — DevOps engineer & founder, roqy.io

Content reviewed by the roqy.io team. Our guides are based on publicly available data.

Disclaimer: This content is for informational and educational purposes only. It does not constitute professional advice or a guarantee of specific results. Infrastructure needs vary by team, stack, and stage. Consult a qualified engineer for advice tailored to your situation.

Frequently Asked Questions

What is a dormant IAM user and why is it dangerous?

An IAM user or access key with no activity for 90+ days. It keeps its permissions, it has no monitoring on first use, and nobody notices when it is finally used. In the Cisco incident, a former employee's dormant credentials gave access to 450 servers for months. The fix: disable unused keys, then delete them.

How do I find unused IAM access keys?

aws iam list-users, then for each user aws iam list-access-keys and aws iam get-access-key-last-used. Any key with a LastUsedDate older than 90 days, or never used since creation, is dormant. Disable it first, watch for complaints for 30 days, then delete.

Should I delete or disable a dormant key?

Disable first. A disabled key stops working immediately but is recoverable if a forgotten legitimate job breaks. After 30 days of silence, delete. Deletion without the observation window risks breaking an unknown automation, which teaches teams to avoid key hygiene.

Get the DevOps Ecosystem Behind You

One accountable engineer. Full platform behind him. Month-to-month, no lock-in.

See How It Works