A retired non-human identity that still retains access because revocation or cleanup failed. In agent environments, ghost identities are especially risky because they can continue to call systems long after the business owner believes the asset is gone.
What Ghost Identity Means in Practice
A ghost identity is not just an unused account. It is a retired non-human identity that still has standing access because revocation, deletion, or cleanup never fully completed. That makes it a lifecycle failure in identity governance, not simply an inventory problem, because the identity can continue to authenticate and act after the business believes it is gone.
In agentic environments, the danger rises because software agents can keep calling APIs, queues, cloud services, and internal tools on behalf of an asset that no longer has an owner. The trust relationship outlives the asset, which can create silent access paths that are difficult to notice until they are abused or discovered during a review.
Why Ghost Identities Persist
Ghost identities usually emerge when offboarding is fragmented. A system, workload, or agent is retired in one place but its credentials, role bindings, tokens, certificates, secrets, or delegated permissions are not fully revoked everywhere else. Partial automation can make this worse if provisioning is easy but deprovisioning depends on manual follow-up.
They also persist when ownership is unclear. If no team is explicitly responsible for an identity’s lifecycle, cleanup can stall across IAM, cloud, application, and platform teams. The problem is especially common where identities are created quickly for integration, automation, or temporary projects and then lose a clear business owner.
Some ghost identities are intentional at first, such as service accounts and agent credentials created for a rollout or migration. Over time, however, their original purpose fades, their permissions remain, and they become stale access paths that no one actively monitors.
Security Consequences of Unrevoked Access
A retained non-human identity can keep reaching systems long after the asset it represented is retired, renamed, or repurposed. That means an attacker who discovers the credential, token, key, or certificate may inherit access that defenders no longer expect to exist. The risk is not only unauthorized access, but also undetected persistence through a legitimate trust relationship.
Ghost identities are particularly dangerous because they can undermine least privilege and access reviews. A dormant but valid identity may still hold broad entitlements, accept old tokens, or remain trusted by downstream systems, which gives an intruder a stable foothold that does not look like a new compromise.
This is one reason OWASP Non-Human Identity Top 10 treats lifecycle failure, secret leakage, overprivilege, and reuse as related risks. The issue is not only whether the identity exists, but whether its access has truly ended.
How Organisations Find and Remove Ghost Identities
Finding ghost identities starts with joining identity inventory to application and asset inventory. Organisations need to know what was decommissioned, what integrations still depend on it, and which credentials, keys, or certificates are still valid. Vendor consoles, cloud IAM views, CI/CD systems, and secret stores often need to be checked together because no single system has the full picture.
Removal also needs to be verified, not assumed. If a retired agent, workload, or service account once had access to internal and external systems, the team should confirm that the trust chain is broken everywhere, including federated links, role assignments, API credentials, and any backup or failover path that might still accept the identity.
For workload and agent identity design, SPIFFE workload identity specification is a useful reference point because it emphasises explicit workload attestation and identity binding rather than implicit trust in long-lived credentials. For broader governance of identity lifecycle and ownership, Identity Security Programme Guide provides a practical model for scope, RACI, roadmap, and accountability.
Where organisations need a wider control lens, NIST SP 800-53 Rev 5 Security and Privacy Controls and NIST Cybersecurity Framework 2.0 both support the governance, inventory, and protection activities that should expose stale access before it becomes a live control failure.
What Good Cleanup Looks Like
Good cleanup is a repeatable lifecycle process, not a one-time purge. A retired non-human identity should be removed from every place it can authenticate, every place it is authorised, and every place it is documented or monitored. The practical test is simple: if the asset is gone, the access path should be gone too.
That usually means coordinating revocation across identity providers, cloud roles, application permissions, secret managers, CI/CD pipelines, certificates, and service ownership records. It also means preserving evidence that the identity was decommissioned so future audits do not rediscover the same access path as a surprise.
Top 10 NHI Issues is a useful companion for understanding the recurring failure patterns that make ghost identities possible, including stale accounts, credential hygiene gaps, and privilege abuse. IAM and Identity Provider Buyer's Guide is also relevant when organisations are deciding whether their identity platform supports lifecycle controls strongly enough to prevent this class of drift.
Risk and Threat Considerations
Ghost identities create a hidden persistence layer because the access path looks legitimate even after the business asset has been retired. That makes them attractive to attackers who look for forgotten credentials, stale service accounts, or unused agent trust relationships that still work.
Failure mechanism: Revocation gaps leave valid authentication material, permissions, or trust bindings active after retirement, so the identity can still be used for authorised-looking access.
Impact: Attackers or internal misuse can exploit the stale trust path for persistence, lateral movement, data access, or covert service abuse, while defenders may not realise the identity still exists.
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 and MITRE ATT&CK address the attack and risk surface, while NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 — Improper Offboarding | Ghost identities are retired NHIs that were not fully revoked. |
| NHI-05 — Overprivileged NHI | Stale identities often keep broader access than they still need. | |
| NHI-07 — Long-Lived Secrets | Ghost identities often persist because secrets remain valid after retirement. | |
| Recommendation — Revoke every credential, role, and trust path when a non-human identity is retired. Review retained non-human entitlements and remove excess privilege before decommissioning completes. Shorten secret lifetime and ensure decommissioning revokes tokens, keys, and certificates. | ||
| NIST SP 800-53 Rev 5 | AC-2 — Account Management | This term is fundamentally about lifecycle control and account disposition. |
| IA-5 — Authenticator Management | Ghost identities persist when authenticators are not fully revoked or rotated. | |
| AC-6 — Least Privilege | Stale identities become dangerous when residual access is broader than necessary. | |
| Recommendation — Track creation, use, disabling, and removal of every account and service identity. Rotate or invalidate authenticators and secrets when an identity is retired. Limit retained access paths to the minimum needed during decommissioning. | ||
| NIST CSF 2.0 | ID.AM-01 — Physical devices and systems inventoried | Ghost identities are exposed when identity-linked assets are not fully inventoried. |
| GV.OC-03 — Legal, regulatory, and contractual requirements are understood | Lifecycle ownership and accountability are needed to govern retirement obligations. | |
| PR.AA-01 — Identities and credentials are issued, managed, verified, revoked, and audited | This directly describes the lifecycle failure behind ghost identities. | |
| Recommendation — Maintain an authoritative inventory of systems and identities that can still authenticate. Assign ownership for identity retirement and deprovisioning obligations. Verify that revocation and audit steps are completed for every retired identity. | ||
| MITRE ATT&CK | T1078 — Valid Accounts | A ghost identity is a valid account that remains usable after it should be removed. |
| Recommendation — Hunt for stale but still-valid accounts and revoke them before they are abused. | ||
Practitioner Guidance
What to watch for: Treat any decommissioned system, agent, or integration as incomplete until you can prove its identity has been revoked everywhere it had standing access. A ghost identity is usually a coordination problem first and a detection problem second.
Governance implication: Assign a named owner for every non-human identity, including the person or team responsible for retirement, revocation, and periodic validation. If no owner can be identified, the identity is already at elevated risk of becoming a ghost.
Practitioner takeaway: The safest deprovisioning model is one where retirement of the asset and retirement of the identity are treated as the same change.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 31, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org