Who is accountable for removing unnecessary access when user responsibilities change?

Accountability should sit with the identity governance owner, the business manager approving access, and the application owner enforcing entitlement correctness. Each has a different control responsibility. Governance defines the review cycle, managers validate business need, and system owners ensure permissions can actually be removed. Without shared accountability, excess access tends to remain in place.

Why This Matters for Security Teams

Removing unnecessary access is not just an administrative cleanup task. It is a control that limits how far excess privilege can spread when roles change, projects end, or staff move between teams. Shared accounts, service principals, and delegated admin paths often retain access long after the original business need disappears. That creates avoidable exposure and makes reviews look complete even when enforcement is weak.

The risk is well documented in both human and non-human identity estates. NHI Management Group notes that 97% of NHIs carry excessive privileges, which broadens the attack surface and makes entitlement drift harder to contain in practice. The same pattern shows up in account review programs where approval exists but deprovisioning never actually happens. The Ultimate Guide to NHIs and the OWASP Non-Human Identity Top 10 both stress that governance only works when it is paired with enforceable lifecycle controls.

In practice, many security teams encounter excess access only after a role change, audit finding, or incident has already exposed the gap.

How It Works in Practice

Accountability is usually distributed across three control owners, not concentrated in one seat. The identity governance owner defines the review cadence, evidence requirements, and workflow for access recertification. The business manager confirms whether the person still needs the access to perform the job. The application owner or system owner ensures the entitlement can actually be removed from the target system without breaking legitimate operations. That division matters because an approved review is not the same thing as an enforced change.

Best practice is to tie removal to a documented trigger such as role change, transfer, termination, or project completion, then require closure evidence from the system of record. Access reviews should not end at manager approval. They should include deletion, disablement, privilege reduction, or time-bound replacement with a lower entitlement. For privileged and non-human access, current guidance increasingly favors just-in-time removal or expiry over permanent entitlement retention, especially where the workload can re-request access at runtime.

Identity governance also needs strong control mapping. NIST’s SP 800-53 Rev. 5 Security and Privacy Controls supports this model through least privilege, access enforcement, and periodic review expectations. For NHI-heavy environments, the Ultimate Guide to NHIs — Key Challenges and Risks is useful because the same control failure often appears in service accounts, API keys, and automation tokens that no manager is actively watching.

• Define who approves removal, who implements it, and who validates closure.
• Automate entitlement checks so role changes trigger review, not just reminders.
• Require proof of removal from the application, directory, or vault.
• Track exceptions separately when technical constraints delay cleanup.

These controls tend to break down when entitlements are embedded in legacy applications that cannot produce reliable removal evidence.

Common Variations and Edge Cases

Tighter removal controls often increase operational overhead, requiring organisations to balance speed of change against assurance that access has truly been revoked. That tradeoff becomes more visible in complex environments with shared admin roles, outsourced operations, and applications that rely on inherited permissions or delayed synchronization.

There is no universal standard for every edge case yet. Current guidance suggests that the accountable owner should still be explicit, even when the actual removal is delegated to a platform team or automation pipeline. In cloud and SaaS environments, this often means the application owner remains accountable for entitlement correctness, while infrastructure teams execute the technical change. In regulated or high-risk environments, the business manager should not be allowed to waive removal without a documented compensating control.

The biggest gap appears when organisations treat recertification as a governance artifact rather than an operational control. NHI Management Group research shows that only 20% of organisations have formal offboarding and API key revocation processes, which helps explain why stale access persists after role changes. That is why the operating model should be tested against real removals, not just approval records, and why the 52 NHI Breaches Analysis remains a useful reminder that missed cleanup is often the precursor to broader compromise.

In practice, the control fails when ownership is split across HR, IT, and application teams but no one is measured on actual deprovisioning completion.

Related resources from NHI Mgmt Group

• Who is accountable when API-driven access changes affect contracts, licences, or user permissions?
• Who is accountable for service principal access when teams change or workloads are reassigned?
• Who is accountable when user access reviews are incomplete or not evidence-ready?
• Who is accountable when a user retains unauthorized access after a certification cycle?