Zero trust without the theatre

Zero trust has had the misfortune of becoming a product category. It started as an architectural claim — that the network location of a request tells you nothing useful about whether to honour it — and it has been gradually redefined as a shopping list. Buy the identity provider, buy the microsegmentation appliance, buy the posture agent, put the logo on the slide.

The architectural claim is correct and worth taking seriously. The shopping list is how organisations end up with eleven new tools and the same lateral movement risk they had before.

The question the tools cannot answer for you

Every zero-trust decision reduces to one question: what is this identity allowed to do, right now, given what we know about it? Tools can enforce an answer. They cannot produce one. If nobody has decided what a service account is for, no policy engine will infer it, and what you will actually deploy is a default-allow rule with a strict-sounding name.

So the work starts somewhere unglamorous: enumerate the identities — human and machine — write down what each one legitimately needs, and find out who owns that decision. This is tedious and it is where the security actually comes from. In practice it also surfaces the real findings. The credentials nobody can account for. The integration that runs as a domain administrator because that was the fastest way to make it work in 2021. The former contractor's key still in the deployment pipeline.

Compliance is a floor, and it is lower than you think

SOC 2 and ISO 27001 are worth having. They are evidence that controls exist and are reviewed, and they open doors commercially. But a framework asks whether you have a policy and whether you follow it. It does not ask whether the policy is any good.

You can pass an audit with broad standing access, as long as the access is documented, approved, and reviewed on schedule. An attacker does not care that the over-permissioned role was signed off by two directors. Treat certification as the floor it is, then ask the harder question separately: if one of these credentials leaked this afternoon, what is the blast radius, and how would we know?

What we actually recommend building first

Not a purchase. Three capabilities, in this order.

Know what you have. An inventory of services, data stores and the identities that touch them. Incomplete and maintained beats comprehensive and stale.

Make access explicit and expiring. Standing access is the thing that turns a single compromised credential into an incident. Short-lived, scoped, and requested-when-needed is worth more than any detection tool you could buy with the same budget.

Be able to see what happened. Logs that a human can actually query during an incident, retained long enough to be useful, covering authentication and authorisation decisions. Detection without this is guesswork.

Microsegmentation, posture checks and continuous verification all have their place, and they are considerably more effective once those three are in hand. Sequenced the other way round, they become expensive theatre — controls enforcing policies nobody wrote, monitored by nobody with time to look.

Security that holds up is mostly a matter of knowing what your systems are supposed to do, and being able to tell when they stop doing it. The architecture follows from that. It does not substitute for it.