Who is accountable when a risk finding should have changed access but did not?

Why This Matters for Security Teams

When a risk finding should have changed access but did not, the failure is rarely just “missed detection.” It is usually a broken control path between finding, decision, and enforcement. For NHI programmes, that matters because secrets, service accounts, and API tokens can keep working long after the risk is known. NHIMG research shows that 91.6% of secrets remain valid five days after the targeted organisation is notified, which is a strong signal that remediation workflows, not alerting, are often the weak link. See the Ultimate Guide to NHIs — Key Challenges and Risks and the NIST Cybersecurity Framework 2.0 for the governance expectation that findings must translate into action. The practical question is not who observed the issue, but who owned the authority to reduce exposure. In mature programmes, that ownership sits with the decision workflow, with clear handoff into enforcement, rollback, or exception handling. In weaker setups, security raises the finding while identity, application, and platform teams each assume another team will act. In practice, many security teams encounter stale access only after a token is abused, rather than through intentional policy-driven revocation.

How It Works in Practice

The accountable path should be defined as a chain: detect, assess, decide, enforce, verify. The security function usually owns the risk signal, but the identity or platform owner must own the policy outcome because they control the system that grants or removes access. That is the operational distinction practitioners often miss. The issue is described in NHI governance guidance such as the Ultimate Guide to NHIs and in broader attack-pattern analysis like 52 NHI Breaches Analysis, where delayed revocation repeatedly turns a finding into an incident. A workable operating model usually includes:

• named decision owners for each finding type, not just for the alert source
• policy-as-code or equivalent rules that determine when access is reduced, paused, or revoked
• service-level timing for remediation, escalation, and exception approval
• verification that the access change actually reached the workload, vault, or IdP

For NHI access, the control should be tied to the identity primitive, the secret, and the workload using it. OWASP guidance on the OWASP Non-Human Identity Top 10 reinforces that excessive privilege and weak lifecycle controls are central failure modes. If the environment uses PAM, JIT, or vault-mediated issuance, the response should be to shorten TTLs, revoke standing grants, and force re-authentication at the workload boundary rather than only opening a ticket. These controls tend to break down when access is embedded directly in code or CI/CD pipelines because the revocation path is slower than the exposure path.

Common Variations and Edge Cases

Tighter revocation often increases operational overhead, so organisations must balance speed of containment against the risk of breaking production workloads. That tradeoff becomes harder when the finding is ambiguous, the service is customer-facing, or the credential is shared across multiple dependencies. Best practice is evolving here: there is no universal standard for every exception path, but the governance decision still needs a named owner and a time-bound review. Some teams route findings through RBAC reviews; others use JIT credentialing or ZSP to eliminate standing access altogether. For autonomous agents and highly dynamic workloads, static role models can fail because the access request changes with each task. In those environments, current guidance suggests intent-based authorisation, short-lived secrets, and workload identity as the more reliable pattern. If the organisation is adopting agentic systems, the control mapping should also reflect OWASP NHI Top 10 alongside the OWASP Non-Human Identity Top 10, because an autonomous agent can chain tools and amplify a stale entitlement faster than a human operator would expect. These cases are hardest in multi-team environments where an exception is approved locally but the revocation must occur globally across vault, cloud, and application layers.

Related resources from NHI Mgmt Group

• When does JIT access create more risk than it reduces?
• What breaks when access reviews are used as the main risk control?
• Who should own third-party access risk in a banking GRC programme?
• How should organisations govern identity risk across human, NHI, and automated access?