When usability is ignored, security tends to accumulate noise, friction, and poor adoption. Users and developers then look for unofficial tools or shortcuts that bypass approved processes, which weakens visibility and control. The result is a system that feels safer on paper but is harder to operate, slower to use, and less effective where risk actually appears.
When restriction creates more friction than safety
Security controls only work when people can actually use them in the flow of work. If teams pile on restriction without reducing effort, they often shift behaviour instead of improving it: people delay tasks, route around controls, or ask for exceptions that become the real operating model. The control may look strict, but the practical outcome is weaker adoption and less reliable security.
That pattern matters because usability is not a convenience layer, it is part of control effectiveness. A process that is too slow, opaque, or error-prone often produces shadow IT, copied secrets, shared accounts, or unsanctioned integrations. In other words, the restriction does not remove risk, it redistributes it into places the team can see less clearly.
For identity-heavy environments, this becomes especially visible in how credentials and access paths are handled. When approved workflows are cumbersome, teams are more likely to keep using long-lived access, duplicate tokens, or informal approvals. That is exactly why NHI governance needs visibility and rotation discipline, as reflected in NHIMG’s Ultimate Guide to NHIs, What are Non-Human Identities, because friction often drives the very exceptions that increase exposure.
Why people route around controls
The usual failure mode is not malicious disobedience, it is operational bypass. If a security step adds latency, blocks common tasks, or creates repeated approval loops, users and developers will seek the fastest workable path, even when it is unofficial. Over time, those workarounds become normalised and the approved process is reserved for edge cases, not daily use.
That is why “more restriction” can actually reduce control quality. Organisations lose telemetry when work moves into unapproved tools, and they lose standardisation when the same task is completed in multiple unofficial ways. A control that is technically strong but consistently bypassed is weaker in practice than a lighter control that people will reliably follow.
The issue is not limited to access requests. It also shows up in logging, approval, token handling, deployment gates, and vault use. When teams see the security path as the hardest path, they tend to minimise contact with it, which means the security team gets less trustworthy data and fewer opportunities to enforce policy at the right point in the workflow.
Why usable security is still security
Usability and restriction are not opposites, but they do need to be balanced deliberately. Good security design narrows unsafe options while keeping the safe path easy, fast, and obvious. That means fewer manual handoffs, clearer defaults, less repeated authentication where it is not necessary, and fewer exceptions that need ad hoc approval.
This trade-off becomes more important as environments scale. A restrictive process that is tolerable for a small team often breaks down when hundreds of developers, operators, or automated workflows need access. At that point, the cost of friction is not just user frustration, it is inconsistent compliance, slower incident response, and a greater chance that critical tasks happen outside the intended control plane.
Current guidance across identity and zero trust practice points in the same direction: make the secure route the easiest route to follow, especially where access, privilege, and secret handling are involved. For a practical benchmark, teams can compare their approach to NIST Cybersecurity Framework 2.0 and NIST SP 800-207 Zero Trust Architecture, both of which support controls that are strong without relying on constant user frustration to function.
Risk and Threat Considerations
When security becomes too restrictive, the risk is not only lower adoption, it is control displacement. Users move to unofficial tools, shared credentials, or parallel workflows that sit outside monitoring, which creates blind spots and can increase the blast radius of a compromise. If the bypass path is simpler than the approved path, adversaries can also exploit the same weakly governed shortcuts.
Failure mechanism: Excessive friction pushes normal work into unapproved channels, where access is harder to review, secrets are harder to rotate, and activity is harder to attribute. The control weakens because the environment now depends on exceptions and informal behaviour rather than the designed process.
Impact: Teams lose visibility, policy enforcement becomes inconsistent, and the organisation may become slower at the exact moment it needs fast, reliable security action. In higher-risk environments, this can also increase the likelihood of secret leakage, privilege sprawl, and delayed containment during an incident.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 addresses the attack and risk surface, while NIST CSF 2.0, NIST SP 800-53 Rev 5, NIST Zero Trust (SP 800-207) and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AA-01 — Identities and Credentials | Usability affects whether identity controls are followed consistently |
| Recommendation — Design identity workflows so approved access is easier than bypassing it. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Frictions in secret and authenticator handling drive unsafe workarounds |
| Recommendation — Streamline credential lifecycle handling to reduce shadow processes. | ||
| NIST Zero Trust (SP 800-207) | Zero Trust Architecture | Zero trust depends on enforceable controls that do not collapse under user friction |
| Recommendation — Make least-privilege controls usable enough to be followed at scale. | ||
| CIS Controls v8 | CIS-5 — Account Management | Account and access processes fail when users create informal substitutes |
| Recommendation — Remove unnecessary friction from account workflows before tightening enforcement. | ||
| OWASP Non-Human Identity Top 10 | NHI-01 — Improper Offboarding | Poor usability often leaves teams delaying or bypassing offboarding and revocation |
| Recommendation — Reduce revocation friction so offboarding happens inside the approved process. | ||
Practitioner Guidance
What to prioritise: Measure where people are bypassing approved processes, then fix the most frequent friction point before adding more restriction. If a control is routinely avoided, treat that as a control-design problem, not a user-training problem.
What to verify: Check whether the secure path is actually the fastest path for common tasks such as access requests, credential use, approvals, and rotation. If the “approved” process takes materially longer than the unofficial one, adoption will usually fail over time.
Common mistake: Teams often add another gate when the real issue is workflow design. That makes the control feel stricter while increasing the incentive to bypass it, which reduces the quality of both enforcement and visibility.
Practitioner takeaway: The goal is not maximum restriction, it is durable control that people will consistently use; a security process that is easy to bypass is usually weaker than a simpler one that is followed.
