What is Zero Trust architecture? (NIST SP 800-207 explained)

Most vendors say “Zero Trust” and mean “we have SSO and MFA”. That’s not Zero Trust. The phrase comes from a 2010 paper by John Kindervag at Forrester and was later formalised by NIST in Special Publication 800-207, published in 2020 - the closest thing to a canonical definition the industry has.

The core premise: stop treating anything on your network as inherently trusted. The traditional “castle and moat” model assumes that a request from inside the perimeter is probably fine. Zero Trust assumes it isn’t.

The PDP/PEP model

NIST 800-207 defines Zero Trust around three logical components:

• Policy Engine (PE): makes the trust decision - allow or deny
• Policy Administrator (PA): translates the decision into an instruction for the enforcement layer
• Policy Enforcement Point (PEP): sits in-path and actually blocks or permits the traffic

The PE and PA together form the Policy Decision Point (PDP). Traffic flows through the PEP, which checks with the PDP before granting access to any resource.

What makes this different from a firewall rule? The enforcement point isn’t static. Trust can be granted, reduced, or revoked mid-session based on signals gathered after authentication. An attacker who compromises valid credentials still has to convince the PDP that the device is healthy and behaving normally - on every request, not just at login.

What goes into a trust decision

The interesting question isn’t the architecture diagram - it’s what inputs the Policy Engine uses. NIST identifies five broad categories of signal:

1. Device identity - is this a known, enrolled device with a valid certificate?
2. Behavioural signals - does this device’s recent activity look normal?
3. Network context - where is the request coming from? Is the IP known?
4. Session data - how long ago did this session authenticate? Is the session token fresh?
5. Posture - is the OS patched? Is the security agent running? Is disk encryption enabled?

These signals are combined and weighted to produce a trust score. The score doesn’t just gate access with a binary allow/deny - it maps to a graduated set of trust levels that can change during the session.

Trust level → access policy

FULL - all resources accessible, normal operation
REDUCED - read-only access, some APIs restricted
QUARANTINE - isolated from network resources, alert raised
DENIED - no access, session terminated

A device enrolled with a valid mTLS certificate that’s been behaving normally and connecting from its usual network segment would score full trust. The same device suddenly scanning internal subnets or connecting from an unknown IP can drop to REDUCED or QUARANTINE automatically - without waiting for a human to intervene.

Why this matters for endpoint security

Most Zero Trust deployments focus on network and identity. What NIST 800-207 makes clear - and what many implementations skip - is that the device itself is a trust signal.

A compromised endpoint with a valid certificate is more dangerous than an unknown device, because it’s already inside the trust boundary. Continuous endpoint monitoring - behavioural detection, posture checks, agent health - needs to feed back into the trust scoring system in real time.

This is where EDR becomes relevant to Zero Trust. An EDR sitting alongside a Zero Trust architecture but not influencing trust decisions is leaving signal on the table. If your endpoint detection knows a process is injecting into LSASS, that should immediately reduce the device’s trust level - not queue a ticket for a human to review.

How Zero Trust changes lateral movement risk

Traditional access models make a binary decision at entry: authenticate once, trust everything inside. That works until an attacker has valid credentials.

Zero Trust moves enforcement inward. Every sensitive resource has its own enforcement point. A compromised credential still gets the attacker onto the network, but each downstream resource checks the full trust picture before allowing an action. Lateral movement requires repeatedly convincing enforcement points that the device is trusted - and that’s hard when behavioural signals are evaluated continuously.

The upshot: attackers who compromise a single endpoint are contained to what that endpoint’s current trust level permits. One noisy action - a reconnaissance scan, an unexpected process spawn - drops the trust level and restricts further movement before the attacker can escalate.

LightEDR implements the full PDP/PEP model per NIST SP 800-207, with five scored trust signals mapping to four trust levels. When behavioural signals spike, trust drops and access is restricted automatically. If you’re working out how to wire Zero Trust into your SOC stack, get in touch.