Zero Trust is not a product - it's an architecture

Every major security vendor now has a “Zero Trust” product. Firewalls, VPNs, identity platforms, and endpoint agents all carry the badge. Some of them are genuinely useful. Very few of them are actually Zero Trust in the NIST sense. Understanding the difference matters before you spend budget on something that just shifts the perimeter rather than eliminating it.

What NIST SP 800-207 actually defines

Zero Trust Architecture (ZTA) is a security model first formalised by NIST in Special Publication 800-207, published in 2020. The core premise is simple: no network location is inherently trusted. A device inside your perimeter gets the same level of scrutiny as one connecting from a coffee shop. Trust is earned continuously, not granted by geography.

The NIST model centres on two logical components:

• Policy Decision Point (PDP): evaluates every access request against current context - device health, user identity, network posture, behaviour patterns - and decides whether to grant, restrict, or deny access.
• Policy Enforcement Point (PEP): sits between the subject (user or device) and the resource, enforcing whatever the PDP decided.

The critical word is continuous. Zero Trust isn’t a one-time authentication gate. The PDP reassesses trust dynamically as context changes. A device that passes its morning check can be quarantined by afternoon if its behaviour shifts - without waiting for the next login or certificate renewal.

What Zero Trust is not: a VPN with multi-factor authentication bolted on. Moving authentication to the edge of your network is a useful improvement, but it still assumes that once a device is “in”, it stays trusted until explicitly revoked. That’s the old perimeter model with a different login screen.

Why most “Zero Trust” products are just marketing

The vendor confusion stems from how loosely the term is applied. A firewall vendor calls its microsegmentation feature “Zero Trust Network Access.” An identity provider calls its conditional access policies “Zero Trust.” An endpoint agent calls its certificate-based enrolment “Zero Trust.” Each claim has some truth to it - but none of them individually implements Zero Trust Architecture.

A genuine ZTA requires all of the following to work together:

1. Strong device identity - certificates issued to individual devices, private keys that never leave the device, mutual TLS on every connection
2. Continuous trust scoring - a live assessment that combines multiple signals: certificate validity, behavioural patterns, network reputation, session context, device posture
3. Graduated enforcement - not just allow/deny, but a spectrum of trust levels that throttle access proportionally. A device with suspicious behaviour shouldn’t be binary blocked; it should move to a restricted state while investigation happens
4. Fail-closed defaults - if the PDP is unreachable, access is denied, not granted. This is where many implementations quietly break the model

If a product you’re evaluating can’t describe exactly how it implements the PDP/PEP split, ask directly. If the answer involves “our cloud verifies your identity at login”, that’s a perimeter model. If the answer involves continuous, multi-signal assessment with graduated trust levels and real-time enforcement, you’re closer to the NIST model.

What it looks like in practice

Here’s a simplified example. An endpoint connects to a resource. The PEP intercepts the request and asks the PDP: should this device have access right now?

The PDP checks five categories of signal:

Signal	What it measures
Certificate	Valid device cert, issued via CSR (private key never transited)
Behaviour	Process execution, network patterns, file access anomalies
Network	Source IP reputation, expected network segment
Session	Time since last verification, active session context
Posture	OS patch level, known-good configuration state

Each signal contributes to an aggregate trust score. Depending on that score, the device lands in one of four states: FULL access, REDUCED access (limited resources), QUARANTINE (isolated pending review), or DENIED. The state is re-evaluated as signals change - not on a fixed schedule, but as events arrive.

This is the architecture LightEDR implements. It isn’t a label we attached to an existing product category. The PDP/PEP model, the five-signal scoring, and the four trust levels are the design, not an add-on. If your current EDR vendor claims Zero Trust but can’t describe a comparable architecture, it’s worth asking what you’re actually buying.

Zero Trust done properly is harder to build than a perimeter with strong authentication. That’s exactly why most vendors rebrand rather than rebuild. When evaluating platforms, hold them to the NIST standard - not the marketing page.

Curious how the architecture holds up for your environment? Get in touch and we’ll walk through it with you.