TL;DR: Controls lose effectiveness when they are so disruptive that people build lower-friction workarounds, according to Coalition. Security programmes work better when the safe path is also the easiest path, and friction is spent only where risk justifies it.
Editorial analysis by NHI Mgmt Group, based on content published by Coalition: “Designing Security for the People Who Have to Live With It”.
Key questions
Q: When does a security control create more risk than it reduces?
A: A control becomes counterproductive when it drives users toward unsupported workarounds, exception handling, or shadow processes that are less protected than the original path.
Q: What breaks when organisations assume prevention will always hold?
A: Recovery planning becomes vague, authority stays undefined, and incident response turns improvised when the first real event arrives.
Q: How should security teams balance protection and usability without weakening governance?
A: Start by treating friction as a design cost that must be justified by risk, not as proof of security.
Practitioner guidance
- Define a friction budget for every major control change Assess the user time, exception rate, and operational overhead each new control will consume before approval.
- Review where teams are routing around security controls Map the highest-friction journeys in access, authentication, approvals, and incident workflows, then identify the workarounds people already use to finish their jobs.
- Pre-decide breach authority and containment roles Document who can isolate systems, who communicates externally, and what operational services must remain available if a control fails or a security event escalates.
Bottom line: Security programmes lose effectiveness when controls are so disruptive that users create their own lower-friction workarounds.
Glossary terms: Security Friction, Control Failure Readiness, Organisational Trust Budget
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
Friction is a governance cost, not just a user-experience problem. Security teams often describe controls as if inconvenience were the price of safety, but in practice that cost is paid in workarounds, exceptions, and lower trust. In identity programmes, the controls most likely to be bypassed are the ones that repeatedly interrupt legitimate work without reducing meaningful risk. The practitioner lesson is to design controls that change behaviour without encouraging shadow processes.
A question worth separating out:
Q: Why do security teams lose credibility when controls feel misaligned with real work?
A: Because advice that is too detached from day-to-day operations is easy to ignore, and people remember when a security rule makes their job harder without a clear risk payoff. Credibility depends on showing that the security team understands the operational cost of its decisions and applies the same standards internally that it expects elsewhere.
👉 Read our full editorial: Frictionless security turns trust into a measurable design choice