A non-human identity that remains active after its business purpose has ended or paused. In practice, dormant credentials create standing access that may still authenticate successfully, which makes them a persistent security and audit risk.
What Makes a Machine Identity Dormant
A machine identity becomes dormant when it is still present and often still capable of authenticating, but the business process, workload, or integration it supported has stopped, changed, or been paused.
That state is especially important because “inactive” does not mean harmless. Dormant identities can retain valid secrets, certificates, tokens, or roles long after the original use case has ended, so they may continue to provide standing access unless they are discovered and removed.
Why Dormant Machine Identities Matter
Dormancy creates a gap between business intent and technical reality. The organisation may believe an integration has been retired, while the underlying credential or trust relationship still exists and can be used by a workload, script, or attacker who finds it.
This is why dormant identities are not just a housekeeping issue. They sit in the broader problem space of identity lifecycle, ownership, and credential hygiene, which is why NHIMG’s Ultimate Guide to NHIs treats lifecycle and offboarding as core security concerns for machine identities.
In practice, dormancy often appears after application decommissioning, vendor changes, environment migrations, or long project pauses. If those transitions are not paired with revocation, the identity can become an invisible access path.
Common Ways Dormant Identities Are Created
Dormant machine identities usually emerge from ordinary operational change, not exotic failure. A service account may outlive the service it supported, an API credential may remain valid after a system replacement, or a certificate may continue to authenticate after the integration has stopped being used.
They are also common when ownership is unclear. When no team feels responsible for a workload or its credentials, retirement steps are easy to miss, which is why NHI Ownership and Accountability Guide is directly relevant to preventing identities from becoming forgotten assets.
The problem is compounded by shared credentials, hardcoded secrets, and ad hoc automation. These patterns make it difficult to know which identities are still active, which are intentionally paused, and which are simply abandoned.
How Dormancy Changes Security and Audit Outcomes
From a security perspective, dormant identities widen the attack surface because they preserve trust without a live business need. A credential that still works after its intended use has ended can be abused for unauthorized access, lateral movement, or quiet persistence.
From an audit perspective, dormancy creates a control mismatch. Inventory, access review, and offboarding records may show a system as retired while the live credential state says otherwise, which is why dormant identities are often detected only after review, incident response, or reconciliation work.
NHIMG’s Service Account Security Guide and Guide to NHI Rotation Challenges both support the broader operational point: unused or stale credentials become dangerous when lifecycle controls are weaker than the systems they protect.
How Dormant Machine Identities Are Usually Managed
The practical response is to treat dormancy as a lifecycle state that must be actively owned, not as an assumption that something is “probably unused.” That means the identity, its secrets, its certificates, and its authorization paths should all be tied back to a current business service and a named owner.
Good management also depends on discovery and regular review. Top 10 NHI Issues is useful here because it frames inactive accounts, orphaned identities, and excessive permissions as recurring patterns rather than edge cases.
For machine identity estates that rely on certificates or workload trust, lifecycle automation matters as much as inventory. Machine Identity, PKI and Certificate Lifecycle Guide is relevant because expiry, renewal, and revocation are often the mechanisms that prevent dormant trust from lingering indefinitely.
Where identity systems are integrated across cloud, Kubernetes, or service-to-service flows, dormant access is best handled through explicit offboarding and periodic access validation rather than by hoping a stale secret will be forgotten.
Risk and Threat Considerations
Dormant machine identities are risky because they preserve authenticated access after the business need has ended. That creates a hidden control gap: the organisation may stop watching an identity just when it remains capable of being used.
Failure mechanism: Secrets, tokens, certificates, or role bindings remain valid after the workload or process is no longer active, allowing a stale identity to be reused by insiders, automation, or attackers who discover it.
Impact: The result can be unauthorized access, persistence, privilege abuse, or audit findings that show access was never fully removed even though the underlying business process was retired.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 provides the primary governance reference for this term.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Dormant identities persist through unmanaged secrets and credentials. |
| AC-2 — Account Management | Dormant machine identities are accounts that outlive their business purpose. | |
| AC-6 — Least Privilege | Dormant identities are dangerous when they retain standing access beyond need. | |
| Recommendation — Revoke unused authenticators and enforce expiry, rotation, and revocation. Inventory, disable, and remove stale accounts when the service is retired. Reduce permissions on inactive identities and remove unnecessary standing access. | ||
Practitioner Guidance
Why practitioners should care: Dormancy should be treated as a lifecycle defect, not a harmless leftover. If an identity no longer maps to a live service, it should move quickly toward revocation, not remain as a tolerated exception.
Common misunderstanding: Teams often equate “not being used recently” with “safe to keep.” For machine identities, that assumption is weak because unattended credentials can stay valid and can be discovered long after the original owner has moved on.
Practitioner takeaway: The safest default is to require a current owner, a current purpose, and a current expiry or revocation plan for every machine identity.