AWS Security Hub · IAM
IAM.8: Unused IAM keys and passwords are waiting to be leaked
Written and reviewed by Emnode · Last reviewed
What does AWS Security Hub IAM.8 check?
IAM.8 fails when an IAM user has a console password or access key that has gone unused for 90 days or more. The control reads last-used timestamps from the credential report to find dormant credentials.
Why does IAM.8 matter?
A credential nobody uses is a credential nobody is watching. Forgotten keys from departed staff or retired automation sit active for years, and they're exactly the kind that turn up leaked in old public commits or backups long after anyone remembers issuing them. Disabling or removing unused credentials reduces the window of opportunity for credentials associated with a compromised or abandoned account to be used, shrinking the attack surface to only what's actually in service.
How do I fix IAM.8?
- Pull the credential report and flag passwords and access keys idle for 90+ days.
- Deactivate each stale key first and watch CloudTrail to confirm nothing breaks.
- Delete the deactivated keys and remove console passwords for users who no longer sign in.
- Add an AWS Config rule so the same dormant credentials can't quietly drift back in.
Remediation script · bash
# Find active credentials idle past 45 days and disable them (review before deleting).
CUTOFF=$(date -u -d '45 days ago' +%Y-%m-%d)
aws iam generate-credential-report >/dev/null
aws iam get-credential-report --query Content --output text | base64 -d \
| awk -F, -v c="$CUTOFF" 'NR>1 && $9=="true" && $11<c {print $1, $10}'
aws iam update-access-key --user-name old-contractor \
--access-key-id AKIAIOSFODNN7EXAMPLE --status Inactive
# Apply the CIS-aligned IAM password policy in one idempotent call.
aws iam update-account-password-policy --minimum-password-length 14 \
--require-uppercase-characters --require-lowercase-characters \
--require-numbers --require-symbols --password-reuse-prevention 24
# A clear-text key in a build project is compromised: rotate and delete, never just relocate.
aws iam delete-access-key --user-name ci-deploy --access-key-id AKIAIOSFODNN7EXAMPLEFull walkthrough (console steps, edge cases and verification) in the lesson Rotate and remove stale IAM credentials.
Is IAM.8 a false positive?
The legitimate failure here is the break-glass account: an IAM user kept deliberately idle as an emergency console login for when SSO or federation is down. By design it goes unused for far more than 90 days, so this control will flag it every cycle even though leaving it in place is the correct call. The same applies to a genuinely seasonal automation key (used heavily once a quarter, dormant the rest of the time). Don't deactivate these; document why they exist, lock them behind MFA and tight monitoring, and suppress the finding for the specific user ARN. Reserve actual deletion for credentials nobody can explain: the forgotten keys of departed staff and retired jobs are what this control is really there to surface.
More IAM controls
- IAM.1 A policy grants full "*" administrative privileges
- IAM.2 Policies attached directly to users do not scale or audit cleanly
- IAM.3 Long-lived access keys have not been rotated
- IAM.4 The root user still has long-lived access keys
- IAM.5 Console users without MFA are one phish from compromise
- IAM.6 The root user is not protected by hardware MFA
- IAM.7 The IAM password policy is too weak
- IAM.9 The root user can sign in without MFA
- IAM.10 IAM user password policies should be strong (PCI DSS)
- IAM.19 MFA should be enabled for all IAM users
- IAM.21 Wildcard permissions grant far more access than intended
- IAM.22 IAM credentials unused for 45 days should be removed