Zero Trust Architecture

Definition: An enterprise security framework built on the principle “never trust, always verify,” which removes implicit trust based on network location and instead authenticates and authorizes every request individually.

How It Works

No implicit trust from network location: being inside the corporate network, on the office Wi-Fi, or behind the VPN grants zero automatic permissions. Every request is treated as if it originated from an open, untrusted network, because in practice it might have.
Continuous verification: each request is evaluated on identity, device health, and context, not just once at login. A valid session doesn’t guarantee continued trust if the device posture changes (e.g. disk encryption disabled, OS out of date) or the request pattern looks anomalous.
Micro-segmentation: instead of one flat internal network where anything can reach anything once inside the perimeter, resources are isolated into small segments with policy enforcement between them, so lateral movement after a single compromise is contained rather than open-ended.
Principle of Least Privilege (PoLP): every identity, human or service, is granted only the minimum access required for its specific task, reevaluated regularly rather than granted once and left standing.
Policy Enforcement Point (PEP) and Policy Decision Point (PDP): the architectural core, formalized in NIST SP 800-207. Every access request passes through a PEP, which asks a PDP to evaluate identity, device signals, and policy before granting or denying access, session by session.

Under the Hood

Traditional perimeter security models a network like a castle: strong walls (firewalls, VPN gateways) at the edge, and largely unrestricted trust once inside. Zero Trust assumes the perimeter will eventually be breached, an insider will go rogue, or a device will be compromised, and designs so that a single breach doesn’t cascade into full network access.
Device trust typically relies on device certificates or managed-device attestation issued to enrolled hardware, so a policy engine can distinguish “a corporate laptop meeting current security posture” from “any device with valid credentials,” closing the gap where stolen credentials alone used to be sufficient.
Software-Defined Perimeter (SDP) and Zero Trust Network Access (ZTNA) products implement this by making internal applications invisible to unauthenticated traffic entirely, a request has to pass identity and device checks before the network path to the application even becomes reachable, rather than being reachable and then challenged.
Policy decisions increasingly fold in behavioral signals (typical access patterns, geolocation, time of day) so a technically valid session that behaves anomalously can still be challenged or terminated mid-session, not just at initial login.
Google’s published BeyondCorp architecture illustrates the moving parts concretely: a Device Inventory Service continuously tracks the state and ownership of every corporate device; a Trust Inferer computes a trust level for a device based on that inventory data (patch level, certificate validity, known compromise indicators); an Access Control Engine evaluates a request’s user identity, device trust level, and requested resource against policy; and an unprivileged network means every internal application sits behind an access proxy that enforces this per-request decision, so being physically on Google’s network carries no more inherent trust than being on the public internet. A request reaches an internal application only after passing through this proxy, never by direct network reachability.

The Never-Trust-Always-Verify Access Flow

NIST SP 800-207 formalizes this as a request passing through a Policy Enforcement Point that consults a Policy Decision Point before any access is granted, regardless of where the request originates:

Nothing about this flow is a one-time event. A session that passed all three checks a minute ago is re-evaluated on the next request, since device posture and context can change mid-session even when the identity token is still technically valid.

Why It Matters

Protects against lateral movement: once perimeter defenses like a firewall are bypassed, a flat trusted internal network lets an attacker pivot freely; Zero Trust’s segmentation and per-request verification contain that blast radius.
Fits how organizations actually work now: employees, contractors, and services connect from home networks, personal devices, and multiple clouds, none of which map cleanly to a single defensible network perimeter.
Reduces reliance on any single control failing catastrophically; even a compromised credential or a bypassed firewall rule doesn’t grant broad access on its own.
Aligns security architecture with how breaches actually unfold in practice: nearly every major breach post-dates initial access with lateral movement across a network that trusted anything already inside it.

Common Pitfalls

