Who should be accountable when an access review is completed but risky access remains?

Why This Matters for Security Teams

An access review that closes with risky access still in place is not a paperwork issue, it is a control failure. The accountable parties are the identity governance owner, the business reviewer, and the control designer who allowed certification to become a volume exercise instead of a risk decision. The NIST Cybersecurity Framework 2.0 expects access controls to reduce exposure, not just document it, and NHIMG’s NHI Lifecycle Management Guide frames the same principle for non-human identities. When a reviewer signs off without forcing remediation, the outcome is shared accountability, but the failure is operational, not abstract.

This matters because risky access in NHI environments often persists through the very systems meant to catch it. Credentials, tokens, and service accounts are easy to certify in bulk and hard to contextualise one by one, especially when teams rely on RBAC snapshots rather than usage, purpose, and ownership signals. NHIMG’s 52 NHI Breaches Analysis shows how frequently weak governance becomes a breach pathway, while OWASP Non-Human Identity Top 10 highlights the risk of overprivileged, stale, or unowned identities. In practice, many security teams encounter this only after an audit trail looks complete but the risky entitlement is still live.

How It Works in Practice

Accountability should be assigned across three layers. First, the identity governance owner is responsible for the design of the review process, including scope, evidence quality, escalation paths, and remediation deadlines. Second, the business reviewer is responsible for making a meaningful access decision, not merely approving a queue item. Third, the control owner or platform team is responsible for making sure the workflow can remove, restrict, or re-approve access when risk is found. A certification that cannot trigger action is not a control, it is a record.

For non-human identities, the review must go beyond RBAC labels. Practitioners should confirm who owns the workload, what system or agent it serves, whether the secret is still needed, and whether the entitlement is still consistent with the workload’s current task. The Ultimate Guide to NHIs — Key Challenges and Risks and the Ultimate Guide to NHIs — Why NHI Security Matters Now both reinforce that ownership, lifecycle control, and short-lived access are central to reducing NHI exposure. NIST CSF 2.0 and the NIST Cybersecurity Framework 2.0 support the same operational expectation: controls must be measurable, actionable, and tied to risk reduction.

• Require evidence that every flagged entitlement was remediated, not just reviewed.
• Separate approval authority from remediation ownership so the business cannot “approve and forget.”
• Use workflow rules that auto-escalate unresolved risky access after a fixed SLA.
• Track whether access was removed, reduced, or converted to JIT provisioning.

These controls tend to break down when large service-account populations, delegated ownership, and fragmented ticketing make it impossible to prove that a certification changed actual access state.

Common Variations and Edge Cases

Tighter access review enforcement often increases operational overhead, requiring organisations to balance speed against assurance. That tradeoff is especially visible where thousands of NHIs, agents, or API clients inherit permissions through platform templates. Current guidance suggests that the answer depends on whether the risky access was known, whether remediation was possible, and whether the reviewer had authority to reject it. If the reviewer lacked the power to change access, accountability shifts upward to the process owner and the control designer.

There is no universal standard for this yet in agentic or autonomous environments, but best practice is evolving toward intent-based authorisation, JIT credentials, and ephemeral secrets. Where an AI agent or automated workload has execution authority, the problem is not only who signed the review, but whether the access model was built for dynamic behaviour at all. OWASP Non-Human Identity Top 10 and DeepSeek breach show why long-lived secrets and broad entitlements become dangerous when workloads can act autonomously. In those cases, accountability includes the design decision to permit standing access instead of workload identity with time-bound proof. The Ultimate Guide to NHIs is useful here as a lifecycle reference for when ownership, expiry, and revocation must be enforced automatically.

Where the reviewer is in a different business unit from the system owner, the most common failure is assumption: each side believes the other will close the gap, and the risky access survives the review cycle.

Related resources from NHI Mgmt Group

• Who is accountable when vendor access remains active after a banking engagement ends?
• When should organizations review access controls?
• Who is accountable for MCP access when identity is federated?
• What breaks when access reviews are only completed on paper?