The Architecture That Makes It Work

Two Planes, One Model

The foundational concept in Zero Trust Architecture comes from NIST SP 800-207, and it starts with a clean separation between two planes.

The Control Plane manages decisions. It's where policy is defined, evaluated, and enforced. Nothing in your environment should get access without passing through the control plane first.

The Data Plane carries traffic. This is where the actual communication between users, devices, applications, and data happens. The data plane executes the decisions made by the control plane.

The critical implication: the control plane must be able to intercept and evaluate every access request before it reaches the data plane. If traffic can flow without touching the control plane, you have a gap in your Zero Trust architecture.

The Core Components

Policy Decision Point (PDP) - The brain of the architecture. It evaluates access requests against defined policy and makes a binary decision: allow or deny. The PDP receives identity claims, device posture, request context, behavioral signals, and threat intelligence as inputs.

Policy Enforcement Point (PEP) - Sits between the requestor and the resource, enforcing whatever decision the PDP issued. PEPs can take multiple forms: a network proxy, an API gateway, an application-layer agent, or an identity-aware load balancer. The key property: the PEP doesn't make trust decisions on its own. It enforces them.

Policy Administration Point (PAP) - Where policies are created and managed. Security teams define rules here: who can access what, under what conditions, and with what constraints.

The Identity Fabric

Identity is the primary control variable in Zero Trust. Where legacy security asked "is this traffic coming from inside the network?" Zero Trust asks "who is making this request, and can that identity be verified?"

A mature identity fabric includes:

Component	Role
Identity Provider (IdP)	The authoritative source of user identity. Modern environments consolidate on a cloud IdP that manages the full identity lifecycle.
Multi-Factor Authentication (MFA)	The minimum bar for any Zero Trust implementation. Passwords alone are insufficient. MFA should be enforced universally.
Continuous Authentication	Beyond the initial login event, behavioral signals should continuously validate the entity accessing a resource. Anomalies should trigger step-up authentication or session termination.
Non-Human Identities	Service accounts, API keys, deployment pipelines, and AI agents all have identities that must be managed with the same rigor as human users. This category is growing fast.

Device Trust

In Zero Trust, identity isn't just about the user - it's about the user-device combination. Device trust evaluation involves:

• Device registration and inventory
• Compliance checks (OS patches, endpoint protection, encryption)
• Certificate-based device authentication
• Continuous risk scoring

Network Microsegmentation

Traditional network security divided the network into trusted inside and untrusted outside. Microsegmentation divides the network into small, isolated zones where communication between segments requires explicit authorization. The goal is lateral movement prevention.

Three approaches exist:

Approach	How It Works	Best For
Network-based	VLANs, SDN	Traditional data center environments
Host-based	Firewall rules at the workload level	Cloud-native workloads
Application-layer	Service mesh (Istio, Linkerd)	Microservices architectures

Zero Trust Network Access (ZTNA)

ZTNA replaces VPN for application access. Where VPN grants broad network access, ZTNA grants access to specific applications based on identity and device posture - without exposing the network layer at all. The user never gets direct network access to the application's host, eliminating several attack classes.

Common Architecture Mistakes

Treating identity as a solved problem. Standing up an IdP and enabling MFA is the start, not the finish.

Ignoring east-west traffic. Most investments focus on north-south traffic (users accessing applications). East-west traffic (service-to-service) is often left uncontrolled - which is exactly where lateral movement happens.

Bolting monitoring on at the end. Build logging and analytics in from the beginning.

Creating too many exceptions. Each exception is a hole in the architecture. Track them explicitly and close them on a schedule.

Letting vendor lock-in drive architecture. Architect around standards (SAML, OIDC, mTLS, FIDO2) and treat vendors as implementation details.