Security works best when it is as transparent as possible to the end user while still achieving the desired aim. Every additional click, prompt or password challenge is a tax on productivity, and users will pay that tax only for so long before they start looking for ways to avoid it.
Back in the mid-2000's, a previous employer of mine was undertaking a major company-wide project to replace an ageing Microsoft Windows NT 4.0 Workstation fleet with Windows 2000. The company operated in the high-security defence research space and up until this point required each night that every computer — a chunky beige mini-tower device — be completely shut down and the hard disk be physically removed and stored in the individual's lockable under-desk cabinet. The hard disks were mounted in special removable cages to make this easy, and everyone understood that this was just the way things were. Come 5pm you saved all your work, shut down your computer, locked the disk away, put the key in your pocket and went home. At 9am the following morning you slotted the disk back in and started your machine up.
With the roll-out of Windows 2000 things changed. Someone somewhere in 'security' decided physically removing hard disks was the old way, and we no longer needed to go through this process each day. Instead, every computer now had full-disk encryption software as standard — a third-party product, as BitLocker and TPM chips weren't yet available — so the only thing you had to do each morning was type in a pair of codes that were regenerated every 30 days. You still needed to shut your computer down every night, but at least you didn't need to unplug anything anymore. Progress!
I'm sure the astute reader will have seen the outcome of being forced to remember a pair of randomly generated codes coming a mile away — the ubiquitous Post-it note began to appear under every keyboard.
Whether or not either of these approaches were 'secure' is something security professionals could debate at some length, and the point of this story isn't to dissect the policy-making process (yet), but to highlight something in civil engineering referred to as a desire path.
Desire Path: an informal track worn into the ground by people repeatedly choosing their own path, usually a shortcut, instead of following the intended one.
When faced with the choice, most people will choose easy over difficult. Having to remember random codes — especially ones which changed every 30 days — was a lot harder than remembering to simply unplug something, so people didn't bother remembering them, they just wrote them down.
Were there any repercussions for failing to follow this new security protocol? Not really. The security people who decided this new policy might have carried out occasional spot-checks at desks near their own offices, but our office was at a site 150 miles away and in the 13 years I worked there I didn't see anyone check.
Sticky notes under keyboards, personal email accounts used to move files, unsanctioned SaaS tools adopted by entire teams — these are not failures of user awareness so much as predictable responses to controls that get in the way of getting work done.
I saw a variant of this play out with a file-sharing policy a few years later. The organisation blocked all consumer cloud storage at the network edge — Dropbox, personal Google Drive, the lot — in response to a data-loss incident elsewhere in the sector. Sensible enough on paper. Within a fortnight, a design team who needed to send large asset files to an external agency had worked out that the block only applied to the corporate network, and started tethering to personal mobile data to upload files from the same laptops. The control hadn't stopped the behaviour; it had just moved it somewhere with no logging, no DLP, and no visibility at all. The team weren't being reckless — from where they sat, the alternative was missing a client deadline, and no one had given them a sanctioned way to move a 400MB file to an external party. They found their desire path, same as we did with the hard disks. The only difference was this one was invisible to the people who'd built the fence.
This is the sharper edge of "a circumvented control is worse than no control at all" — it isn't only that the protection is illusory, it's that the workaround typically happens somewhere entirely outside the organisation's line of sight. No control at all is at least an honest gap. A circumvented one masks the gap while removing your ability to see it.
The more friction a control introduces, the more likely it is to be circumvented, and a circumvented control is worse than no control at all, because it creates the illusion of protection while quietly eroding it.
The corollary is that the most effective controls tend to be the ones users never notice — and it's worth being precise about why. Some succeed because they're ambient: FaceID, EDR agents, automatic patching, DNS filtering — they run continuously in the background and ask nothing of the user in the moment. Others succeed because they absorb the decision the user would otherwise have to make themselves: certificate-based device trust and conditional access don't ask "is this login legitimate?", they answer it using signals the user was never equipped to evaluate anyway. And some succeed because they're proportionate — they only introduce friction at the point where the risk genuinely justifies it, rather than applying a flat tax to every action regardless of stakes.
When friction is genuinely necessary, that third category is the model: step-up authentication for a sensitive transaction, rather than a blanket prompt for every login; a confirmation dialogue when emailing classified material externally, rather than blocking all external email; a brief check when a new device enrols, rather than a daily ritual.
Designing security this way takes more effort, not less. It requires actually understanding how people work, mapping the journeys they take through systems, and being willing to absorb complexity into the architecture so that the user does not have to. It also requires a cultural shift away from treating security as a gate and towards treating it as a service — one whose job is to make the safe path the easy path. Done well, the result is a workforce that complies without thinking about it, because the controls are aligned with how they would naturally want to behave anyway. Done poorly, security becomes the thing people route around, and the organisation ends up with policies on paper and risk in practice.
I think about that under-desk cabinet occasionally. The lock on it was, in its way, a perfectly good control — it's just that it asked something of thirty people, every single evening, forever, and never once explained why. Twenty years and several careers later, the lesson hasn't really changed: the strongest lock is the one nobody has to remember to use.