Dormant non-human identities are risky because they can retain active permissions long after their original purpose has ended. If one is compromised, an attacker may inherit persistent access to sensitive resources without triggering obvious user activity. The risk is amplified when these identities remain linked to secrets, privileged roles, or critical systems.
Why Dormant Non-Human Identities Become Security Problems
Dormant non-human identities are more than unused accounts. Their real risk comes from the permissions, secrets, and trust relationships they may still carry after the original workload, integration, or service has moved on. A dormant identity can look low priority in inventory reviews while still functioning as a valid access path into production systems, data stores, CI/CD pipelines, or third-party services.
That mismatch matters because access risk is shaped by privilege and reach, not just by recent activity. A dormant identity often evades normal behavioural notice because it is not supposed to generate human-style logins or interactive use. When teams assume inactivity means harmlessness, they tend to underweight stale access paths that remain fully usable by an attacker or a careless internal actor. For broader context on common failure patterns, Ultimate Guide to NHIs is the most useful starting point.
In practice, many security teams discover dormant identities only after an incident review shows that the account was still authorised long after anyone believed it had been retired.
How Dormancy Amplifies Access Path Risk
The practical problem is not that the identity is idle; it is that the identity may still be trusted. In many environments, non-human identities are created for a narrow purpose, then left behind with inherited roles, embedded tokens, certificate trust, or service-to-service permissions that were never removed. Over time, that creates a hidden access layer that is easy to forget and difficult to challenge during ordinary reviews.
From an attacker’s perspective, dormant accounts are attractive because they often combine three properties: valid authentication material, weak visibility, and low scrutiny. If a secret is still active, compromise does not require breaking into a user session. If the identity is linked to automation, the resulting actions may blend into expected machine traffic. If it still has privileged reach, the blast radius can be much larger than its dormant label suggests. OWASP’s OWASP Non-Human Identity Top 10 is a useful companion reference for the access and lifecycle issues that make these identities hard to govern.
- Inactive identities can retain API keys, certificates, or tokens that are still accepted by target systems.
- Legacy service accounts may bypass recent access reviews because ownership has shifted or disappeared.
- Privileges often remain broader than the original use case, especially when roles were granted for convenience.
- Monitoring may not flag misuse quickly because machine identities do not produce the same signals as users.
NHIMG research also shows why this matters at scale: only 5.7% of organisations report full visibility into their service accounts, which means many dormant identities remain both valid and poorly governed. These controls tend to break down when old automation paths are still accepted by downstream systems because revocation was never fully propagated.
When “Unused” Becomes “Unowned”
The biggest operational tradeoff is that long-lived machine access is convenient until nobody can confidently say who owns it, why it still exists, or what would break if it were removed. That ownership gap is where dormant identities become especially risky. Best practice is evolving toward tighter lifecycle control, but there is no universal standard for when every dormant identity must be deleted versus quarantined, because some production dependencies are harder to untangle than they first appear.
Edge cases usually involve shared automation, third-party integrations, and break-glass style service access. A dormant identity may be harmless in one system and critical in another if it still authenticates to a management plane, artifact store, or secrets repository. The risk also changes when the identity is tied to a federated trust relationship, because the account may not be the only access path that needs to be removed.
That is why the status alone is misleading. Dormancy can signal neglect, but the access risk comes from what remains attached to the identity: credentials that still validate, permissions that were never reduced, and dependencies that were never documented. For practitioners, the right question is not whether the account has been used recently, but whether it can still do meaningful harm if it is reused today.
Risk and Threat Considerations
Dormant non-human identities create exposure because they often preserve standing access after the business reason for that access has ended. That leaves a control gap in which a forgotten account can still authenticate, reach sensitive systems, and operate without the normal review that active accounts receive.
Failure mechanism: The risk materialises when retained secrets, cached trust, or overbroad roles remain valid after decommissioning or task change. An attacker who obtains the secret, certificate, or token does not need to compromise a live user workflow; they can reuse the dormant identity as a quiet entry point and move through systems that still trust it.
Impact: The consequence is unauthorised access that is harder to detect and often broader than expected. That can lead to data exposure, privilege abuse, lateral movement, service manipulation, or persistence in critical environments long after the identity should have been removed.
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 and MITRE ATT&CK address the attack and risk surface, while CIS Controls v8 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 Lifecycle and Secrets Hygiene — Lifecycle and Secrets Hygiene | Dormant NHI risk centers on stale access, orphaned secrets, and offboarding failures. |
| Recommendation — Revoke dormant identities and rotate any secrets that still validate. | ||
| CIS Controls v8 | 6 — Access Control Management | Dormant identities retain access paths that should be reviewed, removed, or limited. |
| 5 — Account Management | Account ownership, provisioning, and deprovisioning determine whether dormancy becomes exposure. | |
| Recommendation — Review and disable unused accounts before they become reusable access paths. Track ownership and deprovision stale machine accounts on a defined schedule. | ||
| NIST CSF 2.0 | PR.AA — Identity Management, Authentication, and Access Control | Dormant identities remain risky when authentication and access are not continuously governed. |
| Recommendation — Continuously validate machine identity access and remove unnecessary entitlements. | ||
| MITRE ATT&CK | T1078 — Valid Accounts | Attackers often reuse dormant identities because they still authenticate successfully. |
| Recommendation — Hunt for valid-account abuse where stale credentials still grant access. | ||
Practitioner Guidance
What to prioritise: Start with dormant identities that still hold production access, especially those linked to secrets, administrative roles, or third-party integrations. Age alone is not the right filter; reach and privilege are what determine exposure.
What to verify: Confirm whether each dormant identity still authenticates successfully, whether its credentials are still valid, and whether any downstream system depends on it in ways the inventory does not show. If ownership is unclear, treat the identity as an active risk until proven otherwise.
Decision rule: If a dormant identity can still reach a sensitive system, prioritise revocation planning and blast-radius reduction before you decide whether the account is merely redundant. If removal would break a process, document the dependency and constrain the access rather than leaving it untouched.
Practitioner takeaway: Dormancy should never be interpreted as safety; the meaningful question is whether the identity still has valid, privileged, and unobserved access paths that someone else could reuse.
