A dormant workload identity is a non human identity that exists in an environment but is rarely used or no longer actively needed. These identities often remain trusted even after the workload changes, which makes them a hidden security liability. Dormancy is especially dangerous when the account still has elevated permissions.
What Makes a Workload Identity “Dormant”
A dormant workload identity is not simply unused once; it is an identity that has outlived the workload pattern it was created for, or is used so infrequently that ownership, purpose, and access assumptions drift over time. The security issue is not dormancy itself, but the gap between what the identity can still do and what the environment actually needs.
That drift matters because workload identities often sit inside automation, integrations, and service-to-service paths that are not reviewed as visibly as human access. When the workload changes, the old identity may continue to exist with the same trust relationship, creating a stale control surface that attackers can abuse if they find it.
Why Dormant Identities Become Security Debt
Dormant workload identities accumulate because systems are replaced, pipelines are refactored, cloud resources are recreated, and ownership becomes unclear. A dormant identity can still be authenticated, still hold permissions, and still be reachable through scripts, secrets, or references that were never fully removed. NHIMG’s Top 10 NHI Issues treats inactive accounts, visibility gaps, and excessive permissions as recurring patterns, which is exactly why dormant identities deserve explicit lifecycle attention.
The hardest part is that dormancy is often invisible until something breaks or is abused. Inventory tools may show the identity exists, but not whether it is still needed, whether it has valid business ownership, or whether its current permissions match the workload it was originally created for. That is where dormant identities become security debt rather than harmless clutter.
How Dormancy Intersects With Privilege, Secrets, and Reachability
A dormant workload identity is most dangerous when it retains elevated permissions, long-lived secrets, or access to sensitive systems. Even if it is rarely used, a single valid credential can provide a durable foothold for abuse, especially when the identity is tied to automation that still trusts the same token, key, or certificate. The OWASP Non-Human Identity Top 10 directly frames overprivilege, secret leakage, long-lived secrets, and improper offboarding as core NHI risks.
Dormant identities also create hidden reachability. An identity may be “inactive” from an operator’s point of view while still being accepted by downstream services, CI/CD jobs, SaaS integrations, or legacy dependencies. That mismatch is what turns stale access into a live exposure path, because compromise only needs one path that still works.
When Dormancy Becomes a Lifecycle and Governance Problem
Dormant workload identities are a lifecycle issue as much as an access issue. They need ownership, expiry expectations, and a clear removal path, because “rarely used” is not the same as “safe to keep.” NHI governance guidance such as Ultimate Guide to NHIs, Key Challenges and Risks and Ultimate Guide to NHIs is useful here because it ties visibility, lifecycle, and access governance together instead of treating them as separate chores.
From a practitioner perspective, the key question is whether the identity still has a current business purpose. If the answer is unclear, the safest assumption is that the identity is no longer justified until someone can prove otherwise. Dormancy without ownership is a warning sign that the control has drifted out of operational accountability.
Risk and Threat Considerations
Dormant workload identities are attractive because they are easy to overlook and often retain enough trust to be useful to an attacker. If the secret, token, or certificate is still valid, an adversary may not need to defeat primary controls at all, only locate and reuse a neglected credential or exploit a service that still accepts it.
Failure mechanism: The identity survives workload change or decommissioning, keeps its permissions, and remains usable through a still-valid secret or trust relationship.
Impact: Attackers can use the dormant identity for unauthorized access, privilege abuse, lateral movement, or persistence, especially when the account is overprivileged or poorly monitored.
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 addresses the attack and risk surface, while NIST SP 800-53 Rev 5, CIS Controls v8, OWASP ASVS 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-01 — Improper Offboarding | Dormant identities are often leftover after workloads change or retire. |
| NHI-05 — Overprivileged NHI | Dormant identities are risky when they retain elevated permissions. | |
| NHI-07 — Long-Lived Secrets | Dormant identities remain exploitable when their secrets stay valid for long periods. | |
| Recommendation — Remove unused workload identities and revoke their access paths when the workload is no longer active. Reduce dormant identities to the minimum permissions needed or disable them entirely. Shorten secret lifetimes and rotate or retire credentials tied to idle workload identities. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Dormant identities stay dangerous when authenticators and secrets are not retired. |
| AC-2 — Account Management | Dormant identities are an account lifecycle and deprovisioning problem. | |
| AC-6 — Least Privilege | Dormant identities are most dangerous when their permissions exceed current need. | |
| Recommendation — Manage authenticator lifecycle so unused workload credentials are revoked or rotated promptly. Periodically review workload accounts and disable or remove those no longer needed. Constrain workload identities to the minimum access required for the active use case. | ||
| CIS Controls v8 | CIS-5 — Account Management | Dormant workload identities require inventory, review, and timely removal from service. |
| Recommendation — Inventory non-human accounts and disable or remove those that no longer have a valid purpose. | ||
| OWASP ASVS | V8 — Authorization | Dormant service identities matter when authorization still grants them access. |
| V9 — Self-contained Tokens | Dormant identities often depend on tokens that remain valid too long. | |
| Recommendation — Verify that stale application credentials cannot retain access beyond their intended scope. Enforce token expiry and revocation so inactive identities cannot keep using old tokens. | ||
| NIST CSF 2.0 | ID.AM-01 — Inventories of Physical Devices and Systems | Dormant workload identities depend on knowing what exists before you can retire it. |
| Recommendation — Maintain an accurate inventory of workload identities and remove records that no longer map to active systems. | ||
Practitioner Guidance
Why practitioners should care: Dormant workload identities should be treated as lifecycle control failures, not housekeeping issues. The operational question is whether each identity still has a current owner, a current workload dependency, and a current reason to exist.
What to watch for: Pay attention to identities that are rarely authenticated, tied to deprecated workloads, or still carrying broad permissions after an application or integration has changed. Those are the identities most likely to hide an exposure path.
Practitioner takeaway: If you cannot explain why a workload identity still exists and what it still needs to access, it is already past its safe lifecycle.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 25, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
