Most Zero Trust deployments hit a wall at "MFA + network segmentation" — and teams call it a day, assuming the job is done. But true Zero Trust isn't a one-and-done login check. It's a dynamic architecture where access decisions are continuously re-evaluated. Let's break down how it actually works under the NIST SP 800-207 standard, what a "trust score" really means, and why IdP, ZTNA, and SIEM functioning in silos don't equal Zero Trust.
Three Terms You Need to Stop Confusing
Before diving in, let's clear up the terminology. The industry often tosses around Zero Trust, ZTA, and ZTNA as synonyms, creating unnecessary friction and confusion.
- Zero Trust is a concept and a security principle: "Trust no one by default, verify every request." It's a mindset, not an off-the-shelf product.
- ZTA (Zero Trust Architecture) is the execution of that concept. It's the blueprint of how the Zero Trust principle is mapped onto specific components and their interactions. This is exactly what the NIST SP 800-207 standard outlines.
- ZTNA (Zero Trust Network Access) is just one technology within ZTA. It handles a specific job: securing user network access to applications. ZTNA is a component of the architecture, not the entire architecture itself.
The hierarchy is straightforward: Zero Trust (Concept) → ZTA (Architecture) → ZTNA (Component).
Why the Classic Approach Fails
Picture this: At 9:00 AM, a user logs in via MFA and gets a standard 8-hour token. At 11:30 AM, they click a phishing link in an email, and an attacker takes control of their laptop. Until 5:00 PM, the attacker roams the network freely using that legitimate token. SSO is working, MFA was cleared, and nothing looks out of place. By the time a SIEM analyst gets to the alert, the data has already been exfiltrated.
The problem isn't weak MFA. It worked perfectly: at 9:00 AM, the legitimate user was indeed at the keyboard. The failure is that the access decision was made once and never challenged again. Between "user logged in" and "token expired," there wasn't a single checkpoint where the system could say, "Hold on, the context has changed."
To fix this, we need two fundamental shifts:
- Trust thresholds for resources. An internal wiki has a low threshold; an admin panel demands a high one.
- Continuous evaluation. We need a component that constantly scores the user's current trust level against the resource's threshold.
That component is the Policy Engine. And that is the exact differentiator between true Zero Trust and a "classic model topped with MFA."
The NIST Zero Trust Architecture
The foundational playbook here is NIST SP 800-207 (published in 2020). It defines the architecture through core components:
- Policy Enforcement Point (PEP) — the physical tollbooth for traffic. The PEP doesn't make decisions; it executes. It asks the PDP, gets an answer, and either allows or blocks traffic. In modern setups, a ZTNA gateway usually plays this role.
- Policy Decision Point (PDP) — the brain where decisions are made. It consists of two logical parts: the Policy Engine (PE) aggregates signals and calculates the trust score, while the Policy Administrator (PA) hands the verdict down to the PEP. In practice, PE and PA are often bundled into a single microservice.
- Policy Information Points (PIP) — the signal sources. This is where the PE gets its telemetry to make decisions.
Trust Score: Measuring Confidence
A trust score quantifies the system's current confidence in a user. Think of it as a 0 to 100 scale (though some implementations use 0.0–1.0 or text-based categories).
The Policy Engine ingests a catalog of signals from the IdP, ZTNA, and SIEM. Each signal carries a weight — a positive or negative number. These signals are multiplied by their weights and tallied. You don't get these weights from a textbook; you calibrate them against your company's real-world behavior, analyzing false positives and tweaking the system.
However, a purely additive model has a blind spot. A severe negative signal (an IoC match, a confirmed compromise) shouldn't just be added to the rest. This is why override rules are layered on top of the additive model: critical signals immediately tank the score to zero, regardless of other positive factors.
Continuous Evaluation in Action
A trust score is dynamic. It recalculates at every state change. Let's say the SIEM flags a suspicious process and fires a signal to the PE. The score drops. The user isn't fully booted from the system, but access to highly critical resources (databases, admin panels) is automatically revoked in seconds. That is what real-time event response looks like.
The Three Signal Layers: IdP, ZTNA, SIEM
- IdP (Identity Provider) answers the question: "Who is in front of us, and how sure are we?" A modern IdP (Keycloak, Okta, Microsoft Entra ID) pulls users from Active Directory and pushes rich attributes via OIDC: user ID, MFA completion fact, factor type (SMS, TOTP, hardware key), plus risk-based signals such as a new country, unusual login time, or unrecognized device.
- ZTNA (Zero Trust Network Access) answers the question: "What device is the user working from, and where are they?" Unlike a VPN that grants broad network access, ZTNA creates an encrypted tunnel to a specific application and verifies the device on every connection. In ZTA it plays a dual role — both the PEP (enforcer) and a PIP (signal source) — reporting device ID, posture check, IP, ISP, and session duration.
- SIEM (Security Information and Event Management) answers the question: "What is happening around and inside the session?" This is the most critical layer for continuity. The IdP signals at login and ZTNA upon request, but the SIEM fires a signal at any moment during the session when something changes (EDR alerts, network anomalies). With it, Zero Trust becomes a continuous process.
How Signals Reach the Policy Engine
Delivery channels matter just as much as the signals themselves.
- IdP usually relies on a hybrid approach: pushing data via OIDC tokens (push), through event listeners (push), or via Admin APIs upon request (pull).
- ZTNA leans heavily on pull: the PE requests status updates via API.
- SIEM must operate on a push model. It needs to fire a webhook to the PE the instant a rule triggers, otherwise you kill the entire point of an immediate reaction.
How the Policy Engine Controls ZTNA: Three Tiers of Integration
Once the PE calculates the score, it has to pass the verdict to the execution node (ZTNA). There are three tiers of integration:
- Tier 1: Policy Switching. Pre-defined policies of varying strictness are created in the ZTNA. The PE simply toggles them on or off via API. Granularity is at the policy level, not the individual user level.
- Tier 2: Group Shifting. The ZTNA maintains trusted and quarantine groups. When a score changes, the PE shifts the user between them via API. It delivers pinpoint granularity without a monstrous integration effort — perfect for starting out.
- Tier 3: Per-Request Authorization. The PEP queries the PE on every single connection. This offers maximum dynamic control but requires the ZTNA to support external authorization (or the addition of a proxy layer).
Conclusion: From Theory to Practice
Deploying true Zero Trust is a transition from isolated login checks to continuous context analysis. Siloed systems like IdP, ZTNA, and SIEM do not magically create a zero-trust architecture on their own. In the NIST paradigm, they act merely as signal providers (PIPs) for the central brain — the Policy Engine.
To ensure your project doesn't stall, move iteratively: avoid overly strict limits at the start, keep data exchange asynchronous through caching, and roll out complex integration tiers gradually. This approach lets you build a transparent, reliable, and user-friendly security system tailored to the real needs of your business.