Who is accountable for removing access when recertification finds an unjustified entitlement?

Why This Matters for Security Teams

When recertification finds an unjustified entitlement, the real risk is not just excess access. It is ambiguity. If the reviewer, business owner, IAM team, and security team all believe someone else will remove the access, the entitlement often survives long enough to be abused. That is why identity governance must define ownership before the review cycle starts, not after the finding appears.

This is especially important for privileged access, service accounts, and API-driven access paths where a single entitlement can expose data, pipelines, or administrative functions. NHIMG’s Ultimate Guide to NHIs notes that only 20% of organisations have formal processes for offboarding and revoking API keys, which shows how often remediation breaks down after discovery. OWASP’s Non-Human Identity Top 10 similarly treats poor lifecycle control as a core exposure. In practice, many security teams encounter unresolved access only after an audit, incident, or breach has already proven the entitlement was unnecessary.

How It Works in Practice

The accountable party should be the business owner or access sponsor who can judge whether the entitlement is still justified. Identity governance then enforces the workflow, while security or IAM teams make sure the control is executed, logged, and completed. That division matters because the owner makes the business decision, but the platform team performs the technical removal and preserves evidence for audit.

A workable recertification process usually includes three steps:

• Review: the owner confirms whether the access still matches a current role, task, or contract.
• Decision: if the entitlement is not justified, the owner approves revocation or escalation for exception handling.
• Removal: IAM or PAM tooling removes the access and records who approved it, when it was removed, and whether any compensating control remains.

That workflow should be predefined before recertification begins, not negotiated during the review. NIST control language in NIST SP 800-53 Rev. 5 Security and Privacy Controls supports access review, accountability, and timely revocation as operational expectations, while the NHIMG 52 NHI Breaches Analysis shows how quickly unmanaged identities turn into active attack paths. The practical control objective is simple: every unjustified entitlement must have a named decision-maker and a timed removal path. These controls tend to break down when ownership sits with a committee or shared mailbox because no one has the authority to remove access immediately.

Common Variations and Edge Cases

Tighter revocation control often increases review overhead, requiring organisations to balance speed against the risk of removing access that is still operationally needed. That tradeoff is most visible in production support, third-party access, and emergency privileges, where the right answer may be revocation, renewal, or a short exception window rather than immediate deletion.

Where access supports an active incident, a change window, or a regulated operational duty, current guidance suggests documenting the exception and setting a short expiry rather than leaving the entitlement open-ended. For NHIs, the same principle applies to secrets and service accounts, but the execution is often different because the access may be embedded in code, CI/CD, or shared infrastructure. In those cases, the business owner still owns the justification, while engineering owns the technical removal path. If there is no clear owner, the entitlement should be treated as unjustified until proven otherwise, because ambiguity is what usually keeps stale access alive.

For organisations dealing with high-volume NHIs, the safest model is to align recertification with lifecycle controls described in Ultimate Guide to NHIs — Key Challenges and Risks and pair it with enforcement discipline from Microsoft SAS Key Breach. Best practice is evolving for AI-driven or highly automated environments, but the accountability principle remains stable: the approver owns the business justification, and the control owner ensures revocation happens.

Related resources from NHI Mgmt Group

• Who is accountable when API-driven access changes affect contracts, licences, or user permissions?
• Who is accountable when access approvals and review reminders move into collaboration platforms?
• Who should be accountable for keeping joiner mover leaver access current?
• Who should be accountable for access governance when enterprises use a partner to implement identity controls?