Cybersecurity Has a Design Problem. And We’re Blaming the Users for It. 

I've stood in a car park more times than I can count, phone in hand, running late for a train, only to find a machine that takes cards but not cash, and is out of order anyway. And, a app I have to download, with a location code to type in, or a QR code stuck to the machine. Somewhere in that is the correct way to pay, and I have about 90 seconds to work it out.

For me, this year marks my 30th in cybersecurity. I've talked about QR scams (quishing) on national television. And standing there, at any of those times, I could not tell you with confidence whether that code was put there by the operator or by someone else.

So, when I read about Les Howard, I recognised the situation immediately.

Howard is 61. He was visiting a town in Wales with his wife, went to the car park they'd always used, couldn't find change for the meter, and did the thing the machine appeared to be inviting him to do. He scanned the QR code. The next day, criminals began taking money out of his account in £60 chunks. His account of it is here.

His action isn't unusual. Reports mentioning QR codes have climbed roughly 700% in four years, with councils across the UK regularly peeling fraudulent stickers off their own machines.

The advice that followed is the advice that always follows. Be vigilant. Only use the official app. Don't scan codes on parking machines. Some have even gone further, like the RAC, who tells drivers to avoid QR codes in council car parks altogether, partly because many of those councils don't operate a QR payment system in the first place.

All of it sensible. All of it, I think, besides the point.

How is the User Actually Supposed to Know?

For years people have been taught that scanning a code stuck to a physical object is a normal, sanctioned way to pay. Covid accelerated this enormously. Whether it was menus, check-ins, contact tracing, ordering at the table, scanning became the responsible thing to do, the hygienic thing, the thing you were asked to do by the government and by pretty much every business you walked into at that time. Restaurants kept it. Cinemas kept it. Car park operators adopted it. The behaviour was trained into us deliberately, at scale, and for reasons that don't have anything to do with cybersecurity.

Then, criminals noticed that a sticker cost virtually nothing.

Now, those same legitimate organisations are asking the public to judge, in a car park, on a phone, while running late, whether the code in front of them is the real one. Sometimes a fraudulent code sits next to a genuine one. Sometimes the fraudulent one is all there is. Neither helps, because a QR code carries no evidence of who put it there. Looking the same is the entire point of the format. That is genuinely the ask. And when someone gets it wrong, we blame. Shame sets in, and it's no wonder, because the word we reach for is "human error."

Being fair to the people giving that advice, they're doing the only thing left available once the system has already been built this way. The guidance is downstream of a system nobody consciously designed as a whole — a payment estate that assembled itself, operator by operator, over years.

Which brings me to this truth bomb.

You can't train people to compensate for ambiguity that's been designed into the system.

That's not a slogan. It's a constraint. If the legitimate path and the fraudulent path are indistinguishable at the moment of decision, no amount of awareness closes that gap. You can raise someone's suspicion, but you can't give them information the environment has removed.

The Contradiction is Everywhere Once you Start Looking

This is where it stops being about car parks.

Your bank tells you it will never ring out of the blue and ask you to move money. Your bank also rings out of the blue, from a number you don't recognise, and asks you to confirm your identity before it will say why it's calling. Prove who you are to the stranger who phoned you.

Your telecoms provider tells you never to click a link in a text, then texts you a link to view your bill or verify a SIM change.

Employers run phishing simulations that punish clicking, then send genuine all-staff emails from unfamiliar third-party domains asking people to log in urgently before Friday.

Each is defensible in isolation. Someone had a reason. Collectively they teach a rule and then break it, which is the same as teaching no rule at all, except that it also transfers the blame.

Notice what we measure. We measure whether employees can spot a simulated phish. We do not measure whether our own legitimate communications are internally consistent, or whether a reasonable customer could tell them apart from a scam. One of those is an awareness metric. The other is a design metric. Only one is on anybody's dashboard.

