Ghost account

What a ghost account actually represents

A ghost account is not just an unused login, it is an access relationship that has outlived the person or role it was created for. That makes it different from a dormant but intentionally retained account, because the security problem is the lack of a current owner, current business justification, or current governance oversight.

The term is often used where offboarding, transfer, or recertification failed. In practice, the account may still have valid permissions, active sessions, or linked tokens, so the exposure is not simply theoretical. The key issue is that the organisation can no longer reliably explain why the access exists or who is accountable for it.

Why ghost accounts persist in organisations

Ghost accounts usually appear when identity lifecycle processes are fragmented across HR, IT, application owners, and third-party systems. An employee leaves, but the account remains because deprovisioning is delayed, the system is not integrated into the main identity workflow, or nobody owns the cleanup step. Shared administration, service exceptions, and legacy platforms make the problem harder to see.

They also persist when organisations treat account creation as a one-time event rather than a lifecycle that must end cleanly. If access reviews are shallow, stale accounts blend into the background and remain invisible until an audit, incident, or directory cleanup exposes them.

Why ghost accounts are dangerous

Ghost accounts create hidden entry points that attackers and insiders can abuse if the credentials, sessions, or linked access paths remain valid. Even when no one is actively using the account, it can still hold permissions that bypass current approval logic or monitoring expectations.

They also undermine trust in identity data. If the directory still contains accounts that should not exist, then access reviews, least-privilege decisions, and audit evidence all become less reliable. The result is not only excess access, but uncertainty about the real attack surface.

How organisations should think about ghost-account remediation

Ghost-account cleanup is best treated as an identity governance and access hygiene problem, not a one-off housekeeping task. The practical question is whether each account still maps to a current person, approved role, or legitimate service need, and whether that mapping is being checked continuously rather than only during an audit.

Where a ghost account is found, the safest response is to confirm ownership, business need, and downstream dependencies before disabling it. That matters because some stale-looking accounts are actually tied to applications, automation, or shared functions, and those require deliberate replacement rather than blunt deletion. The broader access review discipline described in CIS Controls v8 is relevant here because account inventory, access control, and audit logging are the controls that surface this class of problem.

Risk and Threat Considerations

Ghost accounts matter because they preserve access that no longer has an obvious business owner, which weakens both prevention and detection. They are especially risky when the account still has broad entitlements, privileged roles, or trusted relationships that were never revoked after departure or role change.

Failure mechanism: Offboarding gaps, stale permissions, and incomplete recertification leave valid access paths in place after the legitimate user relationship has ended.

Impact: An attacker, former user, or overlooked automation path can exploit the account for unauthorised access, lateral movement, or audit evasion, while the organisation loses confidence in its identity inventory.

Practitioner Guidance

What to watch for: Focus on accounts with no active owner, no recent business justification, or no clear linkage to current employment, vendor status, or system dependency. Those are the accounts most likely to survive normal review because they look technically valid even when they are operationally obsolete.

Governance implication: Ownership should be explicit at the account level, not implied by a directory entry or a departed employee record. A ghost account is usually a sign that lifecycle responsibility is split too loosely across HR, IAM, application teams, and security operations.

Related resources from NHI Mgmt Group

• Why do ghost logins increase the risk of persistence after an account is compromised?
• 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?