What breaks when offboarding is only checked in the primary directory?

Why This Matters for Security Teams

Offboarding is not complete when a primary directory account is disabled. If a user, contractor, or service account also exists in SaaS portals, legacy applications, API consoles, or vendor-managed systems, those entitlements can survive the directory event and remain callable long after the supposed cut-off. That creates shadow access that is difficult to inventory, harder to prove removed, and often invisible to standard joiner-mover-leaver reporting.

This is especially important for NHI governance because the real control point is lifecycle coverage, not just directory status. NHI Management Group’s NHI Lifecycle Management Guide frames offboarding as a cross-system revocation problem, not an HR cleanup task. The issue is consistent with the broader pattern in the Top 10 NHI Issues, where visibility gaps and weak lifecycle discipline leave accounts active after they should be retired.

For security teams, the practical risk is that directory hygiene creates a false sense of containment. NIST’s NIST Cybersecurity Framework 2.0 emphasizes asset and access visibility, but many environments never extend that discipline beyond the primary identity store. In practice, many security teams discover residual access only after an audit, an incident, or a vendor review exposes accounts that were never actually deprovisioned.

How It Works in Practice

Effective offboarding starts by treating the primary directory as one control plane among many. The directory event should trigger a revocation workflow that reaches every system where the identity may have been provisioned, including SaaS applications, privileged access platforms, source control, cloud consoles, and external partner portals. Best practice is evolving toward automated reconciliation, where each application is compared against a source-of-truth offboarding list and confirmed closed, rather than assuming a single disable action propagates everywhere.

The strongest programs combine identity lifecycle events with entitlement mapping, token revocation, and secret rotation. That means disabling interactive logon, invalidating API keys and refresh tokens, removing group memberships, and checking for locally managed accounts that bypass directory sync. The Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs describes why lifecycle control must include creation, use, rotation, and retirement, not just provisioning. This matters because many third-party systems keep independent identity records, and those records may survive until manually deleted.

• Inventory all systems where the identity had access, including shadow IT and vendor-hosted tools.
• Confirm disablement in each target system, not just in the corporate directory.
• Revoke tokens, certificates, API keys, and delegated admin roles tied to the identity.
• Validate completion with logs, not ticket closure alone.

Where possible, automate offboarding checks through lifecycle orchestration and access review evidence. These controls tend to break down in heavily federated environments where vendors maintain their own account stores and the organisation lacks reliable telemetry from those external platforms.

Common Variations and Edge Cases

Tighter offboarding often increases operational overhead, requiring organisations to balance stronger containment against slower account transitions and more review work. That tradeoff is real, especially when contractors, external developers, and machine identities span multiple business units or shared platforms.

There is no universal standard for this yet, but current guidance suggests treating high-risk systems differently from low-risk ones. For example, privileged admin consoles, finance tools, and production APIs should have explicit shutdown verification, while low-risk collaboration tools may be handled through periodic access attestation. The problem becomes more complex when a vendor controls the lifecycle, because the primary directory may not be authoritative for deletion. In those cases, the organisation needs contractual offboarding requirements, evidence of revocation, and a way to confirm the vendor’s local account store was actually closed.

One useful data point from NHI Management Group’s research is that only 20% of organisations have formal processes for offboarding and revoking API keys, which helps explain why lingering access persists even after directory closure. That gap is amplified when access is duplicated across systems or when emergency accounts are excluded from normal workflows. The safest assumption is that directory disablement is a signal to investigate, not proof of removal. Residual access is most dangerous in environments with shared admin accounts, federated SaaS, or vendor-managed services because the directory cannot enforce what it cannot see.

Related resources from NHI Mgmt Group

• What breaks when offboarding does not fully remove directory access?
• What breaks when device offboarding is only partly automated?
• What breaks when offboarding is only handled at the SSO layer?
• How should security teams prevent unwanted persistence in Active Directory and Entra ID?