Resetting an IAM User's Console Password Leaves Access Keys Active

Symptom

A departed user’s console sign-in no longer works, yet their IAM access keys still show a status of Active.

In the IAM console or in the credential report, the password is disabled or reset, but the access key columns still show active keys. Calls made with those keys may continue to appear in audit logs.

False Assumption

The common assumption is that resetting the console password revokes the user’s access. In IAM, a console password and an access key are separate credentials, and changing one does not change the other. The unverified part of this article is exact console or CLI behaviour in your account; confirm it against current AWS IAM documentation, which is listed in the sources.

Root Cause

IAM users can hold several independent credential types: a console password, up to two access keys, and others such as MFA devices. Offboarding that touches only the password leaves the access keys valid. Any policies attached to the user also stay in force, so the keys keep whatever permissions the user had.

Impact

A former user, or anyone holding a leaked copy of the key, may retain programmatic access to AWS APIs with the user’s permissions. The blast radius is whatever the user’s policies allow. The severity here is rated high because access persists silently and is easy to overlook.

Diagnosis

Use read-only checks first. Generate and review the IAM credential report, then list keys for the specific user. Compare the last-used information for each key before changing anything, so you know whether the key is in live use by a service.

• Review the credential report columns for access key status and last use.
• List the user’s keys and read each key’s last-used details.
• Check your logging for recent activity attributed to the key identifier.

Related reading: how a missing sts:ExternalId enables confused deputy attacks and why AWS identity controls leave workloads exposed until verified.

Correction

Deactivate rather than delete first, because deactivation is reversible. Do this in a validated, approved change window and record the key identifiers beforehand. If a key is used by a workload, create a replacement for that workload before deactivating the old one, and prefer roles with temporary credentials over long-lived keys where practical. After a deactivation period with no breakage, delete the key. Also remove the user’s other credentials and policies as part of offboarding. For role-based alternatives see IAM role chaining through Lambda PassRole wildcards for the risks of loosely scoped role permissions.

Validation

Success means every key for the departed user shows Inactive and no new successful calls appear for it. Re-run the key listing and confirm status, then watch logs for new authentication attempts from the key identifier. Failed attempts after deactivation confirm that the key is being refused. Confirm any replacement credential works for the owning workload.

Rollback

If a deactivated key turns out to support a live workload, re-activate that key to restore service, then plan a proper replacement. Rollback is only possible while the key has not been deleted, which is why deletion should be deferred. Re-activating a key for a departed user restores their access, so treat it as a short, tracked exception and escalate to a human owner.

Prevention

Build offboarding as a checklist covering password, access keys, MFA devices, group membership and attached policies. Report on keys with no recent use, enforce rotation, and favour federated identities and roles so no per-person long-lived keys exist. Next safe decision: run the read-only inventory across your accounts and review the results with the account owner before changing anything.