A Stronger Control Nobody Uses Protects Nobody

Before you strengthen a security control, find out whether anyone will actually use it. A control that is cryptographically impeccable and never switched on protects nobody, and it quietly consumes the effort that could have gone to the risk that is really in play. I've come to treat adoption as part of the security design, not a rollout detail that follows it.

The example that keeps nagging at me is two-factor authentication, because it is such a good idea and so easy to get wrong in practice. I recently watched a security review for a healthcare customer circle a question about a locked-down handheld device. The device is registered, its identity is known, it can only reach the network from the building's own wireless, and it sits physically inside a hospital. Someone in the review objected that a password plus that device could not count as two factors, because both are things you have. That isn't quite right, since a password is something you know, but the more interesting problem was what came next. What exactly did the reviewer imagine a clinician doing instead? Picking up a phone, with gloves on, in the middle of a procedure, to read out a six-digit code that expires in thirty seconds?

That question is the whole argument. A control has to be assessed against the person who will meet it, in the place they will meet it. In an operating theatre, phones are often not even in the room. A second factor that depends on a personal device is either bypassed by someone holding a phone up to a window, or it gets worked around in a way the security team never sees. Both outcomes are worse than the arrangement it replaced, and both would pass an audit that only checked whether the factor existed.

None of this means the reviewer was foolish. Checklists exist because people forget things, and "two independent factors" is a sound principle. The trouble is that a principle applied without the context it was written for turns into a ritual. The ritual satisfies the document and leaves the hospital exactly as exposed as before, plus one more thing for staff to get around.

The control that was built and never used

There's a second half to this story, and it's the one I find more uncomfortable because I've lived it. A different health customer once asked for the seed behind time-based one-time codes to use a stronger hash than the usual default. It is a reasonable request on paper. We did the work, shipped it, and everything behaved as designed.

Then the practical limits showed up. Many of the common authenticator apps people already carry don't support the stronger option, and for something that is only valid for thirty seconds it is difficult to argue the extra strength buys anything. No realistic attacker is breaking a thirty-second code by brute force. The effort protected against a threat nobody faces. And as far as I can tell, not a single user in that environment ever enrolled for the feature. It wasn't even switched on in production.

So a team spent real engineering time, the customer got to tick a box, and the actual security posture did not move at all. Worse, the people responsible felt safer. That feeling is the dangerous part. A completed control gives you a reassuring sense that the problem has been handled, and a sense of safety that isn't earned is more dangerous than uncertainty, because uncertainty at least keeps you looking.

Where the real risk usually is

When I look at where entrusted data actually leaks in organisations like this, it is rarely the strength of a hash. It is far more often a person who types a password into the first convincing page a search engine offers, or a credential that is reused somewhere less careful. That's a human and behavioural problem, and the strongest cryptography in the world sits entirely upstream of it.

I think we sometimes confuse the rigour of a control with the relevance of it. A stronger algorithm feels more serious than an awkward conversation about how people really log in. Specifying the algorithm is easy. Asking "what will a tired person do at three in the morning with this in front of them?" is harder, partly because it exposes that our design may not survive contact with the people it's meant to protect.

What I'd ask instead

I'm not arguing for weaker security. I'm arguing for asking three questions before a control goes into a requirement. Who has to use this, and in what physical and emotional state? What threat does this specific strength address, and is it one we realistically face? And how will we know, a few months after launch, that people are using it rather than routing around it?

The last question is the one that usually gets skipped, and it is cheap to answer. Enrolment numbers, bypass rates and support requests tell you whether a control exists in practice or only on paper. If the number is zero, you have your answer, and it has nothing to do with how well the control was built.

Commercially, this matters as well. Engineering time spent on a control nobody adopts is a cost the customer eventually pays for, and it takes the place of work that would have reduced real exposure. Good security is a form of respect for the people who hold the risk. Sometimes that means doing more. Often it means being honest that the thing that was asked for won't help, saying so politely, and offering the version that fits the room it will be used in.

I'd rather ship a modest control that clinicians use every shift than an unimpeachable one that exists mostly as an entry in a spreadsheet. The first one protects patients' data. The second one protects the document.