Who is accountable when offboarding misses accounts outside the directory?

Why This Matters for Security Teams

Offboarding failures are rarely about a single missed ticket. They usually expose a deeper ownership problem: accounts exist outside the directory, so the usual joiner-mover-leaver workflow never sees them. That is why accountability cannot sit with the workflow alone. It belongs to the identity owner, the application owner, and the control owner who are responsible for knowing where privileged access and service access actually live. NIST’s NIST Cybersecurity Framework 2.0 frames this as a governance and asset-management issue, not just a revocation task.

This matters because directory-centric offboarding can create a false sense of completion while leaving API keys, service accounts, and shadow admin accounts active. NHIMG research shows only 5.7% of organisations have full visibility into their service accounts in the Ultimate Guide to NHIs, and 91% of former employee tokens remain active after offboarding in Entro Security’s 2025 State of NHIs and Secrets in Cybersecurity. In practice, many security teams discover the gap only after a former user’s access has already been abused, rather than through intentional closure of exceptions.

How It Works in Practice

The practical answer is to treat offboarding as an exception-management process, not a directory cleanup task. If an account is outside the directory, it should still have a named owner, an inventory record, and a closure path. That owner must be accountable for identifying the account, validating whether it is still needed, and proving revocation or replacement. The process should not move to “complete” until unresolved accounts are either removed or formally accepted as residual risk.

Current guidance suggests breaking the workflow into three steps:

• Discover accounts through IAM logs, SaaS admin consoles, cloud control planes, and secrets scanners.
• Map each account to an application owner or service owner, even when the account is not present in the directory.
• Require evidence of revocation, rotation, or compensating control before the leaver case is closed.

This is where lifecycle discipline matters. The NHI Lifecycle Management Guide and the Top 10 NHI Issues both point to the same operational failure: organisations manage visible identities while ignoring embedded credentials and orphaned service access. For control design, align offboarding with identity governance, asset inventory, and revocation evidence under NIST CSF 2.0. These controls tend to break down in SaaS-heavy environments where application owners can create local accounts without central IAM approvals because those accounts never enter the standard leaver queue.

Common Variations and Edge Cases

Tighter offboarding control often increases operational overhead, requiring organisations to balance fast employee exits against complete access closure. That tradeoff becomes more visible when accounts are embedded in third-party platforms, legacy applications, shared automation tooling, or vendor-managed systems.

Best practice is evolving for these edge cases. There is no universal standard for this yet, but the current direction is clear: if an account cannot be centrally deleted, it still needs an accountable owner, a documented compensating control, and a review date. Shared service accounts are especially problematic because a single leaver may not own the credential outright, yet still know the secret or the application path that uses it. In those cases, ownership must shift to the system steward, not remain implied by the departing user.

Leaver controls also fail when teams assume the directory is the source of truth for all identities. NHIMG guidance on the Ultimate Guide to NHIs shows how often secrets and service accounts sit outside normal governance, so the better question is not “was the user removed?” but “were all dependent access paths closed?” If not, the accountable owner must formally accept the exception until the gap is resolved.

Related resources from NHI Mgmt Group

• How can organisations improve offboarding when accounts live in many systems?
• How should teams reduce the risk of orphaned service accounts and stale tokens?
• Who is accountable when a non-human identity is never offboarded?
• How should organisations manage contractor access without creating orphaned accounts?