Relying solely on a legacy VPN as the access boundary and calling it “Zero Trust” without adding per-request identity, device, and context verification behind it
Implementing Zero Trust only at the network layer while leaving application-level authorization coarse and unchanged
Underestimating the operational cost of continuous verification, since strict policies without good UX (e.g. constant re-authentication) push users toward workarounds
Treating Zero Trust as a single product purchase rather than an architectural shift spanning identity, device management, network segmentation, and monitoring
Failing to inventory and classify assets first, so segmentation and policy end up applied inconsistently across the estate
Applying strict device and identity checks to human users while leaving service-to-service and machine-to-machine traffic implicitly trusted, when automated credentials are just as valuable a target
Building the Policy Enforcement Point but never revisiting the Policy Decision Point’s rules, so policy drifts stale relative to the org chart, device fleet, and threat landscape it was written against

Comparison

	Perimeter Security	Zero Trust	VPN-Only Remote Access
Trust basis	Network location (inside = trusted)	Verified identity and context, every request	Network location, extended to remote users
Lateral movement risk	High once perimeter is breached	Low, segmented and continuously verified	High, VPN often grants broad internal network access
Verification frequency	At perimeter entry only	Continuous, per-request	At VPN connection time only
Fit for distributed/remote workforces	Poor	Strong	Moderate, but scales and secures poorly
Implementation complexity	Low, well-understood tooling	High, spans identity/device/network/data	Moderate, but doesn’t solve lateral movement
Formalized by	Firewall/DMZ conventions, no single standard	NIST SP 800-207	RFC standards for VPN protocols (IPsec, etc.)
Machine/service identity	Usually implicit, network-based	Explicit, every service authenticates like a user	Usually out of scope, VPN covers human remote access
Breach containment	Depends entirely on internal segmentation, often flat	Built in, per-resource policy limits blast radius by design	Limited, once connected the VPN client often reaches broad internal ranges

Example

Google’s internal BeyondCorp implementation, one of the earliest large-scale Zero Trust deployments, requires a valid device certificate and authenticated user identity for every internal application request, with no special trust granted for being on Google’s own office network. Modern ZTNA products (Cloudflare Access, Zscaler Private Access) apply the same model for enterprises: an employee reaching an internal tool authenticates via SSO, has their device posture checked, and is granted access to that one application specifically, not the underlying network it runs on.

A service-to-service example: in a Zero Trust-aligned microservice architecture, a billing service calling an inventory service doesn’t get a free pass just because both run inside the same Kubernetes cluster. Each service presents its own workload identity (commonly a short-lived mTLS certificate, via something like SPIFFE/SPIRE), and the receiving service’s own policy decides whether that specific caller identity is allowed to invoke that specific endpoint, the same per-request evaluation applied to a human user, just automated between machines.

Real-World Case Study

Google began building what became BeyondCorp after Operation Aurora, a 2009 targeted intrusion that compromised internal systems at Google and other technology companies partly by abusing the trust that came with being inside the corporate network perimeter. In response, Google spent several years rebuilding internal access around the assumption that its own network was no safer than the public internet: every internal application request, regardless of physical location, was routed through an access proxy that checked device trust and user identity before allowing the request through, with no VPN and no privileged internal network segment at all. Google published the architecture progressively starting around 2014 specifically so other organizations could learn from it, and it’s now the most widely cited real-world precedent for Zero Trust at scale, predating NIST’s formal SP 800-207 standard by roughly six years.

The 2023 MGM Resorts breach is a useful counter-case. Attackers used a vished (voice-phished) help desk call to reset an employee’s MFA and gain valid credentials, then moved through internal systems with comparatively little friction once authenticated, encrypting significant portions of MGM’s infrastructure. It illustrates a limit rather than a failure of Zero Trust: verifying identity strongly stops credential-stuffing and password-only attacks, but it still depends on the identity provider’s own reset and recovery process being equally hardened, since a socially engineered credential reset presents as a perfectly valid identity to every downstream policy check.

Core Pillars

CISA’s Zero Trust Maturity Model breaks implementation into five interdependent pillars, useful for scoping how far along an organization’s adoption actually is:

