Who is accountable when an access review decision is not enforced?

Why This Matters for Security Teams

An access review only matters if the decision changes entitlement state. When certifications are approved, revoked, or deferred but the downstream system never enforces the outcome, the control becomes a record-keeping exercise rather than a risk reduction measure. That gap is especially damaging for NHIs, where long-lived secrets, service accounts, and automation tokens can keep working long after the reviewer believes access has been removed.

NHI Management Group’s Ultimate Guide to NHIs notes that 71% of NHIs are not rotated within recommended time frames, and OWASP Non-Human Identity Top 10 treats weak lifecycle enforcement as a core failure mode. The accountability question is therefore not academic: it determines whether the organisation owns an effective control or only an audit artefact.

In practice, many security teams discover unenforced access decisions only after a review cycle has closed and the entitlement remains active in production.

How It Works in Practice

Accountability normally sits across three roles: the identity governance owner, who designs the review workflow; the system owner, who ensures entitlements can actually be changed; and the process owner, who validates that approvals and revocations are executed end to end. If a reviewer marks an entitlement for removal but the ticket, connector, or API action fails, the reviewer has provided input, not control enforcement. That is why current guidance suggests treating unenforced access reviews as control design defects, not as isolated human mistakes.

Operationally, strong programs close the loop with automation and evidence. A review platform should not just capture a decision; it should trigger provisioning, record success or failure, and retry or escalate when the target system rejects the change. For NHI cases, that often means revoking API keys, disabling service accounts, rotating secrets, or forcing token expiry through identity lifecycle tooling. The same principle appears in NHI lifecycle guidance from NHI Lifecycle Management Guide and in the breach patterns described in 52 NHI Breaches Analysis.

Practitioners should also separate decision authority from execution authority. A manager or app owner can approve revocation, but the IAM connector, PAM integration, or workflow engine must prove the action completed. Best practice is evolving toward automated reconciliation checks, where the review outcome is compared against live entitlement state and exceptions are escalated until closure. This aligns with control expectations in the OWASP Non-Human Identity Top 10, especially where stale or mismanaged credentials create persistent access paths. These controls tend to break down when target applications lack APIs or when legacy systems cannot reliably confirm entitlement removal because the workflow cannot verify final state.

Common Variations and Edge Cases

Tighter review enforcement often increases operational overhead, requiring organisations to balance audit simplicity against system complexity. That tradeoff is most visible in hybrid estates, where some platforms support immediate deprovisioning and others need manual intervention or delayed batch updates. In those cases, the accountable party is still the owner of the control design, but the evidence standard should reflect whether the environment can enforce real-time state changes or only near-term reconciliation.

There is no universal standard for this yet in every environment, but current guidance suggests documenting who owns each enforcement step, what happens on connector failure, and how exceptions are time-boxed. For NHIs, this matters because stale credentials can remain usable even after the review is marked complete. The result is a false sense of closure that hides exposure until the next incident or audit. NHI Mgmt Group’s Ultimate Guide to NHIs is a useful baseline for tying review outcomes to lifecycle actions, but organisations still need local ownership and technical enforcement to make the process real.

Edge cases also arise when access is shared, inherited through roles, or embedded in automation pipelines. In those situations, the accountable owner is the person who can remove or redesign the access path, not the reviewer who merely flags the issue.

Related resources from NHI Mgmt Group

• When should organizations review access controls?
• Who is accountable when sustained infrastructure attacks disrupt access and availability?
• Who should be accountable when a compromised mailbox leads to fraud or access loss?
• Who is accountable when cloud access expires on paper but persists in practice?