What should organisations do first when orphaned or ghost accounts may still be active after staff changes?

Start by inventorying all accounts tied to users, applications, and remote access, then identify anything left open after provisioning or deprovisioning events. Prioritise termination cleanup because primary credentials are often disabled while secondary access persists in critical applications. Remove or revoke accounts that no longer have a legitimate owner, and confirm that the offboarding process covers every access path, not just the obvious one.

Where orphaned accounts usually hide after staff changes

The first job is to build a complete account inventory across people, applications, and remote access, then compare that inventory to recent provisioning and deprovisioning events. Orphaned or ghost accounts are often the ones that survive the obvious HR offboarding step but remain attached to a secondary login, a service path, or an older application that was never folded into central review.

That inventory should include human user accounts, application accounts, shared access paths, vendor connections, and any identity linked to remote administration. In practice, the question is not whether a former employee’s main account was disabled, but whether any other account or token still grants reach into production systems, sensitive data, or administrative tools.

Why termination cleanup has to come before broader access review

Cleanup should be prioritised before normal periodic recertification because stale access becomes harder to spot once staff changes have already occurred. The highest-value finding is usually not a missing record, but an active credential that still authenticates somewhere important after the business believes the person has left.

Primary credentials are often removed first, while secondary access persists in critical applications, scripts, integrations, or remote access tooling. That creates a blind spot: the joiner-mover-leaver process may look complete on paper even when the actual access path still works.

A practical cleanup sequence is to identify the account, confirm the owner or business purpose, determine whether it is tied to a leaver event, and revoke or disable anything without a legitimate current purpose. For account lifecycle and ownership discipline, NHIMG’s NHI Lifecycle Management Guide, IAM and IGA Basics, and Joiner-Mover-Leaver (JML) Guide all support the same operational principle: deprovisioning must cover the full access lifecycle, not just the obvious login.

How to make offboarding cover every access path, not just the obvious one

Offboarding fails when organisations treat account closure as a single event instead of a set of dependent actions. The cleaner approach is to verify every path that could still be used by the former worker, contractor, or service owner, including application-native accounts, remote access, privileged access, and any credentials embedded in automation.

That means confirming who owns each account, whether the account is still required, and whether the account is being used by a process that outlived the person. The account may be technically active even when the human identity is gone, so ownership and purpose matter as much as username status.

NHIMG’s NHI Ownership and Accountability Guide is useful here because orphaned access is usually an ownership failure before it becomes a technical one. The control objective is simple: no active account should be left without a clear owner, a valid business reason, and a documented review path.

Risk and Threat Considerations

Orphaned accounts create residual access that attackers, former staff, and forgotten integrations can all exploit. The risk is not limited to account takeover, because stale access often survives in the exact systems that matter most, such as remote access, administrative tools, and critical applications.

Failure mechanism: Primary offboarding disables the most visible account, but a secondary login, shared account, service credential, or remote access path remains active and still authenticates successfully.

Impact: Unowned access can enable unauthorized entry, privilege abuse, data exposure, persistence after termination, and delayed detection because the account may look legitimate in logs.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

NIST SP 800-53 Rev 5 sets the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.

Framework	Control / Reference	Relevance
NIST SP 800-53 Rev 5	IA-5 — Authenticator Management	Orphaned accounts persist when credentials are not fully revoked.
	AC-2 — Account Management	The question is about discovering and removing unused or ownerless accounts.
	AC-6 — Least Privilege	Residual access is dangerous when secondary accounts retain more access than needed.
Recommendation — Revoke, rotate, and track authenticators so departed users cannot keep access. Inventory, disable, and remove accounts that no longer have a valid owner. Reduce standing access so any leftover account has minimal reachable privilege.
ISO/IEC 27001:2022	A.5.16 — Identity management	Identity records and ownership must stay aligned with employment changes.
	A.5.18 — Access rights	The issue is whether access rights remain after staff changes.
Recommendation — Keep identity records current and remove stale or orphaned access promptly. Review and withdraw access rights when the business need or role ends.

Practitioner Guidance

What to prioritise: Start with accounts that can reach production, remote access, or administrative interfaces, because those paths carry the highest blast radius if ownership is unclear. Then work outward to lower-risk application accounts and legacy access paths.

What to verify: For each account, verify who owns it, what system it reaches, whether it was created for a current business process, and whether offboarding removed every associated credential or login method. If any answer is uncertain, treat the account as a cleanup candidate rather than a benign exception.

Practitioner takeaway: The real control is not “disable the user,” but “prove there is no remaining live path from a departed person to a system that still matters.”