Identity: strong authentication (MFA, phishing-resistant methods) and continuous validation of every user and service identity.
Devices: inventorying and continuously assessing the security posture of every device requesting access, not just approving it once at enrollment.
Networks: segmenting network access around individual applications rather than a broad trusted zone, encrypting traffic regardless of whether it’s “internal.”
Applications and Workloads: securing access at the application layer itself, with authorization enforced per request rather than assumed once network access is granted.
Data: classifying and encrypting data, with access governed by policy tied to the data’s sensitivity rather than just the network or application it happens to sit in.

Migration Path

Organizations rarely rebuild from scratch; Zero Trust adoption is typically staged:

Inventory: catalog every identity, device, application, and data store before writing a single policy, since segmentation applied to an incomplete inventory just creates new blind spots.
Strong identity first: roll out MFA and phishing-resistant authentication broadly, since every later layer depends on identity verification actually being trustworthy.
Device posture: enroll devices into management and start gating access on posture signals, initially in monitor-only mode to catch false positives before enforcing.
Segment by application: move high-value applications behind a ZTNA proxy or equivalent access gateway one at a time, rather than attempting a network-wide cutover.
Extend to machine identity: apply the same per-request verification to service-to-service traffic, often the last pillar organizations get to, and often the one attackers exploit once human-facing controls tighten.

History

2004: the Jericho Forum coined “de-perimeterization,” an early articulation of the idea that a hardened network edge alone was insufficient security, as organizations increasingly connected to partners and the internet directly.
2010: Forrester analyst John Kindervag formally introduced the term “Zero Trust” and outlined its core principles as a named model, distinct from prior perimeter-focused thinking.
2011 onward: Google’s internal BeyondCorp initiative, developed after the 2009 Operation Aurora attacks, became the most cited real-world case of large-scale Zero Trust implementation, published progressively in a series of papers.
2020: NIST published SP 800-207, formalizing Zero Trust Architecture with standardized terminology (Policy Decision Point, Policy Enforcement Point) that vendors and government agencies now reference directly.
2021 onward: U.S. federal agencies were mandated to adopt Zero Trust strategies following Executive Order 14028, accelerating enterprise adoption well beyond early cloud-native companies.
2022: CISA published its Zero Trust Maturity Model, giving federal agencies and, informally, private organizations a staged framework (traditional, initial, advanced, optimal) for scoring adoption progress across the five pillars.

FAQ

Does Zero Trust mean no network security at all? No, it means not relying on network location as the sole or primary trust signal. Network segmentation and firewalls still play a role, just not as the only line of defense.

Is Zero Trust a specific product? No, despite heavy vendor marketing. It’s an architectural approach spanning identity, device management, network design, and monitoring; a single product can implement pieces of it but not the whole model alone.

Does Zero Trust eliminate the need for VPNs? In most modern implementations, yes for application access, ZTNA replaces VPN-granted broad network access with per-application, per-request authorization. Some infrastructure-level access may still use other secure channels.

How does Zero Trust affect user experience? Done well, it can reduce friction, single sign-on and risk-based authentication mean users aren’t constantly re-entering credentials. Done poorly, overly strict re-verification policies can frustrate users into risky workarounds like credential sharing.

Does Zero Trust apply to service accounts and APIs, or just human users? Both, and increasingly the machine side is the harder gap to close. Human identity verification (MFA, SSO) matured first; workload identity standards like SPIFFE/SPIRE exist specifically to bring the same per-request verification to service-to-service traffic that used to be implicitly trusted inside a network boundary.

What’s the difference between the Policy Decision Point and the Policy Enforcement Point? The PDP is the brain, it evaluates identity, device, and context signals against policy and returns an allow/deny decision. The PEP is the gate, it sits in front of the actual resource, forwards each request to the PDP for a decision, and enforces whatever that decision says, permitting or blocking the request accordingly.

Referenced by

Dig deeper

Spot an error in this note?