Dormant access becomes a governance problem when reviewers cannot explain why it still exists or when it survives multiple certification cycles without meaningful use. At that point, the entitlement is no longer tied to a clear business outcome and should move into exception handling, investigation, or removal.
Why This Matters for Security Teams
Dormant access is rarely just an inventory issue. When an entitlement remains in place without a current owner, a documented purpose, or evidence of active use, it becomes hard to justify under least-privilege, audit, or incident response scrutiny. That matters because dormant access often survives longer than the business process that created it, especially in cloud and SaaS environments where service accounts, API keys, and delegated tokens can be overlooked.
Security teams should treat this as a governance signal, not only a technical hygiene task. The question is whether the access still maps to a live business outcome, whether the system owner can attest to it, and whether controls can detect abuse if the access is ever used again. NHIMG guidance on regulatory and audit perspectives frames this as a lifecycle problem, while the NIST Cybersecurity Framework 2.0 reinforces that identity governance must stay current with asset and risk ownership.
In practice, many security teams encounter dormant access only after a review cycle, audit request, or incident has already exposed that no one can explain why it still exists.
How It Works in Practice
Dormant access becomes governable when the organisation can measure age, activity, ownership, and exception status together. A stale entitlement is not automatically unsafe, but it should be tested against purpose and recertification evidence. For human accounts, that usually means sign-in history, application usage, and manager attestation. For NHI, it means token issuance patterns, secret rotation status, workload dependency, and whether the credential is still required by an active integration.
Current best practice is to tie dormant access reviews to lifecycle controls rather than one-time cleanup. The OWASP Non-Human Identity Top 10 highlights why over-permissioned and poorly rotated identities remain persistent risk drivers, while NHIMG’s Top 10 NHI Issues shows how visibility gaps and unmanaged lifecycle states turn simple entitlements into long-lived exposure.
- Tag access by owner, system, and business justification so reviewers can distinguish active from orphaned permissions.
- Set review triggers for inactivity, failed rotation, failed attestation, or a missing downstream dependency.
- Move unresolved items into exception handling with a fixed expiry and named approver.
- Remove access when no control owner can demonstrate a current need or when the dependency no longer exists.
Done well, this reduces certificate, API key, and delegated token sprawl before it becomes an audit finding. These controls tend to break down when identity records, application ownership, and workload telemetry live in separate systems because no single reviewer can prove whether the access is truly dormant.
Common Variations and Edge Cases
Tighter dormant-access controls often increase review overhead, requiring organisations to balance risk reduction against operational friction. That tradeoff is especially visible in service accounts, break-glass accounts, and vendor integrations, where “inactive” may simply mean low-frequency rather than unnecessary. Current guidance suggests using different thresholds for different identity classes, but there is no universal standard for this yet.
One common edge case is a credential that appears dormant but supports monthly, quarterly, or failover workflows. Another is delegated access that is not used directly by a person but still enables a business process. In those cases, the right response is not immediate removal, but a documented exception with owner attestation, expiry, and compensating monitoring. NHIMG’s 52 NHI Breaches Analysis and the Key Challenges and Risks section both show that the danger is not inactivity alone, but stale access that remains privileged because no one re-evaluates it after the original use case changed.
That is why dormant access should be treated as a lifecycle control with evidence, not a one-time certification question.
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 CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 | Dormant access often reflects poor rotation and lifecycle control. |
| NIST CSF 2.0 | PR.AC-4 | Access governance requires timely review of permissions and ownership. |
| NIST CSF 2.0 | GV.RM-2 | Dormant access becomes a governance issue when unmanaged risk accumulates. |
Review stale NHI entitlements and rotate or remove credentials that no longer support a live need.
