Zero Trust Is Not a Setting

Somewhere along the way, security became a checkbox. Firewall? Enabled. VPN? Configured. MFA? Activated. The list gets ticked, the audit gets signed, and the network underneath stays exactly as trusting as it always was.

This is the thing about zero trust that the product category has quietly buried: it is not a control you turn on. It is a property a system has once you have removed implicit trust from it, one relationship at a time. Nothing you can buy arrives holding that property, because the trust you are removing is not in the product — it is in the assumptions your services already make about each other.

The assumption doing the work

Almost every internal system contains a sentence that nobody wrote down: if it can reach me, it is allowed to talk to me. That sentence is what a perimeter is for. Put a hard shell around a set of machines, and reachability becomes a reasonable proxy for authorisation, because the only things that can reach you are things somebody deliberately let in.

The proxy stops being reasonable the moment the shell has more than a few doors. A VPN concentrator, a CI runner, a managed database with a public endpoint, a vendor integration, a laptop — each is a legitimate way in, and each one converts "inside the network" from a meaningful statement into a description of where a packet happens to have come from. The controls on the list are all real controls. None of them touches the sentence.

So the useful question is not which zero trust product you have. It is: what would still be true if an attacker were already inside? If the honest answer is "they could reach most things, and most things would answer," then the perimeter is still doing the authorisation, and everything else is decoration on top of it.

Identity that belongs to the workload

The replacement for reachability is identity, and specifically an identity the workload can prove rather than one it inherits from its surroundings. An IP address is not an identity. A subnet is not an identity. A security group is a statement about who may attempt a connection, which is a different and much weaker claim than who is making it.

What you want instead is for the payments service to be able to demonstrate, cryptographically and per-request, that it is the payments service — and for the ledger to make its own decision about whether the payments service may do this particular thing. That is the whole shape of it. Authorisation moves from the network to the callee. The network stops being a security boundary and goes back to being what it always was: a way of moving bytes.

This is also where the effort actually lives, and why no purchase completes it. Issuing identities is tractable. Getting every service to check them is a change to every service. The mesh or the gateway can carry the credential; only the application can know that a valid token from the reporting service is nonetheless not permitted to issue a refund.

Scope is the part people skip

Removing implicit trust from the network is only half of it. The other half is that a credential which proves identity perfectly can still be far too powerful.

The pattern to look for is the credential nobody can describe without reading the code. If you ask what a service account may do and the answer is a shrug followed by a search, its scope is whatever it accumulated. Those grow monotonically: someone needed one more permission during an incident, added it, and there has never been a moment when removing it was anyone's job.

A credential worth having is one you can describe in a sentence, that expires faster than an attacker can make use of it, and that is bound to the workload rather than stored somewhere a human could copy. Short lifetimes matter more than they look, because they change what a stolen credential is worth. A token good for five minutes is an inconvenience. A key in an environment variable, valid until someone rotates it, is a permanent foothold.

Doing it without a rewrite

The reason this stalls is that "remove implicit trust everywhere" is not a piece of work anybody can schedule. It has no edge, no completion criterion, and no obvious first step, so it becomes a strategy slide rather than a ticket.

The way through is to stop treating it as one project. Every implicit trust relationship is its own small piece of work with its own owner and its own review. Pick the ones where the consequence of being wrong is largest — the paths that touch money, personal data, or the ability to change infrastructure — and do those first. Each one is finishable in an afternoon or a fortnight, and each one is independently valuable, which is what a five-year programme is not.

Two things make that sequencing possible. The first is knowing which relationships exist, which is usually less obvious than it should be and is a good argument for building the inventory before the policy. The second is being able to run a new rule in report-only mode long enough to find out what it would have broken, because the fastest way to lose organisational permission for this work is to take down an internal system with a policy that looked obviously safe.

What "done" looks like

There is no done. That is not a failure of the model; it is the model. Every new service, every new integration, every new vendor arrives with a fresh set of assumptions about who may talk to whom, and the work is to notice them while they are still cheap to change.

What you can have is a system where the honest answer to "what if they are already inside?" is bounded rather than catastrophic — where a compromised workload gets an attacker exactly what that workload could do, and nothing else. That is a real property, it is worth a great deal, and there is no setting for it.