An organisation decides to adopt zero trust. What does it actually mean architecturally, what is the realistic implementation order, and where does it fail?

What it actually means

Zero trust replaces location-based trust — "you are on the corporate network, therefore you are trusted" — with identity- and context-based trust, evaluated per request.

The practical statement: every request is authenticated and authorised on its own merits, regardless of where it originated, and the network provides no implicit permission.

The problem it solves is specific and real: a perimeter model gives an attacker who breaches the perimeter lateral movement across everything inside it. Most significant breaches follow that shape — initial access, then unimpeded movement — and the perimeter's failure is total rather than partial.

The architectural components

• Strong identity for users, with phishing-resistant multi-factor authentication. Not all MFA is equal; push notifications and one-time codes are phishable and hardware-backed methods are not, which is the distinction that matters in real incidents.
• Identity for workloads, which is the harder and more neglected half. Services need cryptographic identities — mTLS certificates or signed tokens — issued automatically and rotated frequently, so that service-to-service calls are authenticated rather than assumed.
• Device posture as an input: is the device managed, patched, encrypted?
• Per-request authorisation against a policy engine, considering identity, device, resource sensitivity and context.
• Micro-segmentation, so network reachability is restricted even though it is no longer the trust boundary — defence in depth, not a replacement.
• Comprehensive logging, because per-request decisions are only useful if they are auditable.

The realistic order

1. Strong user identity and phishing-resistant MFA everywhere, including administrative and service accounts. The largest risk reduction per unit of effort by a wide margin.
2. Eliminate long-lived credentials. Short-lived, automatically-rotated tokens; workload identity federation instead of static keys; no cloud access keys in configuration files. Standing credentials are what turn a small compromise into a large one.
3. Least privilege on identities, reviewed and pruned — the permissions accumulated over years are the blast radius.
4. Workload identity and mTLS between services, usually delivered by a mesh or a shared library.
5. Policy-based authorisation at the application layer.
6. Micro-segmentation, last, because it is the most disruptive and the least valuable of the set.

Where it fails

• Treating it as a product purchase. Vendors sell components; zero trust is an architectural property, and buying a proxy while leaving standing credentials everywhere achieves little.
• The legacy estate. Systems that cannot do modern authentication end up behind an exception, and the exceptions become the attack path — the security posture is set by the weakest exempted system.
• Ignoring workload identity. Many implementations secure human access thoroughly and leave service-to-service calls unauthenticated inside the cluster, which is the perimeter model at a smaller scale.
• Policy sprawl, where authorisation rules are so numerous and interdependent that nobody can determine a given identity's effective access — an unanalysable policy is an unenforced one.
• Usability failure. Controls that obstruct legitimate work are circumvented, and the circumvention is invisible. Security that is harder than the workaround selects for the workaround.
• Availability coupling, since a policy engine on the request path of everything is a new single point of failure that must fail in a defined direction — and "fail open" and "fail closed" are both wrong answers in different situations, which requires a per-resource decision rather than a global one.