Subscribe to the Non-Human & AI Identity Journal

Who is accountable when orphaned access appears after offboarding?

Accountability sits with the identity governance process owner, the HR-to-IT workflow owner, and the application owner if integrations fail to remove access. In practice, offboarding is only complete when the entitlement change is propagated across every connected system and recorded in the audit trail.

Why This Matters for Security Teams

orphaned access after offboarding is not just an identity cleanup issue. It is a control failure that exposes audit gaps, privilege creep, and weak system ownership across HR, IAM, and application teams. NHI Management Group’s Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs shows that lifecycle failures are a core driver of NHI risk, especially when revocation does not reach every downstream system. The same pattern applies to human offboarding when service accounts, API keys, and delegated access remain active.

From a security ownership standpoint, accountability is shared but not ambiguous. The identity governance process owner is responsible for the control model, the HR-to-IT workflow owner is responsible for triggering and validating the handoff, and the application owner is responsible for the actual deprovisioning behavior inside connected systems. That division matters because orphaned access often appears after one team assumes another has completed the task. Current guidance from the OWASP Non-Human Identity Top 10 reinforces that lifecycle failures become security events when credentials or entitlements are not reliably revoked. In practice, many teams only discover the gap during an incident review or access recertification, rather than through intentional offboarding testing.

How It Works in Practice

Effective accountability depends on tracing the offboarding process end to end, not stopping at the HR termination event. The governance owner should define the policy, retention window, required evidence, and exception handling. The workflow owner should ensure the termination signal reaches IAM, PAM, SSO, ticketing, and provisioning tools. The application owner should confirm that local entitlements, cached sessions, API tokens, and delegated trust are removed or expired. NHI Management Group’s NHI Lifecycle Management Guide is useful here because the same lifecycle logic applies to any identity that can outlive the user or service that created it.

Operationally, strong teams use three layers of control:

  • Workflow assurance: termination events are tracked from HR to IAM to each target system.
  • Revocation proof: access removal is verified with logs, not assumed from ticket closure.
  • Exception handling: missed systems are escalated to a named owner with a due date.

Where possible, automate attestations and correlation so that orphaned access can be detected quickly. NHI Management Group’s 52 NHI Breaches Analysis is a reminder that delayed revocation is often the difference between a contained issue and a broader compromise. The practical lesson is that offboarding is only complete when entitlement changes are confirmed across every connected system and recorded in a defensible audit trail. These controls tend to break down in environments with many unmanaged SaaS apps, hardcoded credentials, or custom integrations because revocation cannot be centrally enforced.

Common Variations and Edge Cases

Tighter offboarding controls often increase coordination overhead, requiring organisations to balance faster access removal against application complexity and business continuity. That tradeoff is especially visible when an employee owns shared infrastructure, background jobs, or delegated admin roles that cannot simply be deleted without disrupting operations. In those cases, the accountable owner must also plan replacement ownership, key rotation, or temporary privilege reduction.

There is no universal standard for this yet, but current guidance suggests treating orphaned access differently based on risk. High-risk access such as production admin, secrets store access, or privileged API tokens should be revoked immediately and validated separately. Lower-risk access may be handled in a batched review, provided the delay is documented and approved. The OWASP Non-Human Identity Top 10 aligns with this risk-based view because identity sprawl and lingering credentials create exposure long after offboarding.

One important edge case is partial automation. If HR triggers deprovisioning but the app owner must manually remove access, accountability still sits with both functions, but the app owner owns the failure if the connector or API path does not work. Another edge case is third-party managed systems, where contractual ownership and technical control may be split. In those cases, the enterprise still owns the risk, even if the removal action is performed externally. The decisive question is not who submitted the request, but who was responsible for confirming completion.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.

Framework Control / Reference Relevance
OWASP Non-Human Identity Top 10 NHI-04 Orphaned access is a lifecycle and revocation failure for non-human identities.
NIST CSF 2.0 PR.AC-1 Access removal accountability aligns to identity and credential management outcomes.
NIST CSF 2.0 PR.AC-4 Least-privilege enforcement requires access to be removed when employment ends.

Assign a named owner for deprovisioning and confirm access removal evidence before recertification closes.