"Zero Trust" is one of those phrases that carries the weight of being right while obscuring what it actually means. Roughly half the security products on the market in 2026 advertise themselves as Zero Trust solutions; only a fraction of those products implement anything that resembles the original concept. Stripping away the marketing leaves a small but powerful idea, and a clear test for whether you actually have it.
The original idea
The phrase was coined by Forrester analyst John Kindervag in 2010, but the formal model most commonly referenced today is the US National Institute of Standards and Technology’s Special Publication 800-207, finalised in August 2020 and available at nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-207.pdf. The core argument is simple: the perimeter does not exist. Inside-the-network and outside-the-network are no longer meaningful distinctions, which means trust must be earned per-request rather than inherited from network position.
In practice that translates into seven NIST principles. Every resource is treated as a network of one. Every access request is authenticated and authorised explicitly. Trust is granted dynamically based on identity, device posture, and behaviour. Communication is encrypted regardless of network location. Access is granted on a per-session basis with the smallest possible scope. The architecture continuously monitors and adjusts. And, critically, there is no implicit trust based on IP address, network segment, or VPN tunnel.
What that actually buys you
The defensive value of Zero Trust is most clear in the failure modes of perimeter security:
The remote-access VPN is the perimeter’s worst extension. Once a user is authenticated, the entire internal network is reachable. Compromise that VPN account and the attacker has lateral-movement runway across your environment. A 2024 CISA advisory documented dozens of cases where this exact pattern produced ransomware incidents.
Internal east-west traffic is unmonitored in most enterprises. Microsegmentation, a Zero Trust principle, means that the file server only accepts connections from the specific identities and applications that need it, not from any host on the LAN.
Cloud and SaaS workloads do not fit perimeter models. They are accessed from anywhere, and they connect to other clouds. Identity becomes the only meaningful boundary.
What an actual Zero Trust deployment looks like
Strip away the marketing and a real Zero Trust environment has four components:
Identity provider with strong authentication. Almost always Entra ID, Okta, Ping, or Google Workspace, with phishing-resistant MFA (passkeys, FIDO2 hardware keys) on every account.
Device posture engine. Telemetry from your EDR feeds into the access decision: this laptop is patched, AV is running, disk is encrypted, no unauthorised admin tools are present. Failed posture means failed access.
Policy enforcement point. Every application sits behind a gateway that authenticates and authorises every request, typically a Zero Trust Network Access (ZTNA) product like Cloudflare Access, Zscaler Private Access, Tailscale, Cisco Secure Access, or open-source variants like Pomerium and Boundary.
Continuous monitoring and adaptive policy. Behaviour anomalies, geographic impossibilities, sudden privilege escalations, unusual SaaS access patterns, trigger reauthentication or session termination.
Notice what is not on this list: a "Zero Trust appliance," a single product, or a network segment relabelled "Zero Trust zone." Zero Trust is an architecture, not a product. Anyone selling you the latter has missed the point.
The realistic adoption path
Most organisations cannot rip out their existing infrastructure. The pragmatic adoption sequence, derived from CISA’s Zero Trust Maturity Model 2.0 (cisa.gov/zero-trust-maturity-model), looks like this:
Year one: get phishing-resistant MFA on every external-facing service. Roll out an identity provider for SSO. Inventory privileged accounts and reduce them.
Year two: deploy ZTNA for at least one critical application class, typically internal admin tools, then development infrastructure. Replace VPN access for those workloads. Wire EDR posture into access decisions.
Year three: extend ZTNA to general application access. Microsegment the data centre using identity-aware proxies or modern firewall fabric. Enforce explicit policy on east-west traffic.
This is multi-year work measured in capital expenditure and political capital. It is not optional, and it is not a product purchase.
How to spot fake Zero Trust
Three tests cut through the marketing.
Does the architecture remove or reduce the need for VPN? If the vendor is selling a Zero Trust product that lives downstream of a VPN, it is not Zero Trust; it is conditional access.
Is access decided per-request, not per-session? A model that authenticates once at login and then trusts you for eight hours is not Zero Trust regardless of how many factors are used at the front door.
Is policy aware of identity and device posture together? A pure network ACL, even a microsegmented one, is not Zero Trust because it does not know who is on the wire.
If a vendor cannot articulate clear answers to those three questions about their product, the product is not Zero Trust. It might still be useful, modern conditional access and segmentation products are good, but the label is wrong.
The hard part is organisational
The technology is solvable. The hard part of Zero Trust is the organisational change: applications that depend on flat-network assumptions, vendor integrations that hardcode IP allowlists, the executive who refuses to use a hardware key, the legacy authentication protocols that cannot be deprecated because of one critical workload nobody wants to touch.
Zero Trust succeeds, when it succeeds, because someone in the organisation owns the architectural transformation and is empowered to push through the friction. It fails, when it fails, not because the technology was wrong but because the politics were not. Plan for both.
