A ghost account is an account that remains active after the person who owned it has left or no longer needs access. These accounts create hidden entry points, complicate audits and often persist because they sit outside the primary identity governance workflow.
Expanded Definition
A ghost account is not just an unused login. In NHI and IAM operations, it is an identity that still has active entitlements after the original business need has ended, often because joiner-mover-leaver workflows, application ownership, or deprovisioning controls did not capture it. Definitions vary across vendors, but the operational meaning is consistent: the account is still reachable, still trusted by systems, and still capable of action even though it should have been removed.
This matters because ghost accounts blur the line between legitimate access and forgotten access. They may appear as service account, shared admin profiles, stale contractor credentials, or application-linked identities. The key issue is persistence without accountability. In a zero trust model, this conflicts with the expectation that access be continuously verified and revoked when no longer required, a principle aligned with the NIST Cybersecurity Framework 2.0 and the broader lifecycle discipline described in the Ultimate Guide to NHIs.
The most common misapplication is treating a disabled human mailbox as proof that all related access has been removed, which occurs when downstream service, API, or privileged accounts are not independently reviewed.
Examples and Use Cases
Implementing ghost account cleanup rigorously often introduces inventory and ownership overhead, requiring organisations to weigh reduced attack surface against the time needed to trace legacy access paths.
- A former engineer leaves, but their admin account remains enabled in a CI/CD system because the application team, not HR, owns the deprovisioning step.
- A contractor’s VPN access is removed, yet a linked API key still authenticates to production because secrets rotation is not tied to offboarding.
- A retired service account continues to run scheduled jobs because the workload depends on it, but no owner can explain why it still exists.
- A cloud database has a dormant break-glass account that was created during an incident and never formally retired after the recovery period.
- Audit teams find that a privileged identity appears in logs but has no current ticket, approver, or system owner, making the account effectively invisible to governance.
These cases are closely related to the visibility and lifecycle failures highlighted in the Ultimate Guide to NHIs, and they are increasingly measured against identity governance expectations discussed in the NIST Cybersecurity Framework 2.0.
Why It Matters in NHI Security
Ghost accounts are a governance problem because they create durable, low-friction access paths that defenders may not know exist. In NHI environments, those paths can be more dangerous than obvious misconfigurations because they are often embedded in automation, pipelines, and privileged workflows. NHIMG research shows that only 20% of organisations have formal processes for offboarding and revoking API keys, and 5.7% have full visibility into their service accounts, which helps explain why inactive identities keep surviving well past their intended use.
When ghost accounts persist, they expand blast radius, weaken audit reliability, and make incident response slower because responders must first determine whether an account is legitimate, abandoned, or compromised. This is especially risky where excessive privilege already exists, since a forgotten account can still act with broad authority. The Ultimate Guide to NHIs shows how persistent identities and poor revocation discipline undermine zero trust and lifecycle controls, while the NIST Cybersecurity Framework 2.0 reinforces the need for continuous access governance and asset awareness.
Organisations typically encounter ghost accounts only after a breach, audit finding, or failed deprovisioning review, at which point the term 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 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 | Ghost accounts reflect missing lifecycle governance and identity inventory. |
| NIST CSF 2.0 | PR.AA-01 | Identity lifecycle and access validation are central to eliminating stale access paths. |
| NIST Zero Trust (SP 800-207) | Zero trust requires continuous access verification, not trust in lingering accounts. |
Treat every persistent account as untrusted until its current need and authority are proven.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on June 24, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
