Zero Trust: never trust, always verify

Monday, two ways

On a Monday morning an attacker phishes Daniel and gets away with a valid session. What happens next depends on how his company thinks about trust.

In the first version, Daniel’s session was on the corporate VPN, so the attacker is now inside and treated as trusted. They move sideways across a flat network, reach systems Daniel never touched, and escalate, because being inside meant being trusted. One stolen session becomes a broad compromise. In the second version, every resource the attacker reaches for is checked again, request by request. The device they’re using isn’t Daniel’s managed, compliant laptop, so posture checks fail or demand step-up. His apparent behavior, new locations, unfamiliar resources, odd hours, drifts away from his profile, the risk score rises, and the system asks for a re-authentication the attacker can’t pass. Least privilege means even Daniel’s legitimate access was narrow, and segmentation blocks movement toward anything he didn’t already use. The stolen session is contained close to where it started, and the monitoring lights up for the security team.

The second version is Zero Trust. Nothing in it assumes the breach was prevented; it assumes the breach happened and asks how far it gets. This module built up the machinery of access: proving identity with factors, MFA, and biometrics, spreading one sign-in across apps with SSO, and holding and defending the result with session management. Zero Trust is the strategy that ties it together and decides how much to trust any of it, and when.

For decades security ran on a perimeter model: build a strong wall, the firewall, and treat anything inside as trusted. Cloud services, remote work, SaaS, mobile devices, and contractors erased the “inside,” and attackers learned that getting past the wall once bought them a trusted run of everything behind it. Zero Trust’s answer is to stop trusting the network and verify every access explicitly. This is a strategic article, about a way of thinking more than about one protocol. The reference is NIST SP 800-207, together with the CISA Zero Trust Maturity Model.

The principles

Zero Trust gets turned into slogans, but the substance is three disciplined principles.

Never trust, always verify. No request is trusted because of where it comes from. Being on the corporate network, on the VPN, or behind the firewall grants nothing. Every access, user to app, service to service, even inside the datacenter, is authenticated and authorized explicitly on its own merits, using identity, device, and context. Trust is never inherited from the network.

Assume breach. Design as if an attacker is already inside. That flips the mindset from keeping them out to limiting what they can do once in. It drives segmentation, so a breach in one place doesn’t spread; least privilege, so a compromised account reaches little; rich logging, so you can see the intruder; and short-lived, re-checked access, so a foothold decays instead of lasting. You stop betting everything on a wall that will eventually fall.

Least privilege. Every identity, human or workload, gets the minimum access it needs for the minimum time, with no broad standing grants “just in case.” It’s the same principle that governs authorization and privileged access management, applied as the default posture: access is narrow, scoped, and expires. It’s what makes “assume breach” survivable, because if privileges are minimal, a compromise is contained by design.

Perimeter security asks whether you’re inside the network. Zero Trust asks who you are, what you’re using, and whether this specific request is safe right now, every time. That shift from location to per-request verification is the whole idea.

The seven tenets

NIST SP 800-207 doesn’t stop at principles. It lists seven tenets that turn “never trust, always verify” into requirements you can test, and auditors and architects often cite them by number. In paraphrase: all data sources and computing services count as resources, so there’s no privileged zone that doesn’t need protecting. All communication is secured regardless of network location, with traffic authenticated and encrypted the same inside as outside. Access is granted per session, so a grant to one resource doesn’t automatically extend to the next resource or the next session. Access is decided by dynamic policy, drawing on identity, application, the requesting device, and behavioral and environmental attributes, rather than by a static rule tied to an IP range. The organization measures the integrity and posture of every asset, so a non-compliant device is a lower-trust device. Authentication and authorization are dynamic and strictly enforced before access, evaluated continuously rather than once. And the organization collects telemetry on assets, infrastructure, and communications and uses it to improve its posture, which makes monitoring the feedback loop that keeps the decisions sharp.

Read the third and sixth tenets together and you have the operational essence: per session, evaluated fresh, every time. Read the fifth and you see why device posture sits next to identity in every decision.

The architecture: PEP, PDP, and the trust algorithm

NIST SP 800-207 describes Zero Trust with a small, precise set of components, and learning them turns the philosophy into something you can build.

