Dormant privilege is access that remains technically active after the business reason for using it has ended. The account still works, but the relationship, project, or contract that justified it no longer does. In practice, dormant privilege is a lifecycle failure that turns routine collaboration into lingering exposure.
Expanded Definition
Dormant privilege describes access that stays enabled after the original purpose for it has expired. In NHI operations, that usually means a service account, API key, bot identity, or delegated token still exists even though the project ended, the vendor was offboarded, or the integration was retired. It is closely related to privilege creep, but the difference matters: privilege creep is often gradual expansion, while dormant privilege is access left behind after the legitimate use case disappears.
Industry usage is still evolving, so some teams fold dormant privilege into entitlement sprawl or orphaned access. For NHI governance, the practical test is simple: if no current business process justifies the permission, it should be treated as exposure. This aligns with the lifecycle emphasis in the OWASP Non-Human Identity Top 10, especially where service credentials outlive their intended scope.
The most common misapplication is treating an unused account as harmless just because no one is actively logging in, which occurs when discovery, ownership, and revocation are not tied to contract or application retirement.
Examples and Use Cases
Implementing dormant privilege cleanup rigorously often introduces operational friction, requiring organisations to balance faster delivery and continuity against stricter revocation and revalidation.
- A third-party payment integration is decommissioned, but its API key remains active in a secrets store and still has write access to transaction logs.
- A CI/CD robot account keeps production deployment rights after a migration to a new pipeline, because the old role was never removed during cutover.
- A contractor's NHI is retained after project completion so an auditor can "just in case" review past data, even though the account now has broader access than needed.
- A cloud automation agent continues to hold admin permissions in a sandbox and production-linked subscription long after the team moved the workload elsewhere.
These cases are easier to miss when organisations rely on periodic spreadsheets instead of real-time ownership and expiry data. NHI lifecycle issues are discussed in Ultimate Guide to NHIs — Key Challenges and Risks, where excess privilege and weak offboarding are shown to compound one another. For control design, the same pattern appears in the OWASP Non-Human Identity Top 10, which treats unmanaged machine identity access as a core threat surface.
Why It Matters in NHI Security
Dormant privilege is dangerous because it turns temporary collaboration into permanent exposure. Once the business relationship ends, there is no legitimate operator left to notice that the access still exists, yet the account can still move data, call APIs, or modify infrastructure. That is why dormant privilege is not just an IAM housekeeping issue; it is a governance failure that weakens least privilege, complicates incident response, and undermines Zero Trust assumptions.
The operational risk is visible in the data: Ultimate Guide to NHIs — Key Challenges and Risks reports that 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface. Dormant privilege often feeds that condition because old access is easier to keep than to remove. It also conflicts with zero standing privilege expectations and with lifecycle controls described in OWASP Non-Human Identity Top 10.
Organisations typically encounter the real impact only after a vendor breach, pipeline compromise, or failed audit, at which point dormant privilege becomes 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 Zero Trust (SP 800-207) 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-02 | Addresses unmanaged NHI credentials and permissions that persist beyond business need. |
| NIST Zero Trust (SP 800-207) | 5.2 | Zero Trust requires continuous verification and denies implicit trust in standing access. |
| NIST CSF 2.0 | PR.AC-1 | Access provisioning and revocation controls map directly to dormant privilege cleanup. |
Remove stale machine access, enforce expiry, and review NHI privileges on a lifecycle basis.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on June 6, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
