Who should be accountable for user access recertification?

Why This Matters for Security Teams

User access recertification fails when accountability is vague. The named reviewer must be able to say yes, no, or adjust scope for a specific access domain; otherwise the exercise becomes a compliance ritual rather than a control. Security teams often see this problem surface in application owners, data custodians, and line managers who each assume someone else owns the final decision. That gap matters because access review is where excessive privileges, orphaned access, and privilege creep are supposed to be caught before they become incidents. The OWASP Non-Human Identity Top 10 is explicit that identity governance breaks down when ownership and lifecycle controls are not tied to a clear accountable party. NHIMG research shows the scale of that exposure: Ultimate Guide to NHIs reports that 97% of NHIs carry excessive privileges, which is exactly the kind of condition a strong recertification process is meant to catch. In practice, many security teams encounter access review failures only after an audit finding or a privilege-related incident has already exposed the ownership gap.

Accountability should be assigned by access domain, not by generic function. A system owner, data owner, or business process owner can be the accountable reviewer when the review concerns their domain, while IAM or IGA teams remain responsible for workflow design, evidence capture, reminders, and reporting. The reviewer’s job is decision-making; the identity team’s job is process enforcement.

Best practice is evolving toward a model where each recertification item has a named approver with sufficient context to judge business need, privilege sensitivity, and segregation-of-duties risk. That means the review package should include the resource name, role or entitlement, last-used indicators where available, and any exceptions already approved. When the reviewer lacks context, they tend to approve by default, which defeats the purpose of the control.

• Use named reviewers for each application, dataset, platform, or privileged role.
• Escalate to a delegate only with documented authority and time-bounded coverage.
• Keep IAM or IGA teams out of approval decisions to avoid self-review conflicts.
• Require evidence of decision, not just completion status, for auditability.

This also aligns with NHI governance because service accounts, API keys, and machine roles often move faster than human review cycles. The 52 NHI Breaches Analysis shows how access ownership gaps can persist until an incident reveals them. Current guidance suggests that accountability should sit closest to the business risk, while automation handles scale and proof. These controls tend to break down in large federated enterprises where shared applications, outsourced operations, and matrix reporting make it unclear who has final authority.

How It Works in Practice

A workable recertification model starts by mapping every access package to one accountable owner. For example, finance application entitlements go to the finance system owner, customer data access goes to the data steward, and admin privileges go to the platform owner. The IAM or IGA team builds the campaign, but the owner signs off on the risk decision. That split keeps the control operational without turning the identity team into the approver of record.

For high-risk access, the reviewer should see enough context to make a real decision. That usually includes role description, last login or last use, peer comparison, entitlement inheritance, and whether the access is tied to a project, vendor, or production support duty. Where possible, policy should flag dormant access, conflicting roles, and privileged exceptions before the reviewer sees the item. This is especially important when access maps to secrets, certificates, or API keys rather than interactive login.

Implementation works best when the process is explicit:

• Assign one accountable reviewer per access domain.
• Use a named backup only for absence coverage, not shared accountability.
• Route exceptions to a risk owner or security approver when business owners cannot judge technical privilege.
• Retain evidence of each decision, including approvals, removals, and deferred items.
• Measure overdue reviews, default approvals, and repeated exceptions as control failures.

For non-human identities, this principle is even more important because ownership often spans engineering, operations, and application teams. The Ultimate Guide to NHIs — Key Challenges and Risks highlights the governance gap created when access is widespread but ownership is unclear. The OWASP Non-Human Identity Top 10 also reinforces that lifecycle accountability must be explicit rather than implied. These controls tend to break down in shared-service environments where one review line covers too many systems, because the reviewer cannot reasonably judge entitlements they do not understand.

Common Variations and Edge Cases

Tighter accountability often increases administrative overhead, requiring organisations to balance review quality against campaign volume and reviewer fatigue. That tradeoff becomes visible in large enterprises, where thousands of entitlements cannot all be reviewed by senior leaders without slowing operations. Current guidance suggests pushing accountability down to the person closest to the risk, then using guardrails to stop rubber-stamping.

There is no universal standard for this yet, but common variations are emerging. Some organisations use application owners for standard access and security or risk owners for privileged access. Others assign recertification by data domain, especially where regulatory exposure is tied to sensitive records. In highly regulated environments, the accountable reviewer may need sign-off authority plus documented training before they can approve access decisions.

Edge cases matter. Temporary projects often require time-boxed access recertification, while vendor access may need both the business sponsor and the vendor manager to agree on retention. For agentic or automated workloads, the accountable party is usually the owner of the workload or service, not the IAM platform team, because only the service owner can judge whether the access is still required. The key test is simple: the accountable person must understand the business purpose, or the review is effectively delegated to guesswork.

Related resources from NHI Mgmt Group

• How can teams keep payment access accountable as crypto products grow?
• Who is accountable when SaaS access is not revoked on time?
• Who is accountable when a Meraki configuration change disrupts access?
• Who should be accountable when PCI access controls fail?