how to fix least privilege review showing stale AWS IAM users with old access keys error

TL;DR

Regenerate the evidence before you judge the users, because a review built on an old credential report will flag people forever. Generate a fresh IAM credential report, sort by key age and last used date, contact owners of keys with real recent use, and deactivate, then delete, keys with no use in the review window. Users who remain after key cleanup and have no console or key activity are the true dormant set to remove through the normal offboarding check.

how to fix least privilege review showing stale AWS IAM users with old access keys error

Use this when

• The same IAM users appear on every stale access report with keys older than policy allows.
• A credential report shows keys never used or unused for many months.
• Break glass and legacy users have no clear owner in the review.

Not for this skill when

• A key is old but used daily by a named service. Rotate it on a plan instead of deleting it in the review.
• Users sign in through an identity center only. Review those assignments in the identity center, not the IAM user list.

Steps

1. Generate a new IAM credential report, wait for its status to complete, and download it so every age and last used figure in this cycle is current. Verify: the report timestamp is from today and its status shows complete.
2. Sort users by access key age and last used date and split them into three groups named active use, no recent use and never used, with an owner noted for each where one exists. Verify: every flagged user sits in exactly one group with a named next action.
3. For the no recent use and never used groups, notify owners or managers with a specific deactivation date, giving service owners a chance to claim a key before it is touched. Verify: notices are sent with dates and any claimed keys are moved to the active group with an owner.
4. On the agreed date deactivate, rather than delete, the unclaimed keys and watch application and CloudTrail errors for a soak period agreed with the owners. Verify: the soak ends with no errors traced to the deactivated keys.
5. Delete the deactivated keys, remove console access for users with no sign-in activity, and record each removal against the review item that flagged it. Verify: deleted keys no longer appear in a regenerated credential report.
6. For users with no owner and no activity at all, run the HR status check used by offboarding, then delete the user only after that check confirms they should not have access. Verify: each deleted user has an HR check reference in the review record.
7. Regenerate the credential report, attach it to the review, and confirm the stale list is now empty or reduced to documented exceptions with rotation dates. Verify: the closing report shows no unexplained stale users.

Why it happens

Stale users persist because reviews often reuse last cycle evidence and because nobody owns the last step of key removal. A key that is never used still counts in every report until someone deactivates and deletes it, and deactivation feels risky without usage data. The credential report supplies that data URIs last used dates separate living services from abandoned access. Deactivate first, soak, then delete gives owners a safety net while still guaranteeing the list actually shrinks this cycle.

Variants and edge cases

IAM users with access keys older than 90 days report

The policy phrasing. Use the credential report fields for key age and last used together; age alone flags healthy services.

how to clean up dormant IAM users safely

The safety phrasing. The deactivate and soak sequence is the core safeguard, so keep it even under deadline pressure.

same users flagged every quarterly review

The repeat phrasing. Repeats mean last cycle closed on paper only; check whether deactivation actually happened.

Edge cases to check before closing the review cycle:

• Root account keys are handled separately and should be removed outright, not rotated on this schedule.
• Keys used by vendors need a named internal sponsor before deactivation, or the outage lands on your team.
• Some old keys belong to archived workloads that restart rarely. The soak window should cover their known run dates when possible.

Compatibility: AWS IAM credential report, IAM users and access keys, CloudTrail for usage verification, current AWS console and CLI v2.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_UVpJiRukPUohFCEKUUPruA