Dormant Account Rate measures the share of accounts or entitlements with little or no recent use over a defined period, such as 30, 60, or 90 days. Dormancy does not prove misuse, but it is a strong indicator of over-provisioning, stale access decisions, and growing review burden across the identity estate.
Expanded Definition
dormant account Rate is an operational signal, not a verdict: it measures how many accounts or entitlements have had little or no recent activity within a defined window, then uses that ratio to highlight stale access decisions. In NHI programs, the term is most useful when tied to a policy threshold, because 30, 60, and 90 day windows can mean very different things for a batch job, a CI/CD service account, or an integration key. That is why usage in the industry is still evolving and definitions vary across vendors. NIST SP 800-53 Rev 5 Security and Privacy Controls is helpful here because it frames account management, access review, and least privilege as ongoing control activities rather than one-time provisioning events. A high dormant rate often indicates poor lifecycle hygiene, weak ownership, or missing decommissioning workflows. It also differs from simple inactivity reporting: the metric should be used to drive review and action, not to assume compromise. The most common misapplication is treating dormancy as automatic revocation, which occurs when teams delete accounts without validating whether scheduled, low-frequency, or emergency-use access is still required.
For broader NHI lifecycle context, the Ultimate Guide to NHIs explains why idle identities become governance debt when ownership and rotation are not enforced.
Examples and Use Cases
Implementing Dormant Account Rate rigorously often introduces a review burden, requiring organisations to balance stronger access hygiene against the cost of investigating legitimate low-frequency use.
- A cloud API key used only during month-end reporting is flagged after 60 days of inactivity, prompting the owner to confirm whether the integration is still needed or should be retired.
- A service account created for a one-time migration remains enabled for a full quarter, revealing a gap in offboarding and entitlement cleanup.
- A CI/CD deployment token is inactive between release cycles, so the security team treats it as expected dormancy only if the token is tied to a documented workflow and owner.
- An internal data pipeline account shows no logins after a platform change, which leads to a control check against the account inventory and application dependencies.
- Teams align the metric with lifecycle evidence from the Ultimate Guide to NHIs and control expectations in NIST SP 800-53 Rev 5 Security and Privacy Controls before deciding whether inactivity is acceptable or a sign of orphaned access.
In practice, the right use case is to separate expected dormancy from unmanaged sprawl, especially where systems are event-driven or seasonal.
Why It Matters in NHI Security
Dormant access becomes dangerous when no one can explain why it still exists. In NHI environments, idle accounts are often the easiest path to privilege accumulation, because they were provisioned for a project, forgotten, and left with credentials that still validate. That is why Dormant Account Rate matters as a governance metric: it reveals how much of the identity estate is no longer actively defended by a business owner. The NHI Mgmt Group notes that only 5.7% of organisations have full visibility into their service accounts in the Ultimate Guide to NHIs, which means dormancy can hide inside blind spots rather than show up in clean inventory reports. When this metric stays high, review queues grow, exception handling becomes routine, and auditors start asking why unused access remains enabled. NIST guidance reinforces that access review and account lifecycle management are core controls, not optional hygiene. Organisations typically encounter the real cost only after an incident response, at which point dormant accounts become operationally unavoidable to address.
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 SP 800-63 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 | Dormant accounts often indicate poor secret and credential lifecycle management. |
| NIST CSF 2.0 | PR.AC-1 | Account lifecycle and access control governance depend on identifying stale identities. |
| NIST SP 800-63 | Digital identity assurance depends on keeping authenticators and accounts current. |
Ensure dormant identities are reassessed so unused authenticators do not remain trusted indefinitely.
