Why do orphaned accounts keep appearing after employee terminations?

Why This Matters for Security Teams

orphaned account are not just cleanup defects. They are evidence that offboarding is too narrow, usually ending at HR termination and the primary directory while other authenticating systems keep working. That creates residual access in SaaS apps, legacy platforms, API gateways, CI/CD tools, and shared admin paths. NHI Mgmt Group’s Top 10 NHI Issues shows how often organisations miss the broader identity surface, and the NIST Cybersecurity Framework 2.0 reinforces that identity governance must span the full lifecycle, not just account creation and password resets.

The practical risk is privilege persistence. A terminated employee may no longer have directory access, but their tokens, SSH keys, app logins, delegated API access, or service-linked credentials can remain active long after the departure. In many environments, this is not a single failure but a chain of omissions across IT, security, SaaS owners, and platform teams. The result is a lingering access path that attackers can discover and reuse, especially when shared credentials or local accounts were never bound to central identity controls.

Only 20% of organisations have formal processes for offboarding and revoking API keys, which helps explain why residual access keeps reappearing after termination events. In practice, many security teams encounter orphaned accounts only after an audit, an incident, or a post-termination login alert, rather than through intentional lifecycle control.

How It Works in Practice

Effective offboarding has to treat identity as a lifecycle problem across every system that can authenticate independently. The primary directory should trigger a wider revocation workflow that touches SaaS tenants, privileged access stores, code repositories, VPNs, cloud consoles, ticketing systems, and any shared or local accounts tied to the departing worker. NHI Mgmt Group’s NHI Lifecycle Management Guide is useful here because it frames revocation, rotation, and ownership transfer as parts of one process.

In practice, the strongest controls are procedural and technical at the same time:

• Maintain an authoritative inventory of all accounts, tokens, keys, certificates, and delegated access linked to a person.
• Trigger deprovisioning from HR events, then verify revocation in downstream systems rather than assuming directory disablement is enough.
• Rotate secrets that cannot be deleted immediately, especially shared service credentials and legacy integrations.
• Use short-lived access where possible so expired authorisations self-limit the blast radius of missed revocations.
• Require application owners to confirm no hidden local accounts, contractor IDs, or emergency access paths remain active.

This aligns with the identity lifecycle emphasis in the NIST Cybersecurity Framework 2.0, which treats access management as an ongoing control, not a one-time event. It also matches the operational lesson in the Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs: if ownership, rotation, and revocation are not explicit, credentials survive the person who used them.

These controls tend to break down when business units own their own SaaS tools and no central system can verify whether local admin accounts or API keys were actually removed.

Common Variations and Edge Cases

Tighter offboarding often increases operational overhead, requiring organisations to balance speed of termination with validation of every downstream entitlement. That tradeoff becomes more visible in distributed environments, where many accounts are created outside the main IAM stack or are embedded in automation, scripts, and third-party integrations.

Some orphaned accounts are intentional, such as break-glass accounts, vendor support access, or shared operational identities. Current guidance suggests these should be rare, documented, time-bound, and reviewed separately from employee access. The risk is that exceptions become normal practice, especially in older platforms where per-user attribution was never designed in. In those environments, a terminated employee may still appear to own access in one system while the real credential lives in another system entirely.

Another common edge case is identity coupling. A worker may leave, but their access token, personal API key, or email-based login persists because the application does not support SCIM, central SSO, or reliable deprovisioning hooks. NHI Mgmt Group’s Top 10 NHI Issues is especially relevant where secrets and service identities outlive the human account that created them.

Best practice is evolving toward continuous access discovery, not periodic cleanup alone. Orphaned accounts keep appearing when organisations treat termination as an HR task instead of a full identity revocation event across the entire application estate.

Related resources from NHI Mgmt Group

• How should teams reduce the risk of orphaned service accounts and stale tokens?
• Who is accountable when orphaned apps keep running after an employee leaves?
• How can organisations prevent orphaned AI agents after employee turnover?
• Who is accountable when orphaned accounts and stale NHIs keep showing up in audits?