Skip to content

Zero Trust Network Architecture

Every mechanism this module has covered so far — TLS, firewall rules, segmentation — shares one assumption underneath it: once a connection is authenticated and let through the perimeter, the network on the other side of that perimeter is trusted. The segmentation example put a public zone, an application zone, and a data zone behind successively stricter firewall rules, but a device that's already inside the application zone was still trusted by everything else in that same zone, by virtue of being there. Zero Trust starts from a different premise: location on the network proves nothing, and every single request has to prove itself, regardless of which zone, VLAN, or VPN tunnel it arrived through.

The perimeter model, and where it stopped holding

For decades, enterprise network security was built around one idea: build a hard perimeter — a firewall at the internet edge, a VPN for remote access — and trust everything inside it. Security engineers describe this as a castle-and-moat model: heavily defended at the boundary, largely open once past it. Internal traffic between two servers on the same LAN often had no authentication at all beyond "which subnet did this packet come from" — the network itself was the credential.

That model held up reasonably well when "the network" meant a company's own building, with company-owned devices on company-owned switches. It stopped holding up as remote work and multi-cloud deployments dissolved the idea of a single perimeter to defend, and as lateral movement became the standard shape of a serious breach. An attacker who compromises one lightly defended internal host — a forgotten test server, a phished employee laptop — and finds that host trusted by everything else on the same network can move sideways from system to system, with the perimeter's own defenses never triggered again after the first breach, because nothing on the inside was checking.

Zero Trust is the industry's response to that specific failure mode, formalized by NIST in Special Publication 800-207, published in August 2020. Google's own internal security architecture, published under the name BeyondCorp, is the best-documented real-world example of this thinking implemented at scale, predating the NIST publication and heavily informing it.

Never trust, always verify — the network a request came from is not a credential.

What "verify every request" actually means in practice

Saying "trust nothing" is a slogan, not an architecture. NIST SP 800-207 grounds it in a specific shift: protect individual resources — services, accounts, workflows — rather than network segments, and treat authentication and authorization as discrete checks performed before every session to a resource, not a status a device earns once and keeps. That translates into concrete, checkable behavior:

  • Every access request is evaluated individually, not once per session or once per network connection. A device that authenticated successfully five minutes ago doesn't get an implicit pass for its next request; each one is checked again against current policy.
  • Access decisions use more than just identity. A policy engine considers who's asking (the authenticated user or service), what they're asking to reach, and contextual signals — the device's patch level, whether it's a managed corporate laptop or an unknown personal device, the request's geographic origin.
  • Every resource requires authentication and authorization on its own terms, regardless of network location. A server sitting on the "trusted" internal LAN gets exactly the same scrutiny as one reachable from the public internet — there is no longer a network segment where access is granted by default.

This is a genuinely different mental model from the segmentation article's zones, not just a stricter version of the same idea. Segmentation still trusts the zone — anything inside the application zone can, by default, reach anything else inside the application zone. Zero Trust trusts nothing by default, zone or no zone, and re-establishes trust per request based on identity and context rather than location.

Micro-segmentation: shrinking the blast radius to one host

The architectural piece that makes per-request verification enforceable at scale is micro-segmentation — pushing access control down from the network-zone level to the level of a single service or even a single host. Where the earlier segmentation model drew three broad zones and controlled what could cross between them, micro-segmentation asks a much narrower question for every single connection: does this specific source have an explicit, current policy allowing it to reach this specific destination, on this specific port?

Traditional segmentation:          Micro-segmentation:

[ Application zone ]               [ Service A ] -X-> [ Service B ]  (no policy = denied)
   app-1 <-> app-2 <-> app-3          |
   (all trusted by zone)              +--policy allows--> [ Service C ]

Practically, this is usually implemented with a service mesh or an identity-aware proxy sitting in front of every service, issuing short-lived cryptographic identities to workloads themselves — not just to human users — so that "app-1 talking to app-3" is a request the mesh can authenticate and authorize exactly like a login, rather than something implicitly allowed because both happen to run in the same subnet. That's a genuinely different piece of infrastructure from a firewall rule: a sidecar proxy deployed alongside every service instance, handling authentication and encryption for that service's traffic without the service's own code needing to know the mesh exists at all.

BeyondCorp: replacing the VPN's implicit trust

The clearest real-world illustration of Zero Trust replacing perimeter thinking is what Google's own BeyondCorp work changed about remote access, described in Rory Ward and Betsy Beyer's 2014 paper on the subject. A traditional corporate VPN grants a specific, damaging kind of implicit trust: once a device authenticates to the VPN and gets a tunnel address on the corporate network, it's treated as "inside," and everything reachable from inside is fair game to attempt, VPN authentication having already happened. That single authentication step effectively vouches for every subsequent connection during that session — precisely the property VPN basics already flagged as a real limitation: a VPN authenticates the device or user, not the intent of every packet it carries afterward, and it does nothing to stop a device that's already compromised from reaching everything the tunnel grants access to.

BeyondCorp's core architectural change was removing the "privileged intranet" entirely: instead of a VPN tunnel granting broad network-level access once connected, every application request — whether the employee is in the office, at home, or on public Wi-Fi — passes through an access proxy that checks the user's identity, the requesting device's current trust level, and the specific resource being requested, every time. There's no privileged "inside the corporate network" state a device can reach and then coast on. A device on the office LAN and a device on a coffee shop's Wi-Fi are evaluated by the identical policy, because the network they're connecting from was never part of the trust decision to begin with.

What Zero Trust doesn't remove, and what it costs

Zero Trust doesn't eliminate the need for encryption, firewalls, or the PKI-based identity this module already covered — it composes with all of it. TLS still encrypts the connection; certificates still prove identity at the transport layer; a policy engine still needs a network path to actually enforce a decision on. What changes is which factor is allowed to grant access on its own: network location stops being sufficient by itself, and identity plus context becomes the thing that's actually checked, every time.

The real cost is operational, and it's worth naming plainly rather than glossing over: continuous per-request verification means more moving infrastructure — an identity provider every service trusts, a policy engine every request consults, short-lived credentials that have to be issued and rotated automatically rather than a device just being "on the network." A misconfigured policy engine, or an identity provider having a bad day, can turn into an outage that a purely network-based ACL never could, precisely because so much more now depends on that decision being made correctly and quickly for every single request. Zero Trust is a real security improvement for an organization with genuinely distributed users and services, and a considerable engineering investment to run well — not a checkbox a small, simple network gets for free by adopting the name.

Practice exercises

  1. A company currently uses a traditional VPN: employees connect, get a 10.8.0.0/24 tunnel address, and from there can reach any internal service the corporate firewall allows for that whole subnet. Using the BeyondCorp description above, explain specifically what changes about how access is granted if this company moves to a Zero Trust model — not just what new infrastructure gets added.
  2. Explain, in terms of blast radius, why an attacker who compromises one host inside a micro-segmented environment is in a meaningfully different position than one who compromises a host inside a traditionally segmented "application zone" like the one in the firewall article.
  3. A colleague argues, "we already have a firewall and a VPN, so we don't need Zero Trust." Identify the specific failure mode — already named earlier in this article — that a firewall-plus-VPN architecture doesn't defend against, and that Zero Trust specifically targets.

Zero Trust decides whether a given request is allowed to reach a given resource at all. It says nothing about what happens once that decision is "yes" and the resource starts receiving far more traffic than it can safely absorb — accidentally, from a legitimate spike, or deliberately, from an attacker who passed every identity check and is now just sending requests as fast as possible. That's a different problem, and it's next.

Sources