Who is accountable when access controls slow operations and users start bypassing them?

Accountability usually sits with the security and infrastructure leaders who design the access model, because they must balance control, speed, and auditability. If the process drives repeated bypasses, the model is failing its own governance objective. Leaders should review approval paths, privilege duration, and exceptions to ensure controls support work instead of forcing exceptions.

Why This Matters for Security Teams

When access controls slow delivery, users rarely wait patiently for a fix. They route around the control, borrow credentials, reuse tokens, or create local exceptions that never get retired. That makes the real accountability question less about individual convenience and more about whether security leadership designed an access model that can survive operational pressure. Guidance from the NIST SP 800-53 Rev 5 Security and Privacy Controls and NHIMG research such as the Ultimate Guide to NHIs both point to the same operational reality: if control paths are too slow, too rigid, or too opaque, people will optimise around them.

That creates an accountability gap. Security and infrastructure leaders are accountable for designing controls that are enforceable, auditable, and usable enough that teams do not feel compelled to bypass them. Business owners are accountable for using approved paths, but they cannot be expected to absorb repeated friction caused by a poor access model. In practice, the first sign of governance failure is often not an incident review, but a flood of “temporary” exceptions that become the actual operating model.

In practice, many security teams discover that bypasses were not malicious at all, but the predictable result of a control design that made the approved path slower than the workaround.

How It Works in Practice

The cleanest way to assign accountability is to separate policy ownership from workflow execution. Security sets the rules, infrastructure and platform teams implement the access path, and service owners provide operational context for what is genuinely time-sensitive. The question is whether the control model supports the work as it happens, not whether it looks strict on paper. The OWASP Non-Human Identity Top 10 is useful here because it highlights how overlong credential lifetimes, excessive privilege, and weak lifecycle controls become pressure points that encourage unsafe shortcuts.

In mature environments, the practical response is to reduce the need for human intervention:

• Use just-in-time access so approval is tied to a specific task and expires automatically.
• Shorten credential duration so standing access does not become the default exception.
• Apply policy-as-code so decisions are repeatable and can be reviewed after the fact.
• Measure friction points, including approval latency, failed access attempts, and shadow paths.
• Require exception owners and expiry dates so “temporary” access does not become permanent.

NHIMG data reinforces why this matters. The Ultimate Guide to NHIs notes that 97% of NHIs carry excessive privileges, which shows how easily access sprawl turns into operational drag and overexposure at the same time. Accountability therefore includes maintaining controls that are fast enough to be used and strict enough to be trusted. These controls tend to break down in high-change environments with frequent deployments and shared service accounts because the approval chain cannot keep pace with the pace of work.

Common Variations and Edge Cases

Tighter access control often increases coordination overhead, requiring organisations to balance reduced risk against delivery speed and support burden. That tradeoff becomes sharper in incident response, production debugging, and cross-team platform operations, where delay can cause direct business impact. Current guidance suggests that the answer is not to remove controls, but to redesign them so emergency access, break-glass paths, and time-boxed exceptions are visible, logged, and reviewed.

There is no universal standard for exactly how much friction is acceptable. Some teams can tolerate multi-step approvals for privileged actions, while others need delegated authorization with compensating controls. The key is that accountability should sit with the teams that own the control design and exception governance, not with frontline users who are simply trying to complete the task. NHIMG’s 52 NHI Breaches Analysis and external guidance from CIS Controls v8 both support the same operational lesson: when controls create persistent workarounds, the control owner must be the first party held accountable for redesigning the process.

In edge cases, the right fix may be to loosen one control while tightening another. For example, a shorter approval path may be acceptable if paired with stronger logging, more frequent review, and narrower privilege scope. The governance test is simple: if bypasses are becoming routine, the control is no longer functioning as a control.

Related resources from NHI Mgmt Group

• Who is accountable when unauthorized users gain access to sensitive data through weak authorization controls?
• Who should be accountable for access governance when enterprises use a partner to implement identity controls?
• Who is accountable when emergency access is granted to keep healthcare operations running?
• Who is accountable when identity drift or excessive access affects regulated aviation operations?