A non-human identity that is no longer actively used but still has valid access. Dormancy is risky because it looks harmless while preserving credentials, permissions, and trust relationships that can still be abused or accidentally triggered.
Expanded Definition
A dormant identity is a service account, API key, workload identity, or other NHI that is no longer in active operational use but still retains valid authentication material, permissions, or trust bindings. In NHI governance, dormancy is not the same as decommissioning: the identity may be idle for weeks or months while still being capable of access if a job restarts, a pipeline reruns, or a token is replayed. Definitions vary across vendors on whether a dormant identity must be completely unused or simply not observed in a given telemetry window, so organisations should define a clear inactivity threshold and a revocation policy.
This matters because dormant credentials often sit outside normal human review cycles and can survive application refactors, ownership changes, or environment migrations. NHI Management Group’s Ultimate Guide to NHIs frames lifecycle control as a core governance requirement, not an optional hygiene task. In practice, dormant identities become a hidden trust layer unless inventory, ownership, and expiry are continuously maintained. The most common misapplication is treating “inactive” as equivalent to “safe”, which occurs when access is left valid after the workload, integration, or deployment path has already changed.
Examples and Use Cases
Implementing dormant-identity controls rigorously often introduces operational friction, because teams must distinguish legitimate low-frequency use from truly abandoned access and accept occasional false positives in exchange for reduced attack surface.
- A CI/CD service account used by a retired pipeline still has write access to production secrets, even though the pipeline has not run for months.
- An API key for a partner integration is left valid after the partner contract ends, creating silent exposure until rotation or revocation occurs.
- A cloud workload identity remains bound to an old namespace after a migration, so a forgotten trust relationship can still authenticate if the namespace is recreated.
- An emergency automation account is no longer needed after the on-call process changes, but its certificate remains valid in a vault and can still be used.
These patterns are visible in breach analysis across NHIs, including the 52 NHI Breaches Analysis, where unused or overlooked machine access repeatedly becomes a persistence path. External guidance such as the NIST Cybersecurity Framework 2.0 reinforces the need for asset visibility, access management, and continuous monitoring, which are all prerequisites for spotting dormant identities before they are abused.
Why It Matters in NHI Security
Dormant identities matter because they often retain the exact privileges defenders assume have already been removed. When organisations lack full visibility into service accounts, dormant access blends into the background and survives longer than intended. NHI Management Group reports that only 5.7% of organisations have full visibility into their service accounts, which means most teams cannot reliably distinguish active machine access from abandoned trust. That gap is especially dangerous when dormant identities carry broad permissions, long-lived secrets, or links to sensitive pipelines and production systems.
In NHI operations, dormancy is a lifecycle failure as much as an access-control issue. The right response is to pair inventory, ownership, expiry, and rotation with periodic proof that the identity is still required. The challenge is not just finding the identity, but determining whether any downstream dependency still relies on it. This is why dormant identities frequently appear in post-incident reviews alongside leaked secrets, stale certificates, and orphaned automation paths. Organisations typically encounter dormant identity risk only after an audit, compromise, or failed rotation exposes the access path, at which point the term 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 CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 | Dormant identities are orphaned machine access that should be inventoried and retired. |
| NIST CSF 2.0 | PR.AA-01 | Access identities must be managed across their lifecycle, including inactivity and removal. |
| NIST Zero Trust (SP 800-207) | Zero Trust requires continuous verification rather than assuming idle identities are harmless. |
Track every NHI, verify business ownership, and revoke identities that no longer serve an approved workload.