Then notice who pays! :(

What's striking is how little of the cost of that ambiguity lands with the organisation best placed to remove it. The customer loses money. The bank may reimburse it. Staff peel off the fraudulent sticker. Warnings are issued.

But who owns designing the ambiguity out of the system?

Often, nobody. That isn't negligence. It's an incentive structure working exactly as built. And if no one owns the ambiguity, no one is going to design it out. So the system keeps producing advice instead.

The "Safe" Option is the Slowest

"Use the official app" sounds like a small ask, but let's play out a scenario. You're in a multi-storey with one bar of signal, or on a seafront where the network drops. Find the right app among several with near-identical names. Download it over a connection that's struggling. Create an account, verify an email you can't easily reach, set a password, enter your card details, add your registration, choose your duration. Five minutes on a good day, and impossible if the signal gives out halfway through.

Scanning the fraudulent code takes three seconds and works first time.

So, the design tells the user something the guidance never admits, and it's this: the safe path is slow, effortful and unreliable, and the dangerous path is instant. We then express surprise when a person, in a hurry, takes the fast one.

Friction isn't a neutral property of a system. It's a signal about what the system wants you to do. Put all of it on the secure route and you are, quietly, at scale, designing for the outcome you say you don't want.

And as AI strips away more of the sensory cues we once relied on to tell genuine from fake, that design problem is only going to get harder.

None of this is an argument against security technology, and it certainly isn't one against awareness. I've spent much of my career around both. It's an argument for designing systems around how people actually behave — rushed, distracted, trusting the signals we spent years training them to trust — rather than around the idealised user who reads the URL bar.

Now Scale Exactly the Same Problem Up

The same pattern shows up inside organisations, at board level, in the middle of a crisis. Only there we don't call it design. We call it culture, or governance, or bad luck.

It's why I've been developing an idea I call Cyber Survivability: whether an organisation is built to keep functioning, and keep its options open, when things stop behaving as expected. Five layers hold that up, and each can be understood as a design question:

• Judgement — Have we designed conditions in which people can make good decisions, particularly under pressure?
• Truth — Have we designed cultures and information flows in which uncomfortable information can travel?
• Authority — Have we designed decision-making authority to match accountability, particularly during a crisis?
• Capability — Have we designed the organisation around its technical capabilities so they can actually be mobilised when required?
• Collective Strength — Have we designed relationships with suppliers, partners and communities to function when normal conditions break down?

Apply them to almost any serious incident and you'll see the pattern. The engineer who knew three weeks early and couldn't get it heard. The executive with the authority to shut the network down but not the information to justify it, sitting beside the person who had the information and no authority. The backups that restored beautifully into an environment nobody could rebuild in time. The supplier whose contract said one thing and whose behaviour at 2am said another.

Each gets filed as a separate problem — people, governance, technology, procurement. We diagnose them separately because that's how we've organised cybersecurity and cyber resilience. The system experiences them together.

The components work. The relationships between them don't.

The Parts Can Work. The System Can Still Fail

Cybersecurity has become extraordinarily sophisticated at solving for individual components. Give us an identifiable problem and we'll build a control for it: MFA, EDR, immutable backups, awareness platforms, policies, third-party assessments, tabletops. Each addresses something real. Each can be procured, deployed, evidenced and audited.

But assembling good components does not automatically produce a good system. A shelf of excellent parts is inventory, not architecture.

Authentication gives us the cleanest example. Passkeys and FIDO2 are among the strongest things our industry has built, because the credential itself is resistant to phishing — it's bound to the domain it was made for, so it can't be handed to a lookalike site at all. The user can be fooled. The credential can't.

But put that excellent component alongside weaker routes like SMS and one-time codes, emailed links, push approvals and helpdesk resets, and you haven't necessarily built a phishing-resistant system. Attackers don't need to defeat the strongest component if the design leaves them a way around it. That's the principle behind authentication downgrade attacks: rather than attempt the passkey, they engineer the login flow so the user is offered something weaker instead. Even Microsoft now frames the remaining risk as the fallbacks and the recovery path, not the credential.

Phishing resistance isn't a property of the strongest component. It's a property of the system. The technology may be excellent. The people may be excellent. The processes may be excellent, but excellence in the parts cannot compensate for poor design of the whole.

Engineers have understood this for a very long time. Performance depends not only on the components but on their connections, the loads placed on them, and how the whole behaves when conditions change.

Cyber needs to think much more seriously about the connections.

I Used to Make Patterns for a Living

Before cybersecurity, I was a textile designer. I made patterns. For years I treated that as a slightly unusual footnote in my biography, and hid it as I didn't come from a tech background. Almost 30 years into cybersecurity, I'm beginning to think it explains more about how I see this industry than I realised.

Because what I find myself doing, again and again, is looking for patterns. Relationships. Hidden assumptions. Friction. Dependencies. What happens at the joins. What changes when one part stops behaving as expected. I don't think I ever stopped being a designer.

And I think cybersecurity needs more of that way of thinking, not less.

Survivability is a Design Objective

Cyber survivability is not a design problem. It's a design objective.

A survivable organisation is one deliberately designed so that when prevention fails (and it will) or when something behaves in a way nobody anticipated, it retains enough Judgment, Truth, Authority, Capability and Collective Strength to keep functioning and to preserve viable choices.

That last part is the whole thing. When organisations find themselves in serious trouble during a cyber crisis, the defining problem is often not that they've run out of technology. It's that they've run out of good options — forced into a decision at 3am with no good moves left, because every earlier decision quietly removed one.

Which is why, when I talk about recovering with options intact, I'm not describing something you improvise on the night. Options are structural. They're either designed in beforehand or they aren't there.

Resilience is the disciplined preservation of choice.

The Bigger Question

Cybersecurity has spent decades making the individual parts stronger, and it has genuinely succeeded. The controls we have now would have looked like science fiction to me in 1997.

But I keep coming back to those car parks.

Nothing about them looks obviously broken. There's a machine. There are payment options. There's a QR code. There's security advice telling customers how to stay safe.

And a 61-year-old man on holiday still met a malicious payment route that looked sufficiently like the legitimate one to fool him.

Perhaps we've been trying to answer the wrong question i.e., solving for individual components while failures keep emerging in the connections between them.

Perhaps the next stage of this industry's evolution isn't a better part.

It's learning to design the whole.

And if you want somewhere to start, it isn't a new control. Go and look at where your own legitimate processes ask people to do the things your security advice warns them against. Every organisation has some. Then find out who has the authority to change them. That second answer is usually the more revealing one.

---

Now I Want to Hear from You

Tell me, if cyber survivability is a design objective, who owns the design of the whole? I don't mean the individual controls, as we know who owns those. I mean the whole. Because, I don't think our org charts have a good answer to that yet. Do you?

Join me on LinkedIn for the conversation. I'd love to hear your view.