“Zero Trust” is the most over-marketed phrase in security and one of the most important ideas in it. Stripped of vendor spin, it is a single principle — never trust, always verify — and an architecture for enforcing it: no access is granted because of where a request comes from (an “internal” IP, the corporate LAN, the VPN), only because of who and what is asking, proven every time. The authoritative definition is NIST SP 800-207; this page turns it into something you can actually build.
It matters because the old model — a hard perimeter around a soft, trusted interior — is how almost every breach on this site's writeups and AD attack-path map succeeds: get one foothold inside, and the flat, trusting interior does the rest. Zero Trust is the structural answer to that.
The core tenets (NIST 800-207)
NIST frames Zero Trust as seven tenets. They are worth reading literally, because most “ZT” products only implement one or two:
- All data sources and computing services are resources to be protected — including the device making the request.
- All communication is secured regardless of network location; being “on the LAN” grants nothing.
- Access is granted per-session, to one resource, with least privilege.
- Access is determined by dynamic policy — identity, device posture, behaviour, and other attributes — not a static rule.
- The enterprise measures the integrity and security posture of all owned and associated assets (no device is trusted by default).
- Authentication and authorisation are dynamic and strictly enforced before access — and continually re-evaluated.
- The enterprise collects data on asset, network, and communication state and uses it to improve policy.
The logical model: PDP and PEP
The mechanism underneath every Zero-Trust implementation is a split between deciding and enforcing:
- Policy Decision Point (PDP) — the brain. It is a Policy Engine (runs the trust algorithm and decides grant/deny) plus a Policy Administrator (establishes/tears down the session). Conditional Access in Entra / Okta policy is a PDP.
- Policy Enforcement Point (PEP) — the gate in the data path that actually allows or blocks the connection (a ZTNA connector, an identity-aware proxy, a next-gen firewall, a service mesh sidecar).
- Trust algorithm inputs — the PDP consults many signals: identity & entitlements (IdP/IGA), device posture (MDM/EDR), threat intel, activity logs/SIEM, PKI, and data sensitivity.
signals feed the decision
+---------------------------------------------------+
| IdP/IGA Device posture Threat intel SIEM |
| PKI Data sensitivity |
+------------------------+--------------------------+
|
v
[ Subject ] --request--> [ PEP ] --?--> [ Resource/App ]
(user+device) ^
| allow / deny / re-auth
[ PDP: Policy Engine + Administrator ]
The PEP never lets the subject reach the resource until the PDP
says yes -- and the decision is re-evaluated continuously, not once.The single most important shift: authentication is no longer a one-time gate at the edge. The PDP re-evaluates the session continuously, so a device that falls out of compliance or an identity whose risk score jumps mid-session can be cut off — the opposite of a VPN, which trusts you for hours once you connect.
The five pillars and maturity stages (CISA)
NIST gives the theory; CISA's Zero Trust Maturity Model gives a roadmap. It scores five pillars across four stages, over three cross-cutting capabilities (Visibility & Analytics, Automation & Orchestration, Governance). You raise each pillar independently:
| Pillar | Traditional → Optimal looks like |
|---|---|
| Identity | Passwords → phishing-resistant MFA, continuous, risk-based, least-privilege |
| Devices | Unmanaged → every device enrolled, posture is an access signal, continuous compliance |
| Networks | Flat, perimeter-trusted → micro-segmented, encrypted, ZTNA per-app |
| Applications & workloads | Public, implicitly trusted → per-request authorised, workload identity (mTLS) |
| Data | Unclassified, open → classified, encrypted, access governed by sensitivity |
What Zero Trust means per domain, in practice
| Domain | The Zero-Trust move | On this site |
|---|---|---|
| Identity | Phishing-resistant MFA (FIDO2/passkeys), Conditional Access, least privilege, no standing admin | the real perimeter — see the enterprise guide |
| Device | Only compliant, managed, healthy devices get a token (MDM + EDR posture) | device posture as a PDP input |
| Network | ZTNA replaces flat VPN; micro-segmentation controls east-west | the segmentation page |
| Workload | Per-request authorisation; service identity and mTLS between services | landing zones & service mesh |
| Data | Classify, encrypt, and gate by sensitivity — so a bypass still yields unusable data | data security in the end-to-end guide |
Deploying it: you migrate, you don't rip-and-replace
NIST describes three implementation approaches — identity-centric (enhanced identity governance), micro-segmentation, and network-infrastructure/software-defined perimeters — and real programmes blend all three. Nobody buys Zero Trust in a quarter. A defensible sequence:
- Identity first — one IdP, phishing-resistant MFA everywhere, kill legacy/basic auth, Conditional Access. This alone removes most credential-based intrusion.
- Device posture — enrol and attest devices so compliance becomes an access signal.
- Pilot ZTNA for a set of apps, running alongside the VPN, then expand and retire VPN.
- Segment the crown jewels — micro-segment the highest-value assets before boiling the ocean.
- Instrument everything — the Visibility pillar feeds the PDP and the SOC; Zero Trust without telemetry is just friction.
Where teams go wrong
- Treating ZT as a product. A vendor “Zero Trust” box is a PEP, not an architecture. ZT is a strategy the whole estate implements.
- ZTNA ≠ Zero Trust. Replacing the VPN with ZTNA is one pillar; if the app still trusts anything that reaches it, you've moved the flat network inward.
- Authenticate-once-then-trust. If the session isn't continuously evaluated, it isn't Zero Trust — it's SSO with extra steps.
- Forgetting workloads. Service-to-service traffic is where attackers pivot; machine identity and mTLS matter as much as user MFA.
Red team ↔ blue team: what Zero Trust actually breaks
Trace Zero Trust against the attack techniques elsewhere on this site — each tenet removes a step:
| Attack path | How Zero Trust breaks it |
|---|---|
| Pass-the-hash / lateral movement | No implicit network trust + micro-segmentation: a stolen hash can't freely reach other hosts; per-resource auth re-checks every hop |
| LLMNR/NBT-NS poisoning & relay | Segmentation and signed/authenticated channels shrink the broadcast domain and the relay target set |
| Flat VPN foothold | ZTNA exposes only the one entitled app, never the LAN — there is no “flat network” to land on |
| Over-privileged standing admin | Least-privilege + just-in-time elevation + continuous evaluation collapse the window a stolen admin token is useful |
Zero Trust is not a wall that stops the first click — phishing still works. It is the architecture that ensures the first click doesn't become domain compromise, by refusing every implicit trust the attacker needs for step two onward.
Key takeaways
- Zero Trust = never trust, always verify, per-session, least-privilege, continuously re-evaluated.
- The machinery is PDP (decide) + PEP (enforce) fed by identity, device, and behaviour signals.
- It's a strategy across five pillars, built by migration — identity first, then device, network, workload, data.
- Its value is removing the implicit trust that turns one foothold into a breach.