Access or privilege that is still active in an environment but no longer has a legitimate business purpose. In contractor security, dormant risk appears when offboarding is delayed or incomplete. The account is quiet, but it remains exploitable, which makes it especially dangerous in environments with weak lifecycle governance.
Expanded Definition
Dormant risk describes access or privilege that remains active after the business need has ended. In NHI and IAM environments, that usually means a service account, API key, certificate, or contractor-linked credential still exists even though the workload, engagement, or approval path no longer does. The risk is “dormant” because the identity is quiet, not because it is harmless.
Definitions vary across vendors on whether dormant risk includes only unused credentials or also includes active credentials with stale approvals, but NHI governance treats both as lifecycle exposure when offboarding, rotation, or ownership tracking fails. This matters because an inactive credential can still be used by an attacker, automation job, or integration with inherited trust. The control problem is less about current activity and more about whether the identity still has legitimate authority. NIST guidance on identity and access management, including the NIST Cybersecurity Framework 2.0, reinforces that access must be continually governed, not merely issued once. The most common misapplication is treating “no recent login” as proof that a credential is safe to keep, which occurs when lifecycle reviews are based on usage telemetry instead of entitlement validity.
Examples and Use Cases
Implementing dormant-risk controls rigorously often introduces administrative overhead, requiring organisations to balance faster delivery against stronger lifecycle governance and exception handling.
- A contractor leaves after a migration project, but the contractor’s API token remains valid in a CI/CD pipeline until someone notices the pipeline never stopped running.
- A microservice is decommissioned, yet its certificate and backing service account remain active because no one updated the asset inventory or ownership record.
- An internal automation job changes platforms, but the old scheduled task still holds privileged access in the legacy environment, creating silent exposure.
- A third-party integration is replaced, but the revoked business relationship is not matched by credential revocation, leaving a dormant path into production.
These situations are central to the Top 10 NHI Issues because inactivity alone does not eliminate exploitability. They also align with service-account lifecycle concerns described in the Ultimate Guide to NHIs — Key Challenges and Risks, where offboarding and revocation gaps are treated as governance failures rather than edge cases. A practical approach is to review ownership, business purpose, and revocation status together, instead of relying on usage logs as the only indicator.
Why It Matters in NHI Security
Dormant risk is dangerous because NHI compromise often succeeds through forgotten access rather than noisy intrusion. NHI Mgmt Group reports that only 20% of organisations have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them, which means dormant credentials can persist long after their purpose ends. That persistence expands the attack surface, especially in environments where secrets are embedded in code, automation, or third-party workflows.
This is also why dormant risk is not just an operational housekeeping issue. A stale credential can become the easiest path to privilege escalation, lateral movement, or supply-chain abuse if ownership is unclear and monitoring is weak. The governance lesson in the Ultimate Guide to NHIs — Why NHI Security Matters Now is that hidden access becomes material when it survives business change. Organisations typically encounter the consequences only after a contractor departure, system retirement, or breach review, at which point dormant risk 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, NIST Zero Trust (SP 800-207), NIST SP 800-63 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-02 | Addresses secret lifecycle and revocation gaps that create dormant access. |
| NIST CSF 2.0 | PR.AC-1 | Access rights must be managed across the identity lifecycle, not left idle. |
| NIST Zero Trust (SP 800-207) | SP 2 | Zero Trust requires continuous verification of access validity and necessity. |
| NIST SP 800-63 | IAL2 | Identity proofing and lifecycle assurance inform how dormant credentials are governed. |
| NIST AI RMF | GV.1 | Governance requires accountability for access that outlives its intended use. |
Bind NHI credentials to verified ownership and retire them when assurance lapses.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on August 15, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
