TL;DR
Zero Trust Networking (ZTNA) is what you get when you stop treating the network as the trust boundary and start treating every packet as a policy decision against the identity plane from Part 5. It’s an identity-aware L7 proxy with L3/L4 enforcement, co-designed with DNS, and under the hood it very often sits on the WireGuard substrate from Part 4. This is Part 6 of seven; the vendor market is smaller than the noise suggests, and the mental model is simpler than the marketing.
This post is a written-down version of the Zero Trust Networking talk I gave inside Tikal and in private client workshops — the one with the Hebrew “highway versus traffic cop” metaphor. The walkthrough, the Cloudflare Access model, and the cost table are all from that deck; this is the public companion.
The highway and the traffic cop
Imagine driving onto a busy highway with a single gatehouse at the entrance. That’s a VPN. Once you pass the gate — once you type the password — nobody asks who you are again. You drive anywhere. You end up in places you had no business visiting.
Now imagine a road where at every interchange, every traffic light, every turn, an officer stops you and asks: who are you, where are you going, are you still allowed to go there? That’s Zero Trust. Instead of a single identity check at the entrance, the system re-evaluates at every step: who are you, where are you connecting from, are you on the right device, do you still satisfy the policy right now?
The whole post is a technical expansion of that one metaphor, which I’ve told in Hebrew to rooms full of platform engineers and watched land harder than any architecture slide. It’s the clearest difference between VPN and ZTNA you’ll hear.
Three principles that actually define it
Strip away the vendor pitches and Zero Trust reduces to three commitments.
Explicit verification on every request. Not “did you log in at 9am” but “are you still allowed to do this specific thing, from this device, at this moment.” Identity, device posture, location, time of day, and data sensitivity all feed the decision.
Least privilege, scoped to the task. You get access to one application, or one API, or one namespace — not to a network. The word network gradually disappears from user-facing access policies. It becomes an implementation detail of the enforcement plane.
Assume breach. Design every boundary so a compromise of one account or one workstation doesn’t cascade. Lateral movement is the actual attack you’re defending against; a VPN that gives a stolen laptop the entire internal /16 is the attack surface.
Google’s BeyondCorp memo, written after the 2009 Operation Aurora breach, is where this model was publicly articulated. Almost two decades later, the market has caught up; the ideas haven’t really changed.
The four-part mental model: Application, Policy, Tunnel, Route
The cleanest decomposition I’ve used — and the one the Cloudflare deck is organized around — has four pieces:
- Application — the actual destination. A SaaS URL, an internal service, a database, a Kubernetes API endpoint. This is what the user is trying to reach.
- Policy — the rules that decide whether this request is allowed right now. Identity claims from Part 5, device posture from an EDR agent, geography, time of day, session age. The security guard checking the guest list.
- Tunnel — the encrypted conduit from the user or edge to the policy plane. Often WireGuard under the hood (Part 4). The private highway to the policy plane, not the destination.
- Route — how the policy plane, once it says yes, directs the traffic to the right backend. DNS name, IP, path prefix, or service. The Waze of the system.
Miss any one of the four and you don’t have ZTNA — you have a VPN with MFA bolted on, or an identity-aware proxy with no enforcement, or a tunnel with nothing to protect. All four need to be wired together.
DNS, promoted to policy plane
Across this series DNS has grown from plumbing into enforcement. Zero Trust is where the promotion finalizes. Three concrete threads:
DNS filtering is the cheap front door of ZT. Cloudflare Gateway, NextDNS, and Cisco Umbrella block by hostname before a connection is ever attempted. Your laptop resolves known-bad.example.com, the resolver returns NXDOMAIN or a sinkhole, and no packet ever leaves the device. This is the highest-leverage control in the stack and the easiest one to deploy.
DoH/DoT encrypts the queries that used to leak. In Part 3 the classic “DNS leak” was the failure mode — your VPN “protected” your traffic while your laptop resolved names through your ISP. Modern clients speak DNS-over-HTTPS and DNS-over-TLS by default, which closes that leak but also means corporate DNS-based visibility now requires a ZT gateway that terminates DoH and re-applies policy. You get privacy and a new centralization point.
Cloudflare Tunnel’s DNS model. Your internal service’s public DNS record points at the Cloudflare edge; the edge routes the request through the tunnel to your origin. There is no public IP on your backend. The DNS record is the only thing internet-facing, and policy evaluates before routing. This is the Route piece of the four-part model made literal.
The vendor landscape is small
Despite the noise, the ZTNA market has roughly ten real players — every buyer I’ve worked with ends up evaluating some subset of this list: Cloudflare, Zscaler, Palo Alto (Prisma Access), Netskope, Cato Networks, Cisco/Duo, Twingate, Tailscale, Check Point (Perimeter 81), Google BeyondCorp Enterprise. The moat is three-dimensional: global PoP footprint, identity federation depth, and compliance certification breadth. You can’t clone that from a GitHub repo.
Underneath a meaningful fraction of that list — Cloudflare WARP, Tailscale, Twingate, and more — WireGuard is the substrate. Part 4 foreshadowed this explicitly: simpler crypto at the bottom enabled a richer policy layer on top.
The cost conversation (as it actually happens)
A short version of the table I use in procurement conversations:
For most buyers under ~200 seats, the per-user SaaS math beats appliance ops. Above that, it depends on how much policy customization and compliance evidence you need. The appliance-ops tax — engineers on call for the VPN concentrator — is the line item most procurement spreadsheets miss.
An anchor from the field
The pattern came cleanest at an AI-powered endpoint and cloud protection vendor where the EDR product and the internal ZTNA stack were converging. Engineers’ own access decisions were gated on live device-posture signals from the same agent the company sold to customers — a kernel-resident EDR feeding a continuous authorization decision. Revoking a session took seconds. The trust anchor was the device and the identity, evaluated every request. In an industry that ships endpoint protection, nothing disqualifies a vendor faster than having their own employees on a flat VPN.
Hands-on: a ZT-style proxy in front of a k3d service
The full lab — a self-hosted path using oauth2-proxy as an identity-aware proxy in front of a k3d service, with policy driven by OIDC claims and a “denied from unauthorized identity” scenario, plus a lateral-movement denial demo where a neighbor pod can reach the network IP but not the application — lives at [github.com/hagzag/the-road-2-zerotrust/tree/main/practice/part6](https://github.com/hagzag/the-road-2-zerotrust/tree/main/practice/part6).
# From practice/part6/
./run.sh # create cluster, deploy Keycloak, proxy, app
./bootstrap-realm.sh # seed realm + two users (allowed, denied)
# Open http://localhost:8080 — one user gets in, the other is denied at policy.
./lateral-move.sh # deploy a rogue pod and watch it failThe aha moment is the lateral-move.sh output: a pod sitting on the same cluster network as the app still can’t reach it, because the enforcement happens at identity, not at IP.
Where this leaves you
Zero Trust Networking is the technology answer. It’s not the end of the story — regulated environments, hyperscaler-native offerings, the operational reality of FIPS and SOC 2, and the personal side of what this shift means for working practitioners are all still ahead. That’s Part 7, the finale: Compliance, Cloud, and Consulting from Anywhere.
Discussion