Who is accountable when contextual risk signals are not used in access governance?

Why This Matters for Security Teams

When contextual risk signals are ignored, access governance stops being evidence-based and becomes an approval ritual. That matters because risk is rarely static: device posture, location, session timing, privileged action, and unusual behaviour all change the meaning of the same request. Current guidance from the NIST Cybersecurity Framework 2.0 and the OWASP Non-Human Identity Top 10 both point toward risk-informed decisions, not blanket approvals.

For NHIs, the accountability question is especially important because the owner of the governance process is also the party expected to prove that access was justified, proportionate, and reviewable. If contextual signals exist but are excluded, the organisation still owns the decision and the fallout. NHIMG’s Ultimate Guide to NHIs frames this as a lifecycle issue, not just an access-review issue: governance must follow the identity from issue through rotation, use, and retirement. In practice, many security teams discover the weakness only after a disputed access decision has already been exploited or challenged during audit.

How It Works in Practice

Accountability usually sits with identity, security, and application owners because they define the policy, approve the exceptions, and sign off on review outcomes. The practical question is not just “who approved access?” but “who decided which signals mattered and which were ignored?” That decision often gets embedded in provisioning flows, periodic reviews, and exception handling, which means governance teams can inherit risk they never explicitly evaluated.

Good practice is to treat contextual risk as an input to policy, not an optional extra. That typically means combining identity state with session context and workload behaviour, then using it to shape access decisions at request time. For example:

• Use device, location, and time-of-day signals to increase scrutiny for privileged or unusual requests.
• Require step-up approval or shorter-lived access when risk increases.
• Log the context used for each decision so reviewers can explain the outcome later.
• Reassess access when posture changes instead of waiting for the next quarterly review.

This is where evidence matters. The 52 NHI Breaches Analysis shows how quickly weak governance becomes an operational incident, especially when secrets and service accounts are left with broad standing access. Pairing that with the NIST SP 800-53 Rev 5 Security and Privacy Controls helps teams translate the policy into reviewable control language, especially for access approval, logging, and continuous monitoring. These controls tend to break down when approvals are delegated to owners who cannot see the full context or when the platform cannot preserve the evidence behind each decision.

Common Variations and Edge Cases

Tighter contextual governance often increases review overhead, requiring organisations to balance stronger decision quality against operational speed. That tradeoff is real, especially for high-volume service accounts, delegated admin roles, and automated workflows where every extra approval step can slow delivery. In those environments, current guidance suggests using policy tiers rather than forcing the same review depth on every identity.

There is no universal standard for how many signals must be used, but best practice is evolving around proportionality: high-risk access should require richer context, while low-risk routine access can rely on lighter checks. For example, an internal batch job with stable behaviour may need different treatment than an agentic workflow that can chain tools or request new permissions dynamically. The accountability owner should still be able to explain why the chosen context was sufficient.

Another edge case is shared governance across security and application teams. In those models, accountability is often split in practice but not in documentation, which creates ambiguity after an incident. NHIMG’s Top 10 NHI Issues highlights that over-privilege and weak lifecycle controls tend to reappear when ownership is unclear. In other words, the team that can approve access is not always the team that can defend the decision.

Related resources from NHI Mgmt Group

• When does JIT access create more risk than it reduces?
• What is the difference between role-based access and API key governance for NHI security?
• How should security teams govern API keys used for generative AI access?
• How do human risk signals fit into identity and access governance?