Who is accountable when access remains after offboarding?

Why This Matters for Security Teams

Offboarding is not just an HR event. It is a control handoff problem that crosses identity, access, and ownership boundaries. When access remains after separation, the question is not simply whether someone forgot a ticket. It is whether the organisation can prove who approved the entitlement, who owns removal, and whether the revocation path actually works. NHIMG’s NHI Lifecycle Management Guide treats lifecycle closure as a security control, not an administrative courtesy.

This matters because lingering access is one of the most common ways privilege outlives employment, especially in environments where SaaS, cloud, and shared service teams all touch the same account. The operational risk is larger than audit findings: dormant access can be reused, escalated, or inherited by the next assignee. The OWASP Non-Human Identity Top 10 makes the broader point that identity sprawl and weak lifecycle governance are recurring failure modes, not edge cases. In practice, many security teams encounter lingering access only after an audit, a dispute, or a misuse event has already exposed the missing owner chain.

How It Works in Practice

Accountability for lingering access should be traced through four parties: the business manager who sponsors the worker, HR or People Ops who triggers separation, IT or IAM who executes technical deprovisioning, and the application owner who confirms the entitlement is removed from the source of truth. Best practice is evolving, but current guidance suggests treating offboarding as a workflow with explicit ownership at each step, not a single checkbox in an HR system.

A durable control design usually includes:

• an authoritative termination event from HR or the worker management system
• an entitlement inventory that maps the person to all accounts, roles, and secrets
• revocation runbooks for standard apps, cloud platforms, and privileged pathways
• exception handling for business-required retention, with expiry and sign-off
• evidence capture showing when access was removed and who verified completion

The Top 10 NHI Issues highlights why this breaks down when entitlement data is fragmented across ticketing, IAM, PAM, and application consoles. The technical answer is not merely faster deprovisioning; it is clearer identity ownership and continuous reconciliation. For secrets and API credentials, the same principle applies: if a user had access to shared tokens or service keys, those credentials may need rotation, not just account disablement. As GitGuardian and CyberArk note in The State of Secrets in AppSec, leaked secrets are often slow to remediate, which makes offboarding failures especially dangerous when credentials are reused across systems. These controls tend to break down when the organisation lacks a single entitlement inventory because removal cannot be proven across multiple admin domains.

Common Variations and Edge Cases

Tighter offboarding controls often increase coordination overhead, requiring organisations to balance speed against the risk of breaking legitimate business access. That tradeoff becomes visible in contractors, shared mailboxes, privileged admin roles, and break-glass accounts, where “remove immediately” can conflict with business continuity or evidence preservation.

Current guidance suggests separate handling for these cases. Contractors often need accelerated revocation because sponsorship is weaker and duration is shorter. Privileged access should be routed through PAM with time-bound elevation, so termination removes the standing entitlement instead of relying on manual cleanup. Shared accounts are a known exception, but they should be minimised because accountability becomes ambiguous once a named person leaves. For service accounts and non-human identities, the owner may be a platform team rather than HR, and lifecycle closure should follow the same revocation discipline described in the Ultimate Guide to NHIs.

There is no universal standard for this yet, but the strongest programmes assign a named removal owner, define escalation timing, and require periodic recertification of all dormant or retained access. Where that does not exist, accountability becomes diffuse, and the control failure is usually discovered after the access is already being reused. The cleanest rule is simple: if no one owns revocation, no one truly owns offboarding.

Related resources from NHI Mgmt Group

• Who is accountable when server access remains active after offboarding?
• Who is accountable when a former employee still has access after offboarding?
• Who is accountable when access revocation is missed after offboarding?
• Who is accountable when offboarding leaves access behind?