Who is accountable when onboarding access is overprovisioned or never removed?

Accountability usually sits with the business owner of the role, the IAM team that configured the workflow, and the system owner that accepted the entitlement model. Governance fails when those responsibilities are split without a clear review path. The fix is explicit ownership across joiner, mover, and leaver events.

Why This Matters for Security Teams

Overprovisioned onboarding access and stuck entitlements are not just hygiene issues; they are control failures that create long-lived attack paths. When a role is granted broader access than the business need, or when deprovisioning never happens, the organisation inherits unauthorised reach that can persist across teams, systems, and audits. NHI Management Group’s Ultimate Guide to NHIs notes that 97% of NHIs carry excessive privileges, which shows how often access models drift beyond intended scope.

The practical problem is accountability fragmentation. HR may trigger the event, IAM may implement the workflow, and the application owner may approve the entitlement model, but none of those actors can safely assume another team will clean up access later. That gap matters because access review is only effective when ownership is explicit at each joiner, mover, and leaver stage. The OWASP Non-Human Identity Top 10 treats excess privilege and lifecycle weakness as core identity risk, not edge cases. In practice, many security teams discover overprovisioned access only after an audit finding, an incident, or a failed offboarding review has already exposed the gap.

How It Works in Practice

Accountability starts with assigning a named owner for the business role, a technical owner for the identity workflow, and a system owner for the entitlement model. Those three roles should be able to answer one question: who approves the access, who provisions it, and who verifies removal? The answer must be documented in the workflow itself, not buried in a ticket comment or a policy PDF. NHI Management Group’s NHI Lifecycle Management Guide frames this as lifecycle governance, because joiner, mover, and leaver events are only controllable when the handoff points are defined.

In mature programmes, the control model usually includes:

• Role-based approval for initial access, with the business owner validating need and scope.
• Automated provisioning tied to a source of truth, so entitlements are not manually copied into accounts.
• Periodic recertification that checks whether the original job function still exists.
• Automated deprovisioning for role changes and terminations, with exception handling for break-glass or legal hold cases.
• Logging that records who approved, who executed, and who confirmed removal.

This is where identity governance becomes operational rather than theoretical. Current guidance from the OWASP Non-Human Identity Top 10 and NHIMG’s lifecycle research points to the same conclusion: access must be owned end to end, because a workflow without a clear reviewer is just delayed privilege accumulation. When offboarding is tied to people, platforms, and approvals that do not share a single review path, revocation slips behind the real business event and the account remains active longer than anyone expects.

These controls tend to break down in federated environments where business units manage their own entitlements but central IAM cannot enforce a common review cadence.

Common Variations and Edge Cases

Tighter approval controls often increase operational friction, requiring organisations to balance faster onboarding against stronger review discipline. That tradeoff becomes visible in shared platforms, temporary project roles, and outsourced support models, where delays can pressure teams to approve broad access “for now.” Best practice is evolving, but current guidance suggests that temporary convenience should never override explicit ownership of revocation.

There are also cases where no single owner can remove access immediately. Shared admin groups, inherited entitlements, and legacy systems often require staged cleanup instead of instant removal. In those environments, accountability should still be assigned to a named control owner who is responsible for exceptions, documentation, and closure. NHIMG’s 52 NHI Breaches Analysis reinforces a recurring pattern: missed lifecycle actions and excessive privilege tend to compound, not stay isolated.

For audit and governance teams, the practical test is simple. If a reviewer cannot identify who approved the access, who should have removed it, and when the last validation happened, accountability is not complete. That is true even when the entitlement is technically “owned” by multiple groups, because shared ownership without a final decision maker usually means nobody is responsible when access lingers.

Related resources from NHI Mgmt Group

• Who is accountable when orphaned Active Directory access is not removed?
• Who is accountable when temporary access is never removed?
• Who is accountable when zero trust fails because access was never removed?
• Who should be accountable for patient data access in connected healthcare hubs?