The Policy Enforcement Point (PEP) is the gate in front of a resource. It intercepts each request and enforces the decision, allow, block, or allow with conditions, without deciding anything itself. In practice it’s a reverse proxy, an identity-aware gateway, or a service mesh sidecar. The Policy Decision Point (PDP) is the brain. For each request the PEP forwards, it evaluates policy and returns a verdict. NIST splits it into the policy engine, which makes the decision, and the policy administrator, which issues or revokes the credentials or session tokens that let the PEP open the gate. The trust algorithm is the logic inside the PDP that weighs every signal to reach a verdict: the identity and its entitlements, the device’s posture, the context of the request such as location and time, and behavioral and threat-intelligence inputs. It can be a simple yes or no, but it works best as a score that adapts, which is the risk-based adaptive authentication idea generalized to every access decision. And the policy information points are the sources of those signals: the identity provider, a device posture or EDR feed, threat intelligence, the SIEM and behavioral analytics, entitlement data.

flowchart LR
  accTitle: Zero Trust policy decision and enforcement loop
  accDescr: A subject makes a request to a resource. The request reaches a Policy Enforcement Point, which forwards it to a Policy Decision Point. The Policy Decision Point runs a Trust Algorithm that reads signals from information points including the identity provider, device posture, context, and threat intelligence. The Trust Algorithm returns a decision of allow, step-up, or deny to the enforcement point, which grants or blocks access to the resource. A continuous re-evaluation arrow loops from the resource session back to the decision point so trust is reassessed as signals change.
  S[Subject: user or workload] --> PEP{Policy Enforcement Point}
  PEP -->|asks| PDP[Policy Decision Point<br/>Trust Algorithm]
  IdP[Identity + entitlements] --> PDP
  DEV[Device posture] --> PDP
  CTX[Context: location, time] --> PDP
  TI[Threat intel + behavior] --> PDP
  PDP -->|allow / step-up / deny| PEP
  PEP -->|granted| R[(Resource)]
  R -. continuous re-evaluation .-> PDP

Continuous adaptive trust

The classic weakness of authentication is that it happens once, at the door. Everything after sign-in rides on that single decision, which is why a stolen SSO session or a hijacked cookie is so powerful: it inherits a trust decision made minutes or hours earlier, under conditions that may no longer hold.

Continuous adaptive trust closes that gap by re-evaluating trust throughout the session instead of freezing it at sign-in. The trust algorithm keeps watching, and when the picture changes, so does the decision. If the user’s location jumps to another country mid-session, the system asks for step-up or a fresh sign-in. If their behavior stops matching their profile, the behavioral biometrics signal, the risk rises and access is restricted or challenged. If their device falls out of compliance because a patch is missing or the EDR agent stopped, access is narrowed or cut at once. If threat intelligence flags the source address, the session is blocked mid-flight. Standards such as CAEP and the Shared Signals Framework, covered in the frontier article, let the identity provider push those changes to every application in real time.

This is where the whole module comes together. Behavioral biometrics feeds continuous trust silently. Step-up is its response to rising risk. Short sessions and server-side revocation are what let it act on a changed verdict. It’s “always verify” stretched from one instant to the entire lifetime of access, and it’s the operational heart of a mature Zero Trust program.

Identity is the control plane

If network location no longer grants trust, something else has to, and that something is identity. In Zero Trust, the question of whether a request should be allowed is answered mainly from who the authenticated subject is, user or workload, what they’re entitled to, what state their device is in, and what their risk is right now. Identity is the one signal present in every access decision.

That makes the identity provider and its policy engine the main enforcement point, the control plane of the architecture, and it’s why this domain matters so much. Strong authentication with phishing-resistant factors, federated access hardened against its blast radius, and well-managed sessions aren’t separate topics; they’re the ground Zero Trust stands on. Weak identity means weak Zero Trust, however much is spent on network tooling. That’s what people mean by “identity is the new perimeter”: the boundary you defend is no longer the network edge but the identity behind each request.

Some organizations buy network micro-segmentation and call it Zero Trust while their identity layer still runs on passwords and SMS codes. That’s backwards. Because identity is the control plane, Zero Trust maturity starts with getting identity right: MFA everywhere, phishing-resistant factors for privileged access, least-privilege entitlements, continuous risk evaluation. Network controls matter, but they sit on top of identity, not in place of it.

ZTNA: what replaces the trusted VPN

