How do you find and disable inactive IAM users in AWS?

How to tell which IAM users are truly inactive

Inactive in aws iam usually means more than “no one has logged in recently.” You need to check console sign-in history, programmatic activity, and whether access keys have been used. A user can appear idle while still being tied to automation, a break-glass process, or a downstream dependency, so ownership review matters before removal.

For an AWS-specific review, the most useful starting point is an access inventory that separates human users from automation and then checks whether each user still has a business or operational owner. NHIMG’s AWS IAM Policies and Roles Guide is useful here because inactive-user decisions often depend on whether the user still has effective permissions through attached policies, roles, or trust paths.

In practice, stale-user detection works best when you look at three signals together: last activity, access key usage, and sign-in history. That combination helps you distinguish a genuinely dormant human account from a low-frequency service workflow or an account whose console access is unused but whose keys are still active. AWS IAM review is therefore a lifecycle and ownership exercise, not just a log search.

What to disable first, and what to leave alone until reviewed

The safest sequence is to disable the most clearly unused access path first, then confirm whether the user can still be needed for a scheduled job, integration, or disaster-recovery process. If access keys are present, deactivate them before deleting the user, because key-based access is often the easiest route for unintended reuse. If the account has no legitimate purpose, remove it only after ownership and dependency checks are complete.

NHIMG’s Lifecycle Processes for Managing NHIs is directly relevant when the AWS IAM user is acting as an automation or service identity, because the same offboarding and rotation logic applies even if the account looks like a human user in the console.

For teams that manage many AWS accounts, the practical distinction is between “no recent use” and “no remaining purpose.” The former is a signal to investigate; the latter is the condition that justifies deactivation or deletion. If you skip that distinction, you risk breaking hidden workloads, while keeping dormant users around creates unnecessary access surface.

What AWS review should prove before you remove an account

Before disabling or deleting an IAM user, you should be able to answer who owns it, what it was used for, and whether any scripts, apps, or cross-account access paths still depend on it. That is why access review should include attached policies, group membership, role assumptions, and any keys that are still valid. A user with no login activity can still be privileged if its permissions were never cleaned up.

NHIMG’s Cloud IAM Review Checklist supports that review because unused permissions, service identities, and cross-account trust often reveal whether an account is genuinely obsolete or just poorly documented. The same is true of the Top 10 AWS IAM Mistakes, where long-lived keys, weak trust boundaries, and missing guardrails are common reasons stale users remain dangerous long after they stop being actively used.

Once an account is confirmed inactive, deletion is cleaner than indefinite suspension because it removes the identity object itself and reduces future confusion. But if there is any uncertainty about dependent automation, temporary deactivation with monitoring is often the better intermediate step. That gives you a rollback window if the account was dormant rather than obsolete.

Risk and Threat Considerations

Inactive IAM users are attractive because they are easy to overlook, especially when access keys remain valid after the person or workflow has moved on. Dormant accounts increase the chance of unauthorized reuse, forgotten privilege, and delayed detection if credentials are exposed or recycled.

Failure mechanism: The user is assumed idle, but one or more access keys, group memberships, or trust relationships still grant usable AWS access, so an attacker or unauthorized process can continue operating under a low-visibility identity.

Impact: The result can be silent cloud access, privilege abuse, data exposure, or persistence through an account that teams no longer monitor closely.

Practitioner Guidance

What to verify: Confirm both console inactivity and API activity before you act. An IAM user with no interactive sign-in can still be active through keys, automation, or cross-account role use, so review all three indicators together.

Decision rule: If the user is tied to automation, treat it as a managed identity problem first, not a human offboarding problem. Rotate or retire the keys, document the owner, and only then remove the user if the workload has been migrated or replaced.

What good looks like: Every retained IAM user has a named owner, a current purpose, limited permissions, and a review date. Anything that fails that test should be disabled or removed after a short validation window, not left in place by default.

Practitioner takeaway: The goal is not to delete every quiet account, it is to eliminate identities that no longer have a justified purpose while preserving enough evidence and rollback room to avoid breaking hidden automation.

Related resources from NHI Mgmt Group

• How do you detect S3 Browser being used to create IAM users, keys or bucket policies in AWS?
• How do you know if AWS IAM controls are actually working?
• What breaks when service accounts and inactive users are not identified during IAM projects?
• What is the difference between AWS SSO based access and relying on separate IAM users for each account?