Dormant accounts still consume licenses, but the larger issue is that they often retain access long after business need has ended. That creates hidden standing privilege, stale entitlements, and a larger recovery problem when offboarding is delayed. If nobody is watching usage, the account can remain active indefinitely.
Why This Matters for Security Teams
Dormant accounts are often treated as housekeeping, but they create a compound problem: wasted licenses, hidden access paths, and a false sense of control. Once an account is no longer actively used, it is easy for its entitlements, group memberships, and service dependencies to go unnoticed. That leaves standing privilege in place long after business need has ended, which is exactly the condition attackers look for.
This is why account inactivity should be measured as both a cost issue and a control failure under the NIST Cybersecurity Framework 2.0. The operational risk is not limited to direct misuse; dormant access also slows offboarding, complicates audit evidence, and can mask identity sprawl across SaaS, cloud, and internal systems. NHIMG’s Top 10 NHI Issues research highlights how often weak visibility and stale identity hygiene become the root cause of avoidable exposure.
In practice, many security teams discover dormant access only after a former employee, contractor, or stale integration account is already reused or abused, rather than through intentional deprovisioning.
How It Works in Practice
The cost side is usually the easiest to quantify. Many platforms license by seat, identity, or active object, so dormant accounts keep consuming budget even when nobody logs in. The security side is harder because inactivity does not equal harmlessness. A dormant account may still hold RBAC roles, API tokens, mailbox access, file permissions, or delegated admin rights. If it is reactivated, compromised, or inherited by a poorly controlled process, it can become a ready-made privilege set.
Current guidance suggests treating dormancy as an identity lifecycle signal, not just an HR cleanup task. A mature process usually includes:
- Defined inactivity thresholds by account type, with shorter thresholds for privileged or external identities.
- Automated alerts before disablement, so owners can confirm whether access is still needed.
- Scheduled entitlement review to remove stale group memberships and excessive roles.
- Deprovisioning that spans SaaS, cloud IAM, directories, and downstream application accounts.
- Logging that distinguishes true dormancy from service account or break-glass exceptions.
For NHI-heavy environments, the same logic applies to integrations and machine accounts. A dormant token, key, or certificate may not look active in a console, but it can still authorize API calls. That is why NHIMG’s Ultimate Guide to NHIs emphasizes lifecycle management as a core security discipline, not an administrative afterthought. When controls are tied to usage signals, they also support the visibility goals described in NIST CSF 2.0 and reduce the chance that inactive access survives a personnel change. These controls tend to break down in decentralized SaaS estates because no single system owns the full deprovisioning path.
Common Variations and Edge Cases
Tighter dormant-account control often increases operational overhead, requiring organisations to balance lower risk against user friction and support workload. That tradeoff is most visible where accounts are shared, seasonal, or tied to regulated operations. Best practice is evolving here, and there is no universal standard for every account type.
Service accounts, break-glass accounts, and long-lived integrations should not be judged by the same inactivity rule as human users. A service account may appear dormant while still being essential to scheduled jobs, message queues, or batch processes. In those cases, current guidance is to validate usage through telemetry and ownership rather than simple login history. The same applies to contractor accounts that are intentionally paused for future work; they should be disabled, not left partially active.
NHIMG’s State of Non-Human Identity Security findings show how often visibility gaps and over-privileged access persist across identity estates, which makes dormancy checks especially important in hybrid environments. The practical answer is to pair periodic access reviews with automated disablement, clear exception handling, and strong reactivation workflows. Teams that skip those exceptions often either over-disable critical automation or leave stale accounts untouched because nobody wants to trigger a support incident.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 | Dormant accounts are stale identities that should be rotated or removed. |
| NIST CSF 2.0 | PR.AC-4 | Access rights must be reviewed so stale entitlements do not persist. |
| NIST AI RMF | Governance should account for identity lifecycle risk and accountability. |
Run periodic access reviews and revoke inactive entitlements before they become standing privilege.