The most visible product-level form of Zero Trust is ZTNA, Zero Trust Network Access, and comparing it with the classic VPN makes the strategy concrete. A traditional VPN is a perimeter tool in disguise. Once you authenticate to it, you’re placed on the network and can usually reach a wide range of internal resources, implicit trust granted by a single sign-in, which is exactly the model Zero Trust rejects. Steal the VPN credentials and you inherit that reach, as in the first version of Daniel’s Monday.

ZTNA turns this around. Instead of putting you on the network, it brokers access to individual applications through a policy-checked gateway, a PEP, and opens a connection to one resource only after the PDP has evaluated identity, device posture, and context for that request. You reach the specific app you’re allowed, never a flat network segment. Applications stay hidden from the network and are reachable only through the broker, which shrinks what an intruder can even see. And access can be narrowed or cut mid-session as posture changes, where a VPN tunnel, once up, is trusted until it drops. ZTNA is often sold as part of a SASE (Secure Access Service Edge) platform, but it’s a component that applies Zero Trust to remote access, not Zero Trust itself.

Micro-segmentation and the blast radius

“Assume breach” needs a mechanism, and micro-segmentation is the main one at the network and workload layer. The old model was a flat internal network: compromise one machine and you could reach thousands. Micro-segmentation divides the environment into small zones, each with its own policy, ideally down to individual workloads, so that reaching one thing doesn’t give you the next. An attacker who compromises a single server finds that lateral movement, the technique behind nearly every large breach, is blocked by policy at each hop, and each hop must pass identity and posture checks of its own. Combined with least privilege on identities, segmentation turns a foothold from a launchpad into a dead end. Identity decides who; segmentation limits how far.

Workloads and non-human identities

Zero Trust is usually explained with a human user in mind, but most access in a modern system is machine to machine: services, containers, functions, scripts, and more and more AI agents calling each other. These non-human identities now far outnumber people, and the same principles apply without exception. Every service call is authenticated and authorized explicitly, gets least privilege, and is never trusted just because it comes from “inside the cluster.”

In practice, workloads get strong, verifiable identities instead of shared secrets in config files: standards such as SPIFFE and SPIRE, cloud workload identities such as managed identities and IAM roles, and short-lived, automatically rotated credentials in place of long-lived API keys. The trust algorithm evaluates a service’s identity and posture just as it would a person’s. As human authentication gets harder to beat, attackers move to the softer and far more numerous machine identities, which is why the privileged access and non-human identity domain later in the curriculum matters so much. Zero Trust has to cover them, or it has a gap exactly where the volume is.

Where to start

Because Zero Trust is a journey, the practical question is never how to finish it but where to start and in what order. A defensible sequence, consistent with the CISA maturity model, begins with an inventory, because you can’t protect what you can’t see: the identities, human and non-human, the devices, and the applications and data they reach. Next comes fixing identity: MFA everywhere, phishing-resistant factors for privileged and administrator access, consolidation onto a strong identity provider. It’s the highest-leverage move, because identity is the control plane. Then bring in device posture, so an unmanaged or vulnerable device is treated as lower-trust. Then enforce least privilege, trimming standing access, adopting just-in-time elevation, and narrowing entitlements, which shrinks the blast radius that “assume breach” is designed around. Then segment and broker access, replacing flat network trust with per-application access and micro-segmentation. And finally instrument and adapt, wiring telemetry into monitoring and ITDR and moving the trust algorithm from static rules toward continuous, risk-based evaluation.

The order matters. Teams that start by buying a segmentation appliance while skipping the identity work get the label of Zero Trust without the protection.

Myths

Zero Trust is one of the most misused terms in security, and clearing up the myths is part of understanding it. The biggest is that it’s a product you buy. No vendor ships Zero Trust in a box. It’s a strategy and an architecture assembled from identity, device posture, policy, segmentation, and monitoring, and a product can be a component but never the whole. Closely related is the idea that it’s one technology: it isn’t micro-segmentation alone, nor a ZTNA gateway alone, nor MFA alone, and remove identity, monitoring, or least privilege and it stops being Zero Trust.

Another myth is that it means trusting nothing and giving up usability. It means removing implicit, unearned trust, not making systems unusable. Done well it often feels smoother: when risk is low, verification is invisible, a passkey and a compliant device passing silently, and friction appears only when risk rises. Trust is earned per request, not abolished. People also treat it as a project you finish, when it’s a journey measured by maturity. The CISA model frames it across pillars, identity, devices, networks, applications, and data, that advance from traditional to optimal over time. And it doesn’t replace the firewall or the VPN on day one. It changes their role and reduces reliance on them, but adoption is incremental.

