The Zero Trust rollout I watched go badly did everything in the wrong order. It started with the network team, on a Friday, with a policy change that broke a scheduled job nobody knew existed. That job fed a report the finance team needed on Monday. By the following week the project had a reputation, and every subsequent change took three months of negotiation.
The technical decisions were fine. The sequencing was fatal. Zero Trust touches every access path in a company, which means the rollout is a change management problem wearing a security hat — and treating it as purely a security project is how it stalls.
Here is the phased approach that has actually worked, and why the order matters more than the tooling.
What Zero Trust Means, Minus the Vendor Layer
The term has been printed on so many products that it has lost shape. The original idea is narrow and useful: stop treating network location as evidence of trust.
The old model was a perimeter. Get past the firewall or onto the VPN and you were inside, and inside things trusted each other. The problem is that it collapses completely on first breach — one compromised laptop, one stolen VPN credential, one contractor's machine, and the attacker has the same standing as an employee.
Zero Trust replaces the location question with three others, asked on every request: who is this, what device are they on, and are they allowed to do this specific thing right now?
That is the whole concept. Everything else is implementation, and you do not need to buy anything labelled Zero Trust to make real progress on it.
Phase One: Know What You Have
Every failed rollout I have seen skipped this and started enforcing.
Before changing any policy, produce three inventories. Applications and services — everything internal, including the ones running on a machine under someone's desk. Identities — every human account, service account, API key and integration, including the ones belonging to people who left. Access paths — who and what currently reaches each application, and how.
This is unglamorous and it takes weeks. It also finds things. Every time I have been involved in one of these, the inventory has surfaced at least one forgotten server with an open port, one shared account whose password is in a document, and a handful of active credentials for people who left months ago.
Cleaning those up before you start enforcing gives you two things: immediate risk reduction, and an accurate picture of what your policies will actually break.
Phase Two: Make Identity Strong
If network location is no longer proof, identity carries the entire load. It has to be worth that.
One identity provider. Every application authenticates through it. The scattered local accounts are the problem — you cannot revoke access reliably when it exists in fourteen places, and offboarding becomes a checklist somebody forgets.
Phishing-resistant MFA for anything that matters. This is the highest-value control in the entire programme and the one most worth spending political capital on. SMS codes and app-generated codes can both be relayed in real time by a convincing fake login page — the attacker proxies your credentials to the real site while you watch a spinner. Passkeys and hardware keys cannot be relayed, because the credential is cryptographically bound to the real domain. If you protect two things this way, protect your identity provider and your cloud console.
Short-lived credentials everywhere. Sessions that expire. Cloud access through federated roles rather than static keys. CI authenticating through OIDC rather than a stored secret. A leaked credential that expires in an hour is an incident; one that never expires is a breach that may already have happened.
Service accounts treated as first-class identities. They are usually the weakest part of an otherwise decent setup — over-permissioned, shared between systems, with credentials that have not rotated since creation and no owner. Give each one a single purpose, a named owner, minimal permissions and an expiry.
Phase Three: Devices, Then Applications
Once identity is solid, add the device signal. A valid credential on an unmanaged, unpatched machine is a weaker assurance than the same credential on a managed one, and the policy should reflect that.
Start with visibility rather than enforcement — report on what is connecting before you block anything. Then enforce gradually: sensitive systems first, requiring a managed device with disk encryption and current patches, while lower-risk applications stay accessible more broadly.
Then move applications off the VPN one at a time, front-ending each with an identity-aware proxy so that reaching it requires authentication and authorisation rather than network position. One application per change window, starting with the one whose owner is most cooperative and whose failure is least damaging. Not everything at once, and never on a Friday.
Phase Four: Segment the Blast Radius
The internal network is where perimeter thinking survives longest. Two services in the same VPC trusting each other because they are in the same VPC is exactly the assumption Zero Trust exists to remove.
What that means in practice: services authenticate to each other, typically with mutual TLS or signed service tokens. Network policy defaults to deny, with explicit rules for the connections that should exist. Production is a separate account or subscription from everything else, with separate credentials, so a compromise in staging does not walk into production.
# Default deny, then allow only what should exist.
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata: { name: default-deny, namespace: production }
spec:
podSelector: {}
policyTypes: [Ingress, Egress]
---
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata: { name: orders-to-payments, namespace: production }
spec:
podSelector:
matchLabels: { app: payments-api }
ingress:
- from:
- podSelector:
matchLabels: { app: orders-api }
ports: [{ protocol: TCP, port: 8443 }]
Do this in report-only mode first if your platform allows it. You will discover connections you did not know existed, and it is better to discover them in a log than in an outage.
Access Reviews: The Boring Control That Works
Permissions accumulate. Someone needs production read access for a migration in March and still has it in December. A contractor's account outlives the contract. A team lead gains permissions with each project and never sheds any.
A quarterly review where each manager confirms their team's access is unfashionable, mildly irritating, and catches more real risk than most tooling. Pair it with automatic expiry on elevated access — grant it for the duration of the task, not permanently — and with just-in-time elevation for administrative work, where someone requests production access, gets it for four hours, and it disappears.
Why the Sequencing Matters So Much
Every phase above increases friction somewhere. A Zero Trust programme that generates more friction than trust gets escalated, exempted and eventually abandoned — which is what happened to that Friday rollout.
So: inventory before enforcement, so you know what will break. Visibility before blocking, so you can warn the people affected. One application at a time, starting with a friendly owner. A working alternative provided before the old path is closed. And an exception process that exists and is used sparingly rather than a policy with no give at all, because a policy that cannot bend gets broken.
The organisations that got there did it over eighteen months in small increments, each of which was individually unremarkable. The ones that tried to do it in a quarter are usually still running the VPN they intended to retire.
