The phrase "Zero Trust" gets thrown around in vendor marketing until it means almost nothing — a label slapped on firewalls, VPNs, and identity products alike. But underneath the noise is a genuine and well-specified shift in how security architecture is supposed to work. It is worth separating the model from the merchandise.
The term was popularized by Forrester analyst John Kindervag around 2010, building on earlier work like the Jericho Forum's "de-perimeterisation" discussions in the mid-2000s. The clearest reference definition today is the U.S. National Institute of Standards and Technology's Special Publication 800-207, published in August 2020, which lays out the architecture in vendor-neutral terms.
The Problem With the Castle
Traditional network security is sometimes called "castle-and-moat." You build a strong perimeter — firewalls, a VPN gateway, intrusion detection at the edge — and everything inside that perimeter is treated as trusted. A laptop that connects to the corporate VPN is, for most purposes, granted broad access to internal systems.
This model fails the moment an attacker gets inside. And attackers get inside constantly: a phished credential, a compromised contractor laptop, an unpatched edge device. Once past the moat, lateral movement is easy because internal systems trust each other by virtue of being on the same network. The 2013 Target breach and countless ransomware incidents follow this exact shape — initial foothold, then unrestricted movement across a flat, trusting internal network.
Three changes made the castle obsolete. Cloud computing moved workloads outside the perimeter entirely. Remote work moved users outside it. And SaaS moved data outside it. When your apps, your data, and your people are all outside the moat, the moat protects an empty courtyard.
The Core Tenets
NIST SP 800-207 frames Zero Trust around a set of principles rather than a product. The load-bearing ideas:
- No implicit trust from network location. Being on the corporate LAN or VPN confers nothing. An internal request is treated with the same suspicion as one from a coffee-shop Wi-Fi.
- Per-request authorization. Access is evaluated for each resource request, not granted as a broad session and forgotten.
- Least privilege. A subject gets access to the specific resource it needs, for as long as it needs it — nothing more.
- Dynamic, signal-driven decisions. The decision to grant access considers device health, user identity, behavior, and other observable signals — not a static rule set.
- Assume breach. Design as though an attacker is already inside, because in practice they often are.
Zero Trust replaces "trusted because you're inside the network" with "trusted because you proved it on this request, for this resource, right now." Trust is never inherited from where a packet came from.
How It Actually Works: PDP and PEP
The architectural heart of Zero Trust is a split between deciding and enforcing. NIST describes a Policy Decision Point (PDP) — the brain that evaluates whether a given subject should access a given resource — and a Policy Enforcement Point (PEP) — the gate that sits in front of the resource and does what the PDP says.
When a user tries to reach an internal application, the request hits the PEP. The PEP asks the PDP: should this be allowed? The PDP weighs identity (is this really the user, proven with strong authentication like passkeys or a hardware key), device posture (is the laptop patched, encrypted, managed?), and contextual signals (unusual location, impossible travel, time of day). Only if the policy is satisfied does the PEP open the connection — and often only to that one application, not the whole network.
Google's BeyondCorp, documented in a series of papers starting in 2014, is the best-known real-world implementation. Google removed the privileged corporate network entirely: employees access internal apps through an access proxy that authenticates the user and inspects the device on every request, whether they're in the office or at home. There is no VPN to "get inside" because there is no inside.
Microsegmentation and the Blast Radius
A related practice is microsegmentation — dividing the network into small zones so that compromising one workload doesn't grant access to its neighbors. Instead of a flat network where the web server can freely reach the database, the payroll system, and every workstation, each connection is individually permitted or denied.
The goal is to shrink the blast radius. If an attacker compromises one segment, microsegmentation contains them there rather than letting them pivot freely. This is the practical answer to the lateral-movement problem that sinks castle-and-moat designs.
| Dimension | Castle-and-Moat | Zero Trust |
|---|---|---|
| Trust basis | Network location | Verified identity + device + context |
| Granted when | Once, at connection | Per request, continuously |
| Lateral movement | Easy after breach | Contained by segmentation |
| Default posture | Allow inside the perimeter | Deny until proven |
What Zero Trust Is Not
Because the term sells, it gets attached to things that aren't it. A VPN is not Zero Trust — it is the perimeter model in disguise, granting network-level access after one authentication. Buying a single "Zero Trust" product does not make an organization Zero Trust; it is an architecture and an operating discipline, not a SKU.
It also is not a synonym for "secure." Zero Trust is about access control — who can reach what. It does nothing to fix a vulnerable application, a weak encryption scheme, or a misconfigured database that's exposed to anyone with valid access. And it introduces its own risks: the PDP becomes a high-value single point of failure, and aggressive logging of every access decision creates a detailed surveillance record of user behavior that itself needs protecting.
Migrating to a true Zero Trust architecture is an incremental, multi-year effort for most organizations. The U.S. federal government formalized its own push in Executive Order 14028 (2021) and OMB memo M-22-09 (2022), with multi-year deadlines — a useful signal that even with a mandate, this is not a weekend project.
Why It Matters Beyond the Enterprise
The deeper lesson of Zero Trust generalizes well past corporate IT: don't grant trust based on where something is — grant it based on what you can verify about it. That principle shows up everywhere in good security design.
End-to-end encryption is Zero Trust applied to data: the server that relays your message is "inside the network," but it is granted zero ability to read what passes through it, because trust is never extended to infrastructure merely for being in the path. This is the same instinct that drives end-to-end encryption and certificate pinning — verify the thing itself, never trust the channel.
At Haven, we apply that thinking to our own infrastructure. Our backend never has access to the keys that protect your messages and email, so even a full compromise of our servers — an attacker fully "inside" — yields ciphertext, not content. The server is in the path; it is trusted with nothing. That's Zero Trust as a data principle, not just a network one.
Zero Trust is not a finished destination or a product you can buy your way into. It's a continuous posture: verify identity, check the device, evaluate the context, grant the minimum, and assume the adversary is already inside. The organizations that get the most out of it treat it as a discipline rather than a deliverable.