A control can be secure on paper and still make the system less safe.
Force people to create a new complex password every month and some will write it down. Block every file-sharing service without providing an approved alternative and project data will move through personal accounts. Add six approval steps to emergency access and engineers will look for a permanent shortcut.
The problem is not that users dislike security. The control has failed to account for the work surrounding it.
Friction changes behaviour
Security teams often evaluate a control by asking whether it blocks a threat. Users evaluate it every time they try to finish a task.
That difference matters because people adapt. They reuse credentials, share accounts, copy data to an easier system, delay updates, or ask an administrator for a broad exception. Each workaround creates a path the original design did not consider.
Friction is not always bad. A second approval for a large financial transfer is reasonable. The same approval for reading an internal lunch menu is not. The control should match the consequence of a mistake or compromise.
Password rules are a useful warning
Long complexity rules and frequent forced resets look strict. They also encourage predictable changes such as adding a month or number to the previous password.
A better design combines unique passwords, a password manager, MFA, breach detection, and rate limits. Each control handles a different failure. The user only has to remember the password manager’s primary credential and follow a recovery process that the organization has tested.
The lesson goes beyond passwords. Do not ask people to perform repetitive security work that a system can enforce more reliably.
MFA needs its own threat model
MFA reduces the value of a stolen password, but implementations differ. SMS codes, push notifications, authenticator codes, and security keys do not resist the same attacks.
Repeated push prompts can train a user to approve one by mistake. A phishing-resistant method is a better fit for administrators and access to sensitive systems. Lower-risk services may accept a less demanding method.
Recovery deserves equal attention. An attacker who can talk the help desk into resetting MFA has bypassed the strongest part of the login process.
Updates show the operational tradeoff
“Patch immediately” is good advice until an update breaks a production application. “Wait until it is fully tested” is comfortable until an attacker exploits the delay.
The useful answer is a risk-based patch process. Internet-facing devices and exploited vulnerabilities need a faster path. Critical applications need representative testing, rollback plans, and owners who can accept a short outage. Low-risk systems can follow the normal maintenance cycle.
Auto-update works well for many personal devices because the alternative is indefinite postponement. In an enterprise, automation still needs staged deployment and visibility into failures.
Consider an internet-facing VPN appliance with a critical security update. The strict policy says every update must spend two weeks in testing. The emergency policy says exploited edge-device flaws move through a shorter path with a configuration backup, a tested rollback, a named approver, and validation of authentication and tunnels after the reboot.
Skipping all testing is reckless. Waiting two weeks because the normal form says so is also reckless. The workable control changes the process when exposure and exploitability change.
The same tension appears at work
Bring Your Own Device policies are a common example. Employees prefer familiar hardware. The company still has to protect client data and remove access when someone leaves.
A blanket ban may be correct for some work and impossible for the rest of the business. A workable policy can separate corporate and personal data, require screen lock and encryption, restrict downloads, and deny sensitive access from devices that do not meet the standard.
The right control depends on the data and task. A contractor reading a public knowledge base does not need the same device posture as an administrator changing production firewall policy.
What “good enough” should mean
“Good enough” is not permission to ignore a risk. It means the control reduces the important risk, fits the work, and can be maintained.
I use five questions:
- Which attack or mistake does this control address?
- What happens when the control blocks legitimate work?
- How will users work around it?
- Can the team detect those workarounds and failures?
- Is the remaining risk understood and owned?
If the answer to the first question is vague, the control may be security theatre. If nobody has considered the third, the design is unfinished.
Measure the failure modes
Track what people do, not only whether the policy exists.
For authentication, measure failed logins, recovery requests, locked accounts, MFA denials, and suspicious approvals. For endpoint controls, measure exceptions, disabled agents, update failures, and time spent outside the patch target. For data controls, inspect blocked transfers and the channels users switch to afterward.
Support tickets are security data. A sudden increase may show that the control is broken, confusing, or too aggressive.
Where I land
The strongest control is not always the strictest one. It is the control that reduces a real risk and survives ordinary use.
Make the secure path the shortest path when possible. Add friction where the consequence justifies it. When people still need an exception, make it visible, narrow, owned, and temporary.
That is less satisfying than declaring a universal rule. It is also how security survives contact with production.
This article argues from control design rather than one named deployment. A useful follow-up would compare exception volume, support tickets, and control failures before and after a real policy change. Without those measurements, “usable security” can become another slogan.