How can organisations improve offboarding when accounts live in many systems?

They need an ownership graph that already links accounts to people across all connected applications, including legacy and non-standard systems. Offboarding then becomes a complete revocation process rather than a directory cleanup exercise. Where full automation is not yet possible, unresolved accounts should be flagged and handled explicitly before the leaver process closes.

Why This Matters for Security Teams

offboarding fails when teams treat it as a directory event instead of a full identity revocation problem. In modern estates, accounts live in SaaS apps, CI/CD tools, databases, vaults, and legacy systems that do not all report back to the directory. That leaves residual access, orphaned secrets, and shared service accounts behind after HR closes the case. NHI Management Group’s Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs shows why lifecycle control has to span every identity type, not just users.

The risk is not theoretical. The 2025 State of NHIs and Secrets in Cybersecurity reports that 91% of former employee tokens remain active after offboarding, which is exactly the kind of gap that turns a leaver process into an exposure window. The NIST Cybersecurity Framework 2.0 reinforces the need for asset and access governance across the full environment, not just the authoritative directory. In practice, many security teams discover unmanaged accounts only after a user has already left and an incident forces the search.

How It Works in Practice

The practical fix is an ownership graph that maps each person to every account, token, API key, and privileged relationship across connected systems. That graph should include the directory, but also the non-standard and legacy systems where normal SCIM or HR-driven automation often stops. NHI Management Group’s NHI Lifecycle Management Guide is useful here because it treats discovery, ownership, and revocation as one continuous control surface.

Once the graph exists, offboarding can run as a deterministic workflow:

• Identify all known accounts, secrets, roles, and delegated access linked to the leaver.
• Revoke or disable access in every connected system, not just the directory.
• Rotate any shared secrets or service credentials that may have been exposed.
• Flag unresolved systems for explicit manual closure before the offboarding case is marked complete.

Where possible, automate revocation through identity governance, secrets management, and workflow orchestration. Where automation is not possible, the control objective is still to force visibility and accountability. That means no silent exceptions and no assumption that a disabled employee record removes application access. The same logic applies to API keys and service accounts that were created under a person’s sponsorship but now operate independently. Best practice is evolving toward continuous entitlement discovery, because static spreadsheets age out almost immediately in environments with frequent app changes and decentralised admin rights. For implementation patterns, the Top 10 NHI Issues is a useful reference point alongside identity governance tooling.

These controls tend to break down when legacy applications have no API, no owner metadata, and no reliable audit trail because the revocation step cannot be verified.

Common Variations and Edge Cases

Tighter offboarding controls often increase operational overhead, requiring organisations to balance faster leaver closure against the effort needed to chase down every hidden account. That tradeoff is unavoidable in environments with many business-owned apps, acquired systems, or shared admin credentials.

There is no universal standard for this yet, but current guidance suggests treating a few scenarios differently. Shared service accounts should not be handled like user accounts, because revoking them may break production services; instead, they need explicit ownership, rotation, and replacement plans. Third-party platforms add another wrinkle, since access may be embedded in vendor portals or delegated integrations that do not surface in the corporate IAM stack. In those cases, the offboarding checklist should include contract or application-owner signoff, not just IT validation.

For organisations with weak visibility, the first milestone is not perfect automation but a complete exception register. If an account cannot be proven closed, the offboarding ticket should remain open until it is either revoked or formally accepted as a residual risk. That approach aligns with lifecycle guidance in the Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs and helps turn offboarding into a measurable control rather than a best-effort cleanup.

Related resources from NHI Mgmt Group

• How should organisations manage contractor access without creating orphaned accounts?
• How can organisations reduce the risk of stale API keys and machine tokens?
• How should teams reduce the risk of orphaned service accounts and stale tokens?
• How should healthcare organisations govern AI when data comes from many systems?