Who is accountable when risky identity access persists across reviews?

Why This Matters for Security Teams

Risky identity access that stays active across review cycles is not just a paperwork problem. It is a control failure that turns “reviewed” into “trusted,” even when no one can prove the access was still needed. In NHI-heavy environments, stale service accounts, API keys, and agent credentials often outlive the business task they were created for, which makes review cadence a weak substitute for continuous control.

NHI Management Group’s Ultimate Guide to NHIs notes that 97% of NHIs carry excessive privileges, and the Top 10 NHI Issues highlights how often those privileges remain in place long after they should have been reduced or revoked. That is why accountability matters: the identity governance owner must run the process, the system owner must understand the technical exposure, and the business owner must justify the access decision. Current guidance from the NIST Cybersecurity Framework 2.0 supports this kind of ongoing ownership rather than one-time approval.

In practice, many security teams encounter persistent risky access only after an incident review, rather than through intentional governance.

How It Works in Practice

Accountability becomes real when review findings have named owners, defined remediation deadlines, and evidence of closure. A review that flags risky access but does not force an action creates audit theatre, not risk reduction. The practical model is simple: identify the identity, classify the risk, assign the remediation owner, and require either removal, step-up controls, or a documented exception with expiry.

For NHIs, this is harder than for human identities because access is often embedded in code, CI/CD pipelines, or orchestration workflows. The 52 NHI Breaches Analysis and the OWASP Non-Human Identity Top 10 both reinforce the same operational point: if no one owns the secret, token, certificate, or service account lifecycle, risky access tends to persist after review because there is no enforced remediation path.

• The identity governance owner should maintain the review workflow, evidence, and escalation path.
• The system owner should confirm whether the access is technically required and what would break if it were removed.
• The business owner should attest to the current business need and accept the risk if the access remains.
• Security teams should require time-bound exceptions, not open-ended approvals.
• Continuous monitoring should verify that the access pattern still matches the approved use case.

Good ISPM practice also records who approved the access, who challenged it, and who closed the issue, because accountability without traceability usually fails during audit or incident response. These controls tend to break down when ownership is spread across multiple teams and no single workflow can force revocation or reapproval.

Common Variations and Edge Cases

Tighter review and escalation often increases operational overhead, requiring organisations to balance faster risk reduction against slower delivery teams. That tradeoff is especially visible when access supports production systems, third-party integrations, or agentic workloads that cannot tolerate long outages.

There is no universal standard for this yet, but current guidance suggests treating exception handling as part of accountability rather than as an administrative afterthought. In some environments, the business owner may be the only person who can legitimately accept residual risk. In others, especially where privileged access is involved, the system owner or platform owner may need to co-sign because they control the technical blast radius. The important point is that accountability should not disappear into the review process itself.

For persistent NHI access, the edge case is often orphaned ownership. A token or service account may still work even after the application team has changed, the vendor relationship has ended, or the original approver has moved roles. In those cases, the safest response is to assume the access is no longer accountable until a current owner revalidates it. That aligns with the governance direction in the Ultimate Guide to NHIs — Why NHI Security Matters Now, where persistent secrets and excessive privilege are treated as structural risk, not isolated exceptions. In practice, accountability fails when review owners sign off without the authority to revoke, reduce, or retire the access.

Related resources from NHI Mgmt Group

• What breaks when access reviews are managed manually across ERP systems?
• Who is accountable when access is over-provisioned across cloud and on-premises systems?
• How should security teams run access reviews for non-human identities?
• When do NHI access reviews create more value than a one-time cleanup?