"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.
device posture: the second credential
A verified user on a compromised laptop is still a compromised session, which is why mature zero-trust deployments treat the device as a first-class part of every access decision. Before granting access, the policy engine asks questions about the machine itself: is disk encryption on, is the OS patched within policy, is the endpoint agent running, is this a managed corporate device or an unknown personal one? The answers come from an MDM or endpoint agent and are evaluated alongside identity.
The practical power is in graduated responses rather than binary allow/deny. A fully compliant managed laptop gets everything its owner is entitled to; a personal tablet with a passkey might get web email but not the production console; a device that has missed two patch cycles gets a warning period, then progressively reduced access until it is remediated. This turns patching from a nagging email into an incentive structure — and it means a stolen password is not enough, because the attacker would also need a device that passes posture checks.
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.
what continuous verification looks like day to day
"Never trust, always verify" does not end when the session token is issued. The signals that mattered at login — device health, location, behaviour — keep changing while the session is alive, so the architecture needs a way to act on them. Concretely, that means short-lived tokens that force regular re-evaluation rather than eight-hour bearer tokens; support for session revocation so that disabling a user or quarantining a device actually terminates live access within minutes; and step-up authentication, where an already-signed-in user is re-challenged with a passkey before a sensitive action like changing payout details or exporting customer data.
On the detection side, the identity provider's logs become your richest security dataset: impossible-travel logins, a service account suddenly enumerating resources it never touched before, an MFA-fatigue pattern of repeated push prompts. Baseline what normal looks like per identity, alert on deviation, and rehearse the response path — the value of detecting a hijacked session is only as good as your ability to kill it quickly.
zero trust when you're a ten-person company
The BeyondCorp story can make zero trust sound like an enterprise-only programme, but small teams can capture most of the value with a weekend of configuration rather than a multi-year project. Put every application behind a single identity provider with SSO, enforce passkeys or hardware keys for it, and turn on the basic device checks most IdPs now offer out of the box. Replace the legacy VPN with an identity-aware proxy for anything internal. In the cloud, lean on what you already pay for: scoped IAM roles per service instead of a shared admin key, short-lived credentials from a metadata service instead of secrets in config files, and security groups that default-deny between workloads.
A small company that does only this — one identity provider, phishing-resistant MFA, no shared long-lived secrets, default-deny between services — is more genuinely "zero trust" than a large one with a shelf of appliances and a flat internal network. The principles scale down gracefully; it is the tooling theatre that does not.
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.