Dormant account

A dormant account is an identity that has not been used within a defined period but still retains active access. The risk is not only wasted licensing. Dormant access often becomes stale standing privilege, which makes offboarding, certification, and incident response harder to execute cleanly.

Expanded Definition

A dormant account is not simply an unused login. In NHI operations, it is an identity or service account that has gone inactive for a defined period while retaining valid credentials, permissions, and, often, trust relationships. That makes it materially different from a deprovisioned account, which should no longer be able to authenticate or access resources.

Definitions vary across vendors on the exact inactivity threshold, because one environment may treat 30 days as dormant while another uses 90 or 180 days. The operational question is not age alone, but whether the account still has standing access, whether its credentials still work, and whether anyone can explain its business purpose. This is why dormant accounts should be reviewed alongside entitlement data, credential rotation history, and ownership records, rather than as an isolated directory hygiene issue. The NIST Cybersecurity Framework 2.0 frames this as an access governance problem, not just an asset inventory concern. Dormancy becomes especially risky when the identity is tied to automation, CI/CD, or machine-to-machine access, where a rarely used account can still reach sensitive systems without human awareness.

The most common misapplication is treating inactivity as equivalent to decommissioning, which occurs when teams leave credentials enabled after the account stops being used.

Examples and Use Cases

Implementing dormant-account controls rigorously often introduces operational friction, requiring organisations to weigh reduced attack surface against the cost of validating whether an identity is truly obsolete.

• A service account for a retired application remains active in production and can still read configuration secrets because no one completed offboarding.
• An API key used by a batch job has not authenticated in months, but the identity still has broad write access and is never included in access reviews.
• A privileged automation account is left untouched after a migration, creating a hidden fallback path that attackers could discover during lateral movement.
• A dormant vendor integration is preserved for “just in case” use, even though the third-party relationship has ended and the token should have been revoked. NHIMG’s Ultimate Guide to NHIs highlights how often NHI lifecycle controls break down at offboarding.
• Security teams combine directory logs with guidance from NIST Cybersecurity Framework 2.0 to decide whether a dormant account should be disabled, rotated, or fully removed.

Why It Matters in NHI Security

Dormant accounts are dangerous because they create low-noise entry points: access that appears legitimate, has valid trust, and is often excluded from active monitoring. In NHI environments, that matters more than with human identities because service accounts, API keys, and agent credentials can be used at machine speed, outside normal working hours, and without interactive prompts. NHIMG reports that only 20% of organisations have formal processes for offboarding and revoking API keys, and that 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, underscoring how stale access becomes an exploitation path rather than a bookkeeping issue. The same body of research shows NHIs outnumber human identities by 25x to 50x, which means dormant accounts can accumulate faster than teams can audit them.

For governance, dormant accounts complicate certification, incident response, and privilege cleanup because no owner is ready to defend their existence. They also weaken Zero Trust assumptions by preserving standing access that no longer reflects current need. A dormant identity should be treated as a control failure until proven otherwise, and the combination of Ultimate Guide to NHIs guidance and the NIST Cybersecurity Framework 2.0 helps organisations translate that into lifecycle review, revocation, and continuous verification. Organisations typically encounter the real cost only after an incident review or unexpected access discovery, at which point dormant accounts become operationally unavoidable to address.

Related resources from NHI Mgmt Group

• What happens when a human uses an NHI account?
• What happened in the demo account left active in production scenario and what does it reveal?
• What makes a super NHI different from an ordinary service account?
• When does a service account become a compliance problem?