Zero Trust Architecture (NIST 800-207) Explained: Principles, Components, and Workflow

Introduction

Despite its growing popularity, Zero Trust is still widely misunderstood. Many organizations struggle with planning and implementation—partly because of vendor marketing hype and partly due to the lack of universal industry standards.

To provide clarity, the National Institute of Standards and Technology (NIST) released what’s considered the gold standard for Zero Trust: Special Publication 800-207. This framework clearly defines:

• What Zero Trust Architecture (ZTA) is
• The core principles it’s built on
• The essential components that bring it to life

In this article, we’ll break down NIST 800-207 to show what a Zero Trust Architecture really is, how it works, and why it’s not a product but a security philosophy.

---

What Is Zero Trust?

Zero Trust is not a single product or a one-time deployment. It’s the principle that no user or device—inside or outside the network—should be trusted by default. Instead, every access request must be:

1. Verified
2. Continuously validated
3. Evaluated against dynamic, contextual policies

This marks a fundamental shift from the traditional perimeter model, where internal users were automatically trusted once inside the network. In Zero Trust:

• There’s no concept of “internal” or “external” users.
• Every user, device, application, and connection is individually authenticated and authorized.

---

Defining Zero Trust Architecture (ZTA)

A Zero Trust Architecture, per NIST 800-207, is:

A cybersecurity architecture built on Zero Trust principles that applies continuous verification to every access request, regardless of location.

ZTA is flexible in how it’s implemented but must align with the seven core tenets outlined in NIST 800-207.

---

The Seven Core Tenets of Zero Trust (NIST 800-207)

1. All data sources and computing services are considered resources.
2. All communication is secured, regardless of network location.
3. Access is granted on a per-session basis.
4. Dynamic policy decisions consider identity, authentication, device posture, and context.
5. Authentication and authorization are strictly enforced before access is granted.
6. The enterprise continuously monitors the integrity and security posture of all assets.
7. Logging and continuous reassessment are essential for maintaining trust.

No matter the technology stack, all seven must be met to be considered true Zero Trust.

---

Zero Trust Workflow: Subject → PDP/PEP → Resource

At its simplest, the NIST 800-207 Zero Trust workflow looks like this:

1. Subject – A user or machine requesting access (coming from the “Untrusted Zone”).
2. Resource – The protected application, dataset, or service being requested.
3. Policy Decision and Enforcement Point (PDP/PEP) – The broker that decides whether access is allowed.

Why PDP/PEP Placement Matters

The PDP/PEP sits as close to the resource as possible. This minimizes the implicit trust zone—the area in which all entities are trusted. The smaller this zone, the less risk there is of lateral movement if a system is compromised.

---

Breaking Down the PDP and PEP

NIST 800-207 defines the PDP/PEP as two separate but tightly integrated functions:

• Policy Enforcement Point (PEP) – The gatekeeper positioned close to the resource, enforcing the decision made by the PDP.
• Policy Decision Point (PDP) – The brain that determines whether access should be granted, based on enterprise policies and contextual data.

This separation allows:

• Enforcement to happen near the resource
• Policy logic to remain centralized and consistent

---

Inside the Policy Decision Point: Engine & Administrator

NIST further splits the PDP into two sub-components:

1. Policy Engine (PE) – Uses a trust algorithm based on internal and external data sources to decide whether to grant, deny, or revoke access.
   • Internal sources: Data access policies, security telemetry, IAM rules, SIEM events, Continuous Diagnostics and Mitigation (CDM) tools.
   • External sources: Threat intelligence feeds, vulnerability alerts, risk scoring data.
2. Policy Administrator (PA) – Acts on the Policy Engine’s decision by generating session-specific authentication tokens or credentials and delivering them to the PEP.

Tokens:

• Are valid only for that session
• Can be revoked immediately if the device posture or risk profile changes

---

Why Continuous Verification Matters

A well-integrated PDP continuously evaluates:

• User identity (via IdPs like Azure AD, Okta)
• Device posture (via MDM, EDR, or NAC solutions)
• Location and network context
• Threat intelligence updates

Without continuous verification, Zero Trust risks degrading into a static access control model—which defeats its purpose.

---

Technology-Agnostic by Design

NIST 800-207 intentionally avoids prescribing specific vendor products.

This flexibility allows:

• Tailoring ZTA to unique business requirements
• Using a combination of best-of-breed tools
• Adapting as technologies evolve

---

Conclusion

Zero Trust Architecture, as defined by NIST 800-207, is more than just marketing jargon. It’s a principle-driven, technology-agnostic framework that:

• Eliminates implicit trust
• Continuously verifies every request
• Enforces granular, context-aware policies

In Part Two of this series, we’ll explore different implementation approaches, the technologies behind PDPs and PEPs, and how to design a ZTA tailored to your organization’s needs.