Security versus Usability

Definition

Security controls impose friction. Beyond a threshold, users route around them, and a circumvented control provides no protection while creating the belief that it does.

The principle that resolves most cases

A control that is circumvented is less secure than a weaker control that is followed.

The evidence is everywhere: password rotation policies producing predictable increments written on notes; VPN requirements producing shadow tools; approval processes producing shared accounts; strict data controls producing spreadsheets emailed between colleagues.

In each case the strict control produced a worse security outcome than a moderate one, because behaviour adapted.

Where the trade is real and where it is false

False trades — cases where security and usability improve together, and which should be exhausted first:

• Passkeys and modern authentication — more secure and easier than passwords.
• Single sign-on — one strong authentication rather than many weak ones.
• Short-lived credentials issued automatically, replacing long-lived secrets people copy.
• Secure defaults, so the safe path requires no effort at all.
• Automated dependency updates, removing a manual task and a vulnerability class.

Genuine trades:

• Multi-factor authentication on every action versus session-based.
• Approval workflows for privileged operations.
• Restricting data access, at the cost of legitimate analysis being slower.
• Aggressive session timeouts.

How to decide

Apply friction proportionate to risk, and only where risk is concentrated. Step-up authentication for a payment change rather than for reading a dashboard. Break-glass elevation with logging and automatic notification rather than permanently restricted access.

And watch for the workaround. If a control is in place and people have found a way around it, that is the most important security finding available — it tells you both that the control is not working and exactly where the pressure is.

Failure scenarios

• Controls designed without the workflow in mind, then circumvented.
• Uniform friction regardless of risk, so users become desensitised and approve everything.
• Security as a gate rather than as a design input, arriving late and being negotiated away.
• No break-glass path, so an emergency produces an unlogged, unreviewed workaround.

Interview question

"A security control is being circumvented by most of the team. What do you conclude and what do you do?"