"Zero trust" is the most oversold phrase in security, plastered across vendor pages promising it in a box. The idea underneath, though, is sound and concrete — and you cannot buy it, because it is an architecture and a set of habits, not an appliance. The old model assumed a hard perimeter: a firewall around the corporate network, inside which everything was trusted. Remote work, cloud workloads, SaaS, and personal devices dissolved that perimeter years ago. Zero trust is the design that replaces it.
the one principle: never trust, always verify
Every request — from a user or a service, inside or outside your network — must be authenticated, authorised, and encrypted before it is granted, and that decision is made fresh each time rather than inherited from "being on the network." Network location stops being a credential. A request from inside the data centre gets exactly as much scrutiny as one from a coffee-shop Wi-Fi. Everything else in zero trust is mechanism in service of that one rule.
identity is the new control plane
If location no longer confers trust, something else must, and that something is verified identity — for both people and machines.
For users, this means strong, ideally phishing-resistant authentication. Passwords and SMS codes are routinely defeated by phishing and SIM-swapping; FIDO2 security keys and passkeys are not, because the credential is cryptographically bound to the site and never leaves the device. Multi-factor authentication is the floor, not the ceiling.
For services, identity is just as important and more often neglected. In a microservices system, each workload needs its own verifiable identity rather than a shared API key copied into a dozen config files. Frameworks like SPIFFE issue every workload a short-lived, cryptographically verifiable identity document, so services prove who they are to each other automatically. The guiding shift is from long-lived static secrets to short-lived, automatically rotated credentials — a leaked token that expires in five minutes is a far smaller problem than one that works forever.
least privilege, expressed as policy-as-code
Verifying identity answers "who are you." Authorisation answers "what may you do," and zero trust answers it with least privilege: grant the minimum access needed for the task, and revoke it when the task is done. At scale, you do not want that logic scattered through application code. The modern approach is policy-as-code — externalising authorisation rules into a dedicated engine such as Open Policy Agent (OPA), where they are versioned, tested, and audited like any other code. Decisions can then weigh context: not just who is asking, but the device's security posture, the time, the location, and the sensitivity of the resource. Access becomes a continuous, contextual evaluation rather than a one-time gate at login.
micro-segmentation and mutual TLS
The perimeter model's worst failure was lateral movement: breach one machine, and the soft interior let an attacker roam freely. Zero trust contains this with micro-segmentation — policy applied down to the individual workload, so a service can talk only to the specific services it legitimately needs. In practice this is often delivered by a service mesh enforcing mutual TLS, where both ends of every service-to-service call present and verify certificates. Traffic is encrypted in transit and, just as importantly, authenticated: a compromised service finds itself in a tiny, sealed segment with no path to the crown jewels.
a realistic migration path
Zero trust is a journey precisely because you cannot flip a switch on a running organisation. A sequence that works in practice:
- Inventory. You cannot protect what you have not mapped. Catalogue users, devices, services, data stores, and the flows between them.
- Fix identity first. Roll out strong MFA and a single identity provider before anything else — it is the highest-leverage step and the foundation everything else stands on.
- Encrypt and authenticate service traffic. Introduce mTLS between services, starting with the most sensitive paths.
- Segment incrementally. Tighten network policy one workload at a time, beginning in report/monitor mode so you learn real traffic before you start denying it.
- Monitor continuously. Feed identity, device, and network telemetry into analytics that baseline normal behaviour and flag anomalies — verification does not stop at login.
Google's BeyondCorp is the canonical real-world example: they spent years moving their entire workforce off the VPN-and-perimeter model to per-request, identity-and-device-based access. The lesson is that it is incremental and continuous, not a quarter-long project.
the pitfalls
Three traps sink zero-trust efforts. The first is believing it is a purchase — a product can implement a piece, but no vendor delivers the architecture for you. The second is making identity a single point of failure: when identity becomes the control plane, your identity provider becomes the most attractive target in your estate, so it needs the strongest protection and a tested recovery plan. The third is ignoring the human and operational cost — overly aggressive policies that block legitimate work train people to invent risky workarounds, and continuous verification adds latency and operational overhead you must design for. Roll out in monitor mode, measure, and tighten gradually.
the takeaway
Strip away the marketing and zero trust is a disciplined answer to a world without a perimeter: verify every request on the strength of identity and context, grant the least access necessary, encrypt and authenticate everything, and assume any component can be compromised so you contain the blast radius in advance. It is defence in depth applied consistently — and it complements, rather than replaces, the other layers, from hardened browser policies like a Content Security Policy to encrypted data at rest. Approached as an evolving practice rather than a finish line, it produces a security posture genuinely fit for how software is built and used today.