A dormant service account is a non-human identity that still exists and may still have access, even though the workload or process it supported is no longer actively used. These accounts are dangerous because they are easy to overlook, often retain permissions, and can be abused if not discovered and removed.
Expanded Definition
A dormant service account is not simply an old credential. It is a still-present non-human identity that may retain privileges, trust relationships, tokens, or automation hooks after the workload it supported has stopped being actively used. In NHI operations, that distinction matters because an account can be dormant from a business perspective while remaining live from an access-control perspective. Definitions vary across vendors, but NHI Management Group treats dormancy as a lifecycle state problem, not just an inactivity timer.
That lifecycle view aligns with NIST SP 800-53 Rev 5 Security and Privacy Controls, which emphasizes account management, access review, and controlled authorization. Dormant service accounts are especially risky when they are embedded in CI/CD, integrations, or legacy automation that no one fully owns. The most common misapplication is assuming a service account is safe because the application was retired, which occurs when decommissioning fails to include identity cleanup.
Examples and Use Cases
Implementing dormant-account removal rigorously often introduces operational friction, requiring organisations to weigh cleanup speed against the risk of breaking an inherited dependency.
- A payment-processing microservice is decommissioned, but its account still has vault access and can reach internal APIs.
- A scheduled export job is replaced, yet the original account remains in a secrets store and is still accepted by downstream systems.
- A legacy integration is retired after a migration, but the service account survives in IAM because no owner was assigned to revoke it.
- A dormant automation account is discovered during review of the 52 NHI Breaches Analysis, where overlooked non-human identities repeatedly appear as an entry point.
- An offboarded SaaS connector leaves behind a token-bearing account, similar to patterns discussed in the Dropbox Sign breach, where account lifecycle gaps amplified exposure.
Service-account governance also maps to the identity lifecycle guidance in Ultimate Guide to NHIs — What are Non-Human Identities, especially where discovery, rotation, and offboarding overlap.
Why It Matters in NHI Security
Dormant service accounts matter because inactivity does not equal safety. If an account remains enabled, an attacker who obtains its token, certificate, or API key may inherit privileges long after the original workload has vanished. This creates a hidden attack path that is hard to detect through ordinary application monitoring, especially when the account is no longer tied to an active business owner. NHI Management Group research shows that only 5.7% of organisations have full visibility into their service accounts, which means most enterprises cannot confidently say which accounts are still needed, which are merely idle, and which are truly abandoned.
That visibility gap becomes more dangerous when combined with weak secret hygiene and incomplete offboarding. Organisations typically encounter the impact only after a breach, audit finding, or failed incident response, at which point dormant service account cleanup becomes operationally unavoidable to address.
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 address the attack and risk surface, while NIST CSF 2.0, NIST SP 800-63 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 | Dormant accounts are a core NHI lifecycle and inventory risk. |
| NIST CSF 2.0 | PR.AC-1 | Account lifecycle control is central to access governance. |
| NIST SP 800-63 | Lifecycle assurance for digital identities depends on timely deprovisioning. | |
| NIST Zero Trust (SP 800-207) | Zero Trust requires explicit, current authorization for every identity. |
Tie service-account deprovisioning to authoritative offboarding and ownership records.
