What breaks when access recertification is handled by one reviewer only?

Why This Matters for Security Teams

Single-reviewer recertification turns an access decision into a solo judgment call, which is risky when the same person is expected to validate business need, privilege sensitivity, and segregation-of-duties constraints. That pattern is especially fragile for non-human identities, where one account may support multiple systems, hidden automation, or broad API reach. The result is often approval by habit rather than evidence.

Current guidance from the OWASP Non-Human Identity Top 10 and NIST SP 800-53 Rev 5 Security and Privacy Controls points toward stronger separation of duties and more explicit access review evidence, but many organisations still treat recertification as a checkbox exercise. NHI Management Group’s Ultimate Guide to NHIs notes that 97% of NHIs carry excessive privileges, which is why weak review design quickly becomes a privilege-retention problem, not just a governance issue.

In practice, many security teams discover over-entitlement only after an audit exception, incident review, or failed access review cycle has already exposed the gap.

How It Works in Practice

A stronger recertification model splits the decision into two distinct checks. One reviewer confirms operational need: does the identity still support a live service, workflow, or automation path? A second reviewer validates risk: is the access level still appropriate, and does it create segregation-of-duties conflict, lateral-movement exposure, or unnecessary standing privilege? That separation matters because one person rarely has enough context to judge both use and risk fairly.

For NHIs, the review should also include machine-readable evidence. Asset owners should see the service name, last-used timestamp, privilege scope, linked secrets, and downstream systems. Security reviewers should see whether the identity is tied to a shared credential, a stale token, or a privileged role that should instead be reduced to just-in-time access. This is where the Ultimate Guide to NHIs — Key Challenges and Risks is useful: it frames review quality as part of lifecycle control, not a one-off compliance task.

• Use separate approvers for business ownership and security risk.
• Require evidence for last use, privilege scope, and dependency mapping.
• Flag privileged service accounts for deeper review or removal.
• Automate escalations when the reviewer cannot determine ownership or purpose.

For human identities, this pattern supports clearer accountability. For NHIs, it should feed directly into rotation, deprovisioning, or privilege reduction instead of merely renewing the entitlement. These controls tend to break down in high-volume environments with shared service accounts and poor asset inventory because reviewers cannot verify ownership or impact fast enough.

Common Variations and Edge Cases

Tighter review controls often increase operational overhead, so organisations have to balance decision quality against campaign speed. That tradeoff becomes visible when thousands of identities are recertified at once, or when one account supports multiple applications and nobody can confidently own the full access picture.

There is no universal standard for this yet, but current guidance suggests the following exceptions need special handling: emergency access, break-glass accounts, inherited platform permissions, and vendor-managed NHIs. In those cases, a single reviewer may be acceptable only if the workflow adds compensating controls such as automated usage evidence, policy-based thresholds, or independent post-approval sampling. This is especially important when the access sits on a critical service or carries secrets that can be reused elsewhere, as seen in breach patterns discussed in the 52 NHI Breaches Analysis.

Where teams get into trouble is assuming a manager, app owner, or platform lead can validate risk alone. That assumption fails when access is inherited, hidden behind orchestration layers, or granted through indirect roles rather than direct entitlements. In those environments, single-reviewer recertification tends to preserve legacy access instead of removing it.

Related resources from NHI Mgmt Group

• When do NHI access reviews create more value than a one-time cleanup?
• What breaks when project access changes are handled one member at a time in large environments?
• What breaks when defensive AI gets broad access to identity code and deployment workflows?
• What breaks when MFA recovery is handled by the same team that grants account resets?