Zero Trust is a good idea with terrible marketing around it.
Worse than terrible, really. It’s one of those phrases the security industry found, polished, expanded, franchised, and then slapped onto so many unrelated products that the term now arrives in meetings already exhausted. Firewalls became Zero Trust firewalls. VPN replacements became Zero Trust. Endpoint products became Zero Trust. Browsers became Zero Trust. At some point I fully expected somebody to sell me Zero Trust office chairs.
The annoying part is that the underlying idea is solid.
What It Originally Meant
John Kindervag’s Forrester framing around 2010 was simple: never trust, always verify. More precisely, stop granting broad implicit trust just because something is on the “inside” of the network. Network location is not moral virtue. Every access request should be authenticated, authorized, and evaluated in context.
That was and is a useful correction. Traditional network security drew a perimeter — firewall at the edge, everything inside is trusted. VPN connects you to the “inside,” and once you’re in, you can reach everything. This model assumed the perimeter was unbreachable and internal actors were trustworthy. Both assumptions failed repeatedly.
Zero Trust says: there is no inside. Every request is untrusted until proven otherwise. Identity is the perimeter, not the network.
NIST formalized this in SP 800-207. It defines Zero Trust Architecture through a set of principles: verify explicitly, use least-privilege access, assume breach. It’s a set of architectural tenets, not a product specification. The document is clear about this.
What the Vendors Did
Somewhere around 2020, “Zero Trust” crossed from architecture whitepaper into marketing goldmine. The term showed up in every enterprise pitch deck.
“Our SASE platform enables Zero Trust!” means we replaced your VPN with our VPN.
“Zero Trust endpoint protection!” means we run an agent on the laptop.
“Zero Trust email gateway!” means we filter email.
These products may be useful. Some of them may even implement one or two ZT principles. But calling a firewall “Zero Trust” because it checks user identity before allowing traffic is like calling a door “Zero Trust” because it has a lock. The lock is a component. It’s not the architecture.
The damage: when everything is Zero Trust, the term means nothing. A CISO evaluating three vendors who all claim Zero Trust has no signal. The label conveys no information about what the product actually does or which ZT principle it addresses.
What Zero Trust Actually Requires
Real Zero Trust architecture is years of work, not a product purchase. NIST SP 800-207 is explicit about the components:
Identity as the perimeter. Every access decision is based on who is requesting, from what device, in what context. Not which network they’re on. This requires a mature identity provider, strong authentication (ideally phishing-resistant), and device posture assessment.
Least-privilege access everywhere. Users get access to exactly what they need and nothing more. Not “access to the production network.” Access to specific applications, specific resources, scoped by role and context. This requires rebuilding access controls from the ground up in most organizations.
Micro-segmentation. Internal networks are divided into small, isolated segments. A compromised workstation can’t reach the database server because the segment boundary prevents it. This requires deep network redesign — not a product you install, but an architecture you build.
Continuous verification. Authentication doesn’t happen once at login. The system continuously evaluates whether access should continue — checking device health, behavioral patterns, location anomalies. This requires real-time telemetry and policy engines that most organizations don’t have.
Each of these is a multi-quarter project involving architecture changes, process changes, and organizational buy-in. It’s not a product. It’s not even a project. It’s a transformation.
The Vendor Question
If someone is selling you “Zero Trust,” ask one specific question: which NIST SP 800-207 tenet does this product address?
If the answer is vague — “it provides Zero Trust security” — the product is borrowing a label without earning it. If the answer is specific — “it provides continuous device posture assessment that feeds into access policy decisions” — that’s a component of a ZT architecture, and it might be worth evaluating.
The difference between “this is a Zero Trust product” and “this contributes to a Zero Trust architecture” is the difference between marketing and engineering.
The Irony
The organizations that have actually implemented something close to Zero Trust architecture — usually large tech companies with dedicated platform security teams — rarely call it “Zero Trust.” They call it “identity-based access” or “BeyondCorp” or just “how we do access control.” The label is most aggressively used by the organizations furthest from implementing it.
Don’t Dismiss the Principles
I’m not saying Zero Trust is meaningless. The principles — verify explicitly, least privilege, assume breach — are the right way to think about security architecture. They were right in 2010 and they’re right now.
What’s meaningless is the marketing. The label has been so thoroughly diluted that hearing “Zero Trust” in a sales pitch tells you nothing. The term has become a Rorschach test: people see whatever they want to see in it.
If your organization is serious about Zero Trust, ignore the label entirely. Read NIST SP 800-207. Look at which tenets you actually implement today. Identify the gaps. Build a roadmap. It will take years and it won’t involve buying a single product that has “Zero Trust” in its name.
The architecture is sound. The marketing destroyed the signal.