Why do HR, directory, IGA, and PAM controls often miss dormant access after offboarding in hybrid environments?

Why This Matters for Security Teams

Offboarding failures are rarely caused by one broken workflow. They happen because hybrid identity stacks split authority across HR, directory services, IGA, and PAM, while the actual access footprint often extends beyond all four. That gap matters most when dormant access persists in local accounts, unmanaged SSH keys, API keys, and service credentials that never entered the formal lifecycle. NHIMG’s Ultimate Guide to NHIs notes that only 20% of organisations have formal processes for offboarding and revoking API keys, which is why human termination does not reliably equal access termination.

Security teams often assume that a closed HR record or deprovisioned SSO account means the person is gone everywhere. In reality, hybrid environments preserve access in places that are not centrally reconciled, especially where cloud, on-prem, and developer tooling overlap. OWASP’s Non-Human Identity Top 10 reflects this broader identity sprawl by treating unmanaged machine access as a first-class risk, not a cleanup task. In practice, many security teams encounter dormant access only after an audit, incident, or vendor notice has already exposed the gap.

How It Works in Practice

The failure mode is usually a missing correlation layer. HR knows the employment event, directory services know the primary accounts, IGA knows the applications it has onboarded, and PAM knows what has been vaulted. None of those systems can automatically prove that a forgotten local admin, an SSH key in a server profile, or a token embedded in a CI/CD pipeline belonged to the terminated worker unless the organisation has built identity-to-asset mapping across the full environment.

That is why current guidance suggests treating offboarding as a cross-system reconciliation exercise rather than a simple disablement workflow. A practical process usually includes:

• Revoking directory and SSO access first, then verifying whether shadow accounts still exist on endpoints, servers, and SaaS tenants.
• Searching for unmanaged secrets, SSH keys, and API tokens in code, configs, vaults, ticketing systems, and collaboration tools.
• Checking PAM vaults for shared accounts, break-glass credentials, and delegated access that may outlive the employee record.
• Linking HR termination events to application ownership and system logs so that out-of-band access is flagged for review.

NIST SP 800-53 Rev. 5 supports this kind of control mapping through account management and least privilege expectations, but it does not solve the correlation problem on its own. NHIMG’s NHI Lifecycle Management Guide is useful here because it frames offboarding as a lifecycle event, not a one-time deactivation. NIST guidance can define the control objective, while NHI governance has to close the operational gap between system-of-record and system-of-use. These controls tend to break down when local access is created outside central IAM, because there is no authoritative inventory to tell the deprovisioning workflow what still exists.

Common Variations and Edge Cases

Tighter offboarding controls often increase operational overhead, requiring organisations to balance fast workforce changes against the cost of full access reconciliation. That tradeoff becomes sharper in hybrid environments where legacy systems, contractors, and developer-owned infrastructure coexist with modern IAM. Best practice is evolving, but there is no universal standard for automated correlation across every identity store, secret manager, and host control plane.

Some environments look secure on paper because every user has a clean directory record, yet still carry dormant access through shared service accounts, personal SSH keys, or cloud access keys stored outside PAM. Other organisations centralise too much into one tool and miss what sits outside its scope. NHIMG’s Top 10 NHI Issues and the 52 NHI Breaches Analysis both reinforce the same lesson: visibility failures and stale credentials are usually systemic, not isolated.

Where this guidance is least reliable is in highly decentralised engineering environments, because teams can create new access paths faster than governance processes can discover them. In those cases, offboarding has to include continuous discovery, not just one-time revocation.

Related resources from NHI Mgmt Group

• Why do privileged access controls break down in hybrid environments?
• How should organisations govern access when identity controls are spread across IGA, AM, and PAM?
• How should security teams manage dormant access in hybrid environments?
• Why do PAM deployments often fail in hybrid and legacy environments?