Who is accountable when offboarding reviews miss access?

Why This Matters for Security Teams

Offboarding misses are rarely a tooling problem alone. They usually expose a broken accountability chain across identity owners, application owners, and reviewers who were expected to confirm access removal. For NHI programmes, the same issue appears when service accounts, API keys, or shared tokens survive longer than the business process that was supposed to retire them. That is why offboarding review failure is a governance issue, not just an operational miss.

NHIMG’s Ultimate Guide to NHIs notes that 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, which shows how quickly unresolved access becomes a security event. The OWASP Non-Human Identity Top 10 reinforces the same point: lifecycle control and ownership clarity are part of the attack surface, not administrative extras. In practice, many security teams encounter the accountability gap only after access has already persisted past departure, rather than through intentional review failure detection.

How It Works in Practice

Accountability should follow the review workflow, not the automation layer. If an offboarding review missed access, the first question is who owned the decision, who had fallback coverage, and who could prove that the review was completed. Automation can trigger tasks, collect evidence, and revoke access, but it cannot own the business decision to approve removal or accept an exception.

Practically, this means assigning a named identity owner and a named application owner for every system with access that must be reviewed at exit. The reviewer should confirm whether the account, token, or integration still has a business purpose, and whether revocation is immediate or deferred for a controlled handover. Evidence should show the reviewer, the date, the decision, the scope of access checked, and any exception approval.

• Define one accountable owner for each application and identity class.
• Require fallback coverage so reviews do not stall during leave or turnover.
• Record evidence of approval, revocation, or exception handling.
• Reconcile HR exit events against IAM and secrets inventories before closure.

The NHI Lifecycle Management Guide is useful here because offboarding should be treated as a lifecycle control, not an isolated ticket. The 52 NHI Breaches Analysis is also a reminder that weak revocation discipline often becomes visible only after exposure, lateral movement, or misuse has already started. These controls tend to break down when application ownership is shared across teams because no single person can prove who should have closed the access.

Common Variations and Edge Cases

Tighter offboarding control often increases review overhead, requiring organisations to balance speed of separation against evidence quality and escalation discipline. That tradeoff matters most in large estates where systems are inherited, ownership is unclear, or access paths include SaaS admin portals, CI/CD tokens, and shared service accounts.

There is no universal standard for this yet, but current guidance suggests that exception handling should be explicit. If a former employee’s access is retained for a short transition window, the record should show who approved it, why it was needed, and when it will be removed. The same principle applies to contractor exits and role transfers, where access may be valid in one system but not another.

Edge cases become more serious when offboarding touches NHI credentials, because tokens and keys are often reused across multiple applications. In that environment, accountability must extend to the owner of the workload that consumes the secret, not just the team that stored it. NHIMG’s Top 10 NHI Issues is a practical reference for the control gaps that most often prevent clean revocation, while OWASP guidance helps teams separate process ownership from technical enforcement. The hardest failures appear when no reviewer can explain why access remained valid after the exit was already closed.

Related resources from NHI Mgmt Group

• Who is accountable when offboarding leaves access behind?
• 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 server access remains active after offboarding?