A control is failing when users repeatedly work around it, delay adoption, or use insecure shortcuts to finish routine tasks. Another sign is that the control is only followed by expert users while everyone else treats it as optional. Those patterns show the mechanism may be technically sound, but operationally unusable.
When a security control is hard to use, the failure usually shows up in behaviour, not in policy language. People start bypassing it, invent workarounds, or postpone adoption until they are forced to comply. That is often the clearest signal that the control’s design is misaligned with real operational work.
The strongest warning sign is repeated non-compliance by otherwise willing users. If a control is routinely followed only by experts while everyone else treats it as optional, the issue is often usability rather than intent. In practice, that means the control may exist on paper but is not reliable as a day-to-day safeguard.
Another sign is the appearance of insecure shortcuts, such as shared accounts, copied tokens, manual exceptions, or side channels that let teams finish tasks faster. Those workarounds do not merely reduce convenience, they usually change the effective risk profile because the control no longer governs the activity it was meant to constrain.
Why Hard-to-Use Controls Fail in Practice
Controls fail when the effort required to comply is out of proportion to the task they protect. If a check interrupts routine work, adds too many steps, or depends on specialist knowledge to complete correctly, users will optimize for getting work done. That is why friction is not just an adoption problem, it becomes a control integrity problem.
This is especially visible in controls that depend on precise human execution. When the user must remember a sequence, manage exceptions, or interpret ambiguous prompts, small usability flaws turn into inconsistent enforcement. The mechanism may still be technically sound, but the operating model makes it unreliable under normal workload conditions.
Hard-to-use controls also tend to drift into exception culture. Once people believe the control slows delivery, they ask for one-off waivers, permanent bypasses, or “temporary” alternative processes that become the real process. Over time, the control becomes a ritual rather than an effective barrier.
What the Failure Looks Like on the Ground
Operational symptoms are usually easy to spot if teams look beyond formal compliance rates. You may see delayed rollouts, repeated help desk friction, elevated exception volume, or inconsistent enforcement between teams. A control that requires frequent intervention to complete ordinary work is signaling that its design cost is too high.
It is also useful to compare stated control coverage with actual user behaviour. If users complete the protected activity through alternate channels, the control is not fully governing the process. That gap between intended and actual behaviour is often more informative than any single audit result.
Controls that are too hard to use can also create hidden security debt. Users may store credentials insecurely, share access, skip verification steps, or reuse older workflows that no longer match policy. The risk is not only that the control is ignored, but that its failure encourages compensating practices that are less visible and harder to reverse.
How to Judge Usability Without Losing Security
The practical test is whether the control can be completed correctly by the intended user population during real work, not just by the most experienced operator in a controlled demo. If routine users need repeated coaching, if completion time is materially longer than the task warrants, or if exceptions are the norm, the control deserves redesign review.
Look for whether the friction is essential or accidental. Some control cost is necessary, but avoid assuming all friction is protective. A good control should be explicit about the risk it reduces, predictable in how it behaves, and consistent enough that users do not need to improvise around it.
Where the control protects a high-value action, the right question is not “can users eventually make it work?” but “does it remain reliable when people are busy, under pressure, or switching contexts?” That is the point at which usability weaknesses become security weaknesses.
Risk and Threat Considerations
When a control is difficult to use, the main risk is that people will route around it, creating unapproved paths that weaken governance and increase exposure. The same friction can also encourage insecure workarounds, which are often less visible than the original control and harder to detect.
Failure mechanism: Excessive steps, unclear workflows, or specialist-only operation pushes users toward bypasses, exceptions, shared workarounds, and delayed adoption, which breaks consistent enforcement.
Impact: The organisation may end up with nominal control coverage but weak real-world protection, higher operational error rates, and a larger attack surface through unmanaged exceptions and informal processes.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
CIS Controls v8, NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS-5 — Account Management | Usability-driven bypasses often expose weak account and access control handling. |
| Recommendation — Simplify and standardize account workflows so users do not resort to insecure bypasses. | ||
| NIST CSF 2.0 | PR.AA-01 — Identities and credentials are issued, managed, verified, revoked, and audited for authorized devices, users and services | A hard-to-use control often fails when identity workflows become impractical in daily use. |
| Recommendation — Align identity workflows with actual operations so authorized use remains the easiest path. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | Access controls lose effectiveness when users routinely work around them. |
| Recommendation — Design access controls so routine tasks can be completed without informal exceptions. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Overly burdensome privilege controls are frequently bypassed, undermining least-privilege enforcement. |
| Recommendation — Apply least privilege in a way that users can sustain without recurring workarounds. | ||
Practitioner Guidance
What to verify: Check whether the control can be completed by ordinary users without repeated assistance, and whether exception handling is becoming the default path. If the answer is yes, treat usability as a control failure mode, not a training issue.
Decision rule: If users are bypassing the control to complete normal work, prioritise redesign of the workflow before asking for stricter enforcement. Enforcement alone usually increases frustration without fixing the underlying operational mismatch.
Practitioner takeaway: A control is too hard to use when people can only follow it by making their work exceptional, because a safeguard that depends on constant user heroics is not dependable control.
Related resources from NHI Mgmt Group
- What are the signs that security awareness messaging is too hard for non-technical audiences to use?
- How should security teams use IAST and RASP in NHI governance?
- What are the signs that Exchange Online PowerShell access is failing because of identity or session control issues?
- What are the signs that an AI security control is failing against jailbreak attempts?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 25, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
