How should organisations manage dormant IAM accounts before they become a security and cost problem?

Why Dormant IAM Accounts Become a Governance Problem

Dormant IAM accounts are not harmless inventory. They can retain valid access long after the original business need has passed, which creates both security exposure and avoidable licence cost. The practical issue is not simply “unused” access, but access that remains live without a current owner, review cadence, or clear retirement trigger. Once that happens, the account can drift into the same blind spot as orphaned credentials and stale permissions.

Organisations often underestimate how quickly dormant accounts accumulate across role changes, project endings, contractor exits, and service transitions. A small number of overlooked accounts may seem insignificant, but they can still satisfy an attacker’s objective if they are reactivated, guessed, or abused through weak monitoring. They can also distort access reviews by making it harder to tell which identities are truly active. NHIMG research on non-human identity management shows that many organisations still lack strong confidence in securing machine identities, which reflects a wider lifecycle gap that also affects dormant human IAM accounts when governance is manual or sporadic.

Lifecycle discipline matters because the problem is usually administrative before it becomes adversarial. In practice, many security teams discover dormant accounts only after a review cycle, an audit finding, or an incident investigation has already exposed how long they were left in place.

How Dormancy Detection and Deprovisioning Work in Practice

The most reliable approach is to treat inactivity as a lifecycle signal, not as a one-time cleanup task. Organisations should define what “dormant” means for each identity class, because a contractor, a seasonal employee, and a privileged administrator may need different thresholds. A good policy pairs inactivity telemetry with business context: login absence alone is not enough if the account is tied to a leave of absence, shared workflow, or approved standby role.

Automation is important because manual review tends to lag behind reality. Continuous checks can flag accounts with no authentication, no privilege use, or no successful access across a defined period, then route them into a staged process: notify the owner or manager, validate whether the account is still needed, and suspend or deprovision if no justification is provided. That sequence is safer than immediate deletion in environments where access restoration must be controlled, but it should not become an excuse to leave accounts live indefinitely. Where the issue is broad, NIST Cybersecurity Framework 2.0 provides a useful governance lens for asset lifecycle and access control, while NHIMG’s NHI Lifecycle Management Guide helps teams think in terms of ownership, state changes, and retirement discipline across identities.

• Track last use, owner, manager, and business purpose for every account that can persist beyond employment or project end.
• Link deprovisioning to events such as termination, role reassignment, and contractor closeout rather than relying on periodic cleanup alone.
• Separate suspension from deletion when legal, audit, or recovery requirements require a reversible step.
• Measure dormant-account volume over time so you can see whether cleanup is reducing backlog or merely redistributing it.

Where this guidance breaks down is in environments with poor identity ownership data, shared admin accounts, or application dependencies that still rely on accounts no one formally owns.

Common Variations, Cost Pressure, and Edge Cases

Tighter dormant-account controls often increase short-term administrative overhead, so organisations have to balance faster deprovisioning against the risk of breaking legitimate access paths. That tradeoff is most visible in regulated environments, merger activity, and large enterprises where identity stores, HR systems, and access approvals do not move in lockstep. Best practice is evolving, but the key judgement remains the same: if an account cannot be tied to a current business need, it should not be allowed to sit in an active state by default.

Privileged accounts deserve stricter thresholds than ordinary user accounts because the impact of stale access is disproportionate. The same is true for accounts tied to finance, customer data, source code, or production operations. In those cases, it is better to use shorter inactivity windows, stronger revalidation, and explicit exception handling than to rely on the same rules used for low-risk standard access. Some organisations also discover that licence savings are delayed because deprovisioning is not connected to procurement and SaaS reclamation workflows, so the cost problem persists even after access is removed.

For teams trying to reduce both risk and spend, The State of Non-Human Identity Security is useful because it shows how weak lifecycle control and limited visibility often travel together, and the same pattern commonly appears in dormant IAM backlogs. Dormancy becomes most dangerous when owners assume “inactive” means “safe,” because an unused account can still be recovered, abused, or counted as a live licence long after everyone has stopped thinking about it.

Risk and Threat Considerations

Dormant IAM accounts create two distinct exposures: control failure and attack opportunity. From a governance perspective, they weaken identity hygiene, inflate access-review noise, and make it harder to prove that access is aligned with current business need. From a threat perspective, they can provide a low-friction foothold if an attacker discovers an account that still authenticates, still has excessive privilege, or is less closely monitored than active identities.

Failure mechanism: Dormant accounts become risky when inactivity is not tied to revocation, monitoring, or ownership reassignment. Attackers may target forgotten accounts because they are less likely to trigger behavioural scrutiny, and defenders may miss them because the account no longer appears operational even though it still exists in the directory or SaaS tenant.

Impact: The result can be unnecessary licence spend, audit findings, hidden privilege retention, and a wider blast radius if an account is reactivated or compromised. In the worst case, a dormant but still-authorised identity becomes an unobserved path into systems that teams believed were already closed off.

Practitioner Guidance

What to prioritise: Start with dormant privileged accounts, contractor accounts, and any identity tied to production, financial, or customer-facing systems. Those accounts create the highest downside if they are overlooked, and they usually justify faster remediation than low-impact standard users.

Decision rule: If an account has no current owner, no current business purpose, and no approved exception, treat it as a deprovisioning candidate rather than an access-review item. If the account must remain for operational reasons, require a named owner and a review date so the exception does not become permanent.

What to measure: Track dormant-account count, time-to-removal after inactivity, percentage of accounts with clear ownership, and the number of exceptions older than one review cycle. Those measures show whether the programme is actually shrinking risk and cost, or merely documenting it more carefully.

Practitioner takeaway: The best control is not a periodic cleanup campaign; it is a lifecycle design that makes stale access difficult to keep, easy to find, and simple to retire.

Related resources from NHI Mgmt Group

• How should security teams govern dormant Office 365 accounts before they become exposure paths?
• How should security teams reduce the risk from dormant SaaS accounts before they become an attack path?
• How should security teams manage shadow APIs before they become exposure points?
• What do organisations get wrong when they treat identity security as only an IAM or workforce problem?