The most damaging mistake of all is treating Zero Trust as a purchase: buy a product with the label, declare victory, and leave identity, least privilege, and continuous monitoring untouched. That brings the cost of Zero Trust with none of the protection. Start from the principles, anchor on identity, measure with a maturity model, and treat every product as a means, never the goal.

Where it sits among the frameworks

Zero Trust connects to guidance security teams already answer to, and naming those links helps when you present it to leadership. NIST SP 800-207 is the architectural reference. The CISA Zero Trust Maturity Model turns it into pillars and stages for practical assessment. The U.S. federal mandate, OMB M-22-09, put agencies on Zero Trust timelines, which is much of why the term went mainstream, and the DoD Zero Trust Reference Architecture adds a defense-grade breakdown of capabilities.

It complements rather than replaces the wider frameworks. Zero Trust is a strategy for access; the NIST Cybersecurity Framework frames the whole risk program around it; ISO 27001 governs the management system; and least privilege and segmentation appear in nearly every control catalog, from CIS Controls to PCI DSS. In practice, the same MFA rollout, least-privilege review, and continuous monitoring that raise your maturity also produce audit evidence for access control, authentication, and logging requirements across several frameworks at once, which turns “another security project” into a posture that satisfies obligations you already have.

Pitfalls in the rollout

Even teams that understand Zero Trust in principle trip over recurring operational traps. Add verification everywhere at once and users revolt, leadership backs off, and the program stalls; the cure is the adaptive approach, making low-risk access invisible so friction appears only when risk rises. Aggressive policies that misjudge posture or context lock out real users and workloads in a self-inflicted outage; roll out in monitor-first mode, logging what would have been blocked, before enforcing, and enforce in stages. Teams harden human sign-in and leave service accounts, API keys, and machine identities on old implicit trust, which is exactly where the attacker goes next. Per-resource, per-context rules multiply into a tangle nobody fully understands, which becomes a risk in itself; centralize policy, write it as code where possible, and review it. New cloud apps get Zero Trust while legacy systems, third-party connections, and shadow IT keep their flat trust, and attackers head straight for what’s left unprotected, so the inventory has to be honest about what isn’t covered yet. And teams declare victory at a milestone and let the posture drift, when Zero Trust has to be maintained continuously or it decays. Zero Trust rarely fails on the concept. It fails on rollout discipline.

Recap

Zero Trust is the strategy that gives the rest of this module its purpose. It replaces perimeter trust with explicit, per-request verification, built on three principles from NIST SP 800-207: never trust, always verify; assume breach; least privilege. Its architecture separates decision from enforcement, with a PEP that enforces and a PDP that runs a trust algorithm over signals from the policy information points. Continuous adaptive trust re-evaluates trust across the whole session, powered by behavioral signals, step-up, short sessions, and revocation. Identity is the control plane, so strong authentication, hardened SSO, and session hygiene are its foundation. And it’s a strategy and a journey, not a product; every myth collapses into that one point.

Three questions to test yourself

1. Map the module together: for a single “transfer money” request, say which Zero Trust component (PEP, PDP, trust algorithm, or a policy information point) each of these corresponds to: the identity provider’s MFA result, the reverse proxy in front of the API, the risk score, and the device-compliance feed.
2. A vendor pitches your CISO a “Zero Trust platform” that’s essentially a network micro-segmentation appliance. Give three questions that would reveal whether adopting it alone would actually deliver Zero Trust.
3. Using continuous adaptive trust, explain how a Zero Trust system should react to a stolen SSO session differently from a perimeter model. Which controls from earlier in this module make that reaction possible?

Hands-on exercises

1. Find the components in a real stack. For a system you know, even a personal cloud account, identify what plays the PEP, what plays the PDP, and which signals feed the decision (MFA, device, location). Sketch the path of a request.
2. Score identity maturity. Using the identity pillar of the CISA Zero Trust Maturity Model, place an organization you know on the scale from traditional to optimal for MFA coverage, least privilege, and continuous evaluation. Name the single most valuable next step.
3. Rewrite a perimeter rule. Take a legacy rule like “anyone on the VPN can reach the internal wiki” and rewrite it as a per-request policy based on identity and device. Say which signals your trust algorithm would need to enforce it.