Dormant Credential

Expanded Definition

A dormant credential is a non-human identity artifact that still exists after the business process that created it has ended. That can include service accounts, API keys, OAuth tokens, certificates, and embedded secrets that remain technically valid even though no team intends to use them. In NHI governance, the key issue is not whether the credential is active from an operational standpoint, but whether it still has authentication power anywhere in the environment.

Definitions vary across vendors on whether a credential becomes “dormant” at the point of inactivity, retirement, or failed ownership reconciliation, so the practical test is lifecycle status plus residual access. This is closely related to secret hygiene and offboarding controls, but it is not the same as temporary inactivity. A dormant credential may sit unnoticed in code, a vault, a pipeline, or a legacy workload until someone discovers it during audit or incident response. The industry guidance in the OWASP Non-Human Identity Top 10 aligns with treating forgotten NHI artifacts as an exposure problem, not merely an inventory problem.

The most common misapplication is assuming a credential is harmless because the owning application was decommissioned, which occurs when revocation and dependency mapping were never completed.

Examples and Use Cases

Implementing dormant-credential controls rigorously often introduces inventory and revocation overhead, requiring organisations to weigh faster shutdown of old systems against the cost of tracing every dependency that might still rely on them.

• A legacy integration token remains in a CI/CD secret store after the deployment tool was replaced, and the token can still access production APIs until rotation or revocation occurs.
• A service account created for a retired reporting job still authenticates to cloud storage because the account was never disabled, a pattern discussed in the Guide to the Secret Sprawl Challenge.
• An application certificate is left valid after a workload migration, so an attacker who discovers it in backups can impersonate the old workload and reach internal services.
• An API key embedded in source control is no longer referenced by the application, but it still works because no one rebuilt the dependency map after the release.
• A cloud access key is abandoned after an engineer leaves, and the lack of timely offboarding turns a forgotten secret into an account takeover path, as seen in the LLMjacking: How Attackers Hijack AI Using Compromised NHIs research.

For lifecycle assurance, the identity assurance concepts in NIST SP 800-63 Digital Identity Guidelines are useful even when the credential is machine-issued, because the operational question remains whether the authenticator should still be trusted.

Why It Matters in NHI Security

Dormant credentials matter because they create hidden authentication paths that bypass normal change management. When a credential is forgotten, it often falls outside ownership review, rotation schedules, and incident monitoring. That makes it an ideal foothold for attackers who scan for stale secrets, old tokens, and unused service accounts that still authenticate. NHIMG research shows that 88.5% of organisations acknowledge that their non-human IAM practices lag behind or are merely on par with their human identity and access management efforts, which helps explain why dormant credentials persist across mature environments.

The risk is amplified in hybrid estates because a credential can be dormant in one system but still trusted in another through federation, cached trust, or overlooked automation. Controls from NIST SP 800-53 Rev 5 Security and Privacy Controls support revocation, access review, and configuration management, but practitioners still need explicit ownership for NHI lifecycle events. The most damaging failures usually appear after a breach review or audit discovers that the supposed decommissioning never removed the credential’s real access path. Organisations typically encounter unauthorized access only after an incident or audit, at which point dormant credential removal becomes operationally unavoidable to address.

Related resources from NHI Mgmt Group

• What is the difference between an identity, a credential, and a secret?
• What is credential injection risk and how does it occur?
• What is the most common mistake organisations make with NHI credential management?
• How do I respond to a confirmed NHI credential compromise?