Beyond the Castle and Moat: Deconstructing Canonical Zero Trust Architecture

TL;DR: Zero Trust Architecture (ZTA), as defined by NIST SP 800-207, replaces network location with per-request verification of identity and context. It does this with four logical entities (Subject, Resource, Policy Enforcement Point, Policy Decision Point), and it runs in two domains: North-South (user to application) and East-West (workload to workload). Once you can place every product you run onto those entities and planes, vendor-specific Zero Trust stops looking like a pile of unrelated tools.

🎥 Video Companion: Prefer a visual walkthrough? Watch the companion animated presentation on YouTube: Zero Trust Architecture Explained: NIST SP 800-207 Deconstructed (1m 36s).

Over the past year or so, security incidents across the IT industry seem to have surged, and AI is a big part of the context. I don't have a clean statistic to quote, so I'll only claim what follows from it: attackers can iterate faster than before, and a defense that assumes "the bad guys are outside" has less and less room to be wrong.

I came at this from a quieter angle. My day job is supporting Apigee on Google Cloud, and for a long time I've had the feeling that the product has a lot of Zero Trust ideas built into it. I wanted a reason to sit down and map those ideas properly instead of relying on a vague impression. This is the first of two posts: this one covers the canonical architecture, with no API gateway in it, and the second looks at how Apigee implements the philosophy.

1. The Perimeter Illusion: Why Network Locality No Longer Equals Trust

Zero Trust is a security model in which no request is trusted because of where it comes from; every request is authenticated, authorized, and encrypted based on identity and live context. NIST formalizes it in SP 800-207. The slogan is "never trust, always verify".

The old model was a castle. A firewall and a VPN formed the moat, and once you crossed the drawbridge you could walk into almost any room. That worked while the applications, the servers, and the employees all sat inside the same walls. They no longer do.

1.1 Three structural shifts

1. Applications left the building. Workloads run across multiple clouds and on-prem clusters. There is no single wall to put a firewall on.
2. People left the building. Employees work from home and from cafés, on networks you do not control.
3. Internal traffic exploded. Microservices turned one user request into seven or eight internal calls. Most traffic is now East-West, and perimeter tooling never saw it.

The consequence is lateral movement. If one credential or one container is compromised, an attacker who inherits "inside the network" status can reach everything the subnet can reach.

Figure 1. Same compromised laptop, two architectures. In the perimeter model the blast radius is the whole network; in Zero Trust it is the one resource the policy allows.

1.2 The three principles

These three show up in every source I have read, and each one maps to something you can configure:

An analogy that has held up well for me: a modern office tower with no outer moat. Every elevator, floor, and server-room door wants a badge swipe. The system checks that the badge has not expired, that you are carrying a company laptop, and that your clearance covers this room right now. Being in the lobby earns you nothing.

2. The Canonical NIST SP 800-207 Blueprint: The Four Core Logical Entities

A logical entity in NIST SP 800-207 is a role in the architecture, not a product. One product can play several roles, and one role can be spread over several products. Keeping the roles separate in your head is what lets you reason about a vendor's "Zero Trust solution" without being swayed by its marketing.

There are four entities: Subject, Resource, Policy Enforcement Point (PEP), and Policy Decision Point (PDP). The PDP is itself split into a Policy Engine and a Policy Administrator.

2.1 Subject and Resource: actors are not only humans

• Subject: the initiator of a request. A remote SRE on a laptop is a subject. So is a Kubernetes checkout-service pod, a CI runner, or an autonomous AI agent.
• Resource: the thing being requested. A production PostgreSQL cluster, an internal gRPC payment endpoint, a storage bucket full of customer data.

The point of listing pods and agents is that identity has to exist for them too. A service has no password, so it needs a cryptographic identity of its own. That is the Identity Plane in Section 3.

2.2 The PEP: the muscle with no judgment

The Policy Enforcement Point sits in the traffic path. It intercepts the request, asks for a decision, and carries out the answer: allow, drop, challenge, or terminate the session. It holds no authorization logic of its own.

Think of the turnstile at a station gate, or the guard at a door. The guard does not write the access policy. He obeys a signal from the security office.

Real-life PEPs: an Envoy sidecar next to a pod, a cloud identity-aware proxy in front of an internal web app, a ZTNA connector such as Cloudflare Access.

2.3 The PDP: why NIST splits the brain from the coordinator

The Policy Decision Point lives outside the traffic path and has two parts:

• Policy Engine (PE): the judge. It evaluates the access policy against the inputs and answers one question: can Subject S perform Action A on Resource R under Context C right now? Real-life examples: Open Policy Agent (Rego), AWS Cedar, a context-aware access policy engine in a BeyondCorp-style product.
• Policy Administrator (PA): the clerk who acts on the verdict. When the PE says yes, the PA hands the PEP what it needs to open the path: a session ticket, a short-lived certificate, a token. When the verdict flips to no, the PA tells the PEP to cut the session. Real-life examples: Istio's istiod pushing configuration and certificates to proxies, a ZTNA session broker.

Why separate decision from enforcement at all? Because the data path has to stay fast. The PEP can cache decisions and verify short-lived signed tokens locally, so most requests never wait on the PDP. That is the answer to the "Zero Trust adds latency" objection, and I will come back to it with numbers in the East-West section.

Figure 2. One request through the four entities. The data path (Subject, PEP, Resource) is separate from the decision loop (Administrator and Engine).

3. Mapping Entities to Infrastructure: The Four Zero Trust Planes

A plane is a group of components that share one job in the architecture. The four entities from Section 2 tell you who plays which role. The planes tell you where those roles live in your infrastructure. Splitting them gives four planes: Data, Control, Identity, and Context & Signal.

One note on provenance. NIST SP 800-207 itself speaks of a control plane and a data plane, and lists supporting inputs such as identity management, device monitoring, threat intelligence, and activity logs. Grouping those inputs into an Identity Plane and a Context & Signal Plane is an organizing choice that makes the architecture easier to map onto real systems. It is not a NIST term.

Figure 3. The four planes and the entities they host. Dotted lines are signals flowing to the decision; thick lines are the traffic itself.

3.1 The Data Plane and the Control Plane

The Data Plane carries the actual traffic: Subject to PEP to Resource. Everything in it has to be fast and has to fail safely. Real-life examples: an Envoy sidecar or an eBPF datapath on a node, an identity-aware reverse proxy in front of an internal web app, a ZTNA connector.

The Control Plane is where the PDP lives. It is allowed to be smarter and slower, because it is not in every packet's path. Real-life examples: Open Policy Agent or Cedar evaluating rules, a mesh control plane like istiod distributing configuration and certificates.

If you've worked with Kubernetes, the split will feel familiar: the API server and controllers decide desired state, while kubelet and the container runtime do the work. Same idea, different subject matter.

3.2 The Identity Plane: proof for humans and for machines

Decisions are only as good as the identity behind them. This plane answers "who or what is making the call", cryptographically.

• For humans: an identity provider speaking OIDC or SAML (Okta, Microsoft Entra ID, Google Cloud Identity), with MFA or passkeys.
• For workloads: SPIFFE and its reference implementation SPIRE issue each workload a short-lived X.509 certificate (an SVID) whose identity is a URI such as spiffe://prod.example.internal/ns/finance/sa/payment-processor. SPIRE attests the node first, then the workload (namespace, service account, container), before it hands the certificate over.

The key property for machines is that the identity is not an IP address. A pod can be rescheduled to a new IP and keep the same identity.

3.3 The Context & Signal Plane: turning telemetry into policy input

Authentication says who you are. It says nothing about whether the laptop is patched or the process tree looks like ransomware. This plane feeds live posture and risk into the Policy Engine.

Here is the plane that makes verification continuous. A decision made at 9:00 can be overturned at 9:15 because a signal changed. Section 4 shows exactly that.

4. Operational Domain A, North-South: Replacing the VPN with Context-Aware Access

North-South traffic is the traffic between a person (or an external client) and an application. Zero Trust here replaces the VPN. The user never lands on the corporate network; an identity-aware reverse proxy, acting as the PEP, brokers each connection to one specific application. Real-life examples: Google BeyondCorp Enterprise and Cloud IAP, Cloudflare Access, Zscaler Private Access.

4.1 The trust equation

The Policy Engine's decision can be written as a function of four inputs:

$\text{Access Granted} = f(\text{User Identity}, \text{Device Health}, \text{Contextual Risk}, \text{Resource Sensitivity})$

The same user gets different answers for different resources. Reading a wiki page from a managed laptop may need only a valid session. Opening the production database console may additionally need a hardware-key MFA, a fully patched OS, and a request from an expected region.

4.2 Inside an identity-aware proxy flow

A typical flow looks like this:

1. The user requests an internal app. The proxy (PEP) redirects to the IdP for sign-in and MFA.
2. The proxy asks the decision side whether this identity, on this device, may reach this app. Device posture comes from the Context & Signal Plane.
3. On allow, the proxy strips any identity headers the client sent (so they can't be spoofed) and injects its own signed assertion, a JWT, for the backend to verify.
4. The backend verifies the signature and claims instead of implementing login itself.

Step 3 matters more than it looks. The application stops trusting "whoever reached me" and starts trusting "whoever carries a valid signature from the proxy".

4.3 Continuous verification: revoking a session mid-flight

Here is a hypothetical but realistic timeline:

• 09:00 A developer signs in from a corporate laptop. MFA passes, the EDR reports the device healthy, and the proxy admits the session.
• 09:15 An infostealer runs on the laptop. The EDR flags it.
• 09:15 + seconds The EDR emits a security event. The Control Plane receives it, the Policy Engine re-evaluates, and the Policy Administrator tells the PEP to terminate the session.

The standard for the middle step is the Continuous Access Evaluation Protocol (CAEP), part of the OpenID Shared Signals Framework (SSF). Events are carried as Security Event Tokens (SETs, RFC 8417), which are signed JWTs. A device-compliance-change event looks like this once decoded:

Copy{
  "iss": "https://edr.example.com",
  "jti": "24c63fb56e5a2d77a6956d147f0f9f4b",
  "iat": 1761802500,
  "aud": "https://zt-controller.example.com",
  "sub_id": {
    "format": "email",
    "email": "dev@example.com"
  },
  "events": {
    "https://schemas.openid.net/secevent/caep/event-type/device-compliance-change": {
      "event_timestamp": 1761802497,
      "previous_status": "compliant",
      "current_status": "not-compliant",
      "reason_admin": {
        "en": "EDR: credential-dumping behavior detected"
      }
    }
  }
}

Sample CAEP event (illustrative values). The receiver verifies the signature, matches sub_id to active sessions, feeds the new status into the Policy Engine, and the Policy Administrator revokes.

Event types in the CAEP specification also include session-revoked and credential-change, so the same pipeline handles "this account was disabled" as well as "this device went bad". Check the current SSF/CAEP specs for exact claim names before you build against them; they have been evolving.

Figure 4. The synchronous path (1-2) and the asynchronous revocation loop (A-D).

5. Operational Domain B, East-West: Microsegmentation in a Hostile Internal Network

East-West traffic is the traffic between workloads, such as service to service inside a cluster, VPC, or hybrid environment. There is no human to prompt for MFA. The rule is that an IP address or subnet carries zero authorization weight. Every call must prove which workload is making it, and every receiver checks.

5.1 The problems this model solves

Rather than start with configuration, start with the failures it exists to prevent:

5.2 How it works, in layers

Three layers cooperate, and each covers a gap the others leave open:

• Identity: each workload gets a SPIFFE identity and short-lived certificate (Section 3.2).
• Transport and L7 authorization: a proxy next to each workload, or on each node, terminates mutual TLS, extracts the caller's identity, and checks a policy such as "only checkout-service may POST to /v1/transactions". This is the PEP of the East-West domain. Istio with Envoy is the common example.
• Packet-level isolation: a default-deny network policy at the CNI layer (Calico or Cilium, for instance) drops packets that were never allowed, even if the proxy is bypassed.

Don't rely on only one of them. A mesh without network policy can be sidestepped by a pod that skips the sidecar, and network policy alone cannot tell who is calling.

Here is the analogy for the two deployment styles. A sidecar is a personal bodyguard assigned to every service. Sidecarless designs (Istio Ambient, or eBPF datapaths like Cilium) are more like a smart floor: node-level components handle encryption and identity, and a shared proxy appears only where you need layer-7 rules.

Figure 5. East-West enforcement: mutual TLS between proxies, with a default-deny network layer underneath.

5.3 The latency question

The usual objection is that per-request checks and mTLS must be slow. Two things answer it. Decisions are made from cached policy and local certificate checks, not a round trip to the control plane. And the cost differs sharply by design. My source notes give rough orders of magnitude, which you should treat as indicative rather than a benchmark:

The pattern to take away: keep the check in-process or on-node, and avoid sending every internal call through a remote decision.

---

6. Putting It Together: The Unified Zero Trust Mental Model

Zero Trust is not a single product or binary switch; it is an architectural contract enforced across every boundary. Whether traffic crosses an external internet boundary into an application (North-South) or flows between two internal pods within a cluster (East-West), the underlying logic remains identical: the Policy Enforcement Point intercepts untrusted communication, queries local or control-plane policy, and demands continuous cryptographic proof of identity and posture.

6.1 North-South vs. East-West: The Architectural Comparison Matrix

While the logical entities (Subject, Resource, PEP, PDP) remain constant across both domains, the protocols, latency budgets, and enforcement mechanisms diverge sharply:

6.2 Answering the Skeptics: Three Common Engineering Objections

Whenever an engineering team proposes moving to Zero Trust, three organizational objections predictably emerge. Understanding the architectural mechanics equips you to address each one with precision:

1. The Executive Objection: "We already pay for an enterprise VPN. Why invest in Zero Trust?"

• The Skeptic's Concern: The existing firewall and VPN perimeter seem sufficient, and rebuilding access controls appears redundant and expensive.
• The Architectural Reality: VPNs operate on a coarse, binary assumption: once a client authenticates at the edge, they are placed directly onto the internal network. If an attacker compromises a single developer laptop or steals a VPN session, they gain unfettered network visibility to scan and move laterally across subnets. Zero Trust eliminates network-level admission. Every request to every application requires individual cryptographic authentication and continuous device posture checks, shrinking the blast radius of a compromised machine to only the specific resources that identity is actively authorized to touch.

2. The Developer Objection: "Won't verifying every request and enforcing mTLS destroy our latency?"

• The Skeptic's Concern: Adding cryptographic handshakes and authorization checks to every internal microservice call will degrade application throughput and inflate p99 response times.
• The Architectural Reality: Zero Trust strictly separates the Policy Decision Point (PDP) from the Policy Enforcement Point (PEP). Proxies do not perform remote out-of-process round-trips for every packet. In East-West traffic, Envoy sidecars or kernel-level eBPF datapaths validate incoming calls using locally cached policy tables, pre-negotiated TLS 1.3 session tickets, and dynamic X.509 certificate validation in memory. The measured overhead is under $1\text{ ms}$ for sidecars and under $0.2\text{ ms}$ for modern sidecarless eBPF architectures—well within the latency envelope of distributed systems.

3. The Security & Audit Objection: "Exposing internal applications via reverse proxies makes them more vulnerable than hiding behind a private subnet."

• The Skeptic's Concern: Publishing corporate tools behind internet-facing reverse proxies increases the internet attack surface.
• The Architectural Reality: Behind an Identity-Aware Proxy, backend applications do not listen on public IP addresses or open inbound firewall ports to the internet. Traffic terminates at an edge PEP fronted by DDoS scrubbing and WAF rules. Before an incoming TCP connection or HTTP request can establish a socket to the backend service, the client must satisfy cryptographic mutual TLS, pass IdP authentication with MFA, and meet strict device compliance policies. An unauthorized scanner on the public internet cannot even reach the application layer.

6.3 Frequently Asked Questions (FAQ)

What are the four core logical entities in NIST SP 800-207?

The four core entities are the Subject (the initiating user or workload), the Resource (the target service or data), the Policy Enforcement Point (the inline proxy executing decisions), and the Policy Decision Point (the centralized brain, split into the Policy Engine and Policy Administrator).

How does Zero Trust differ from a traditional VPN?

A VPN grants broad network-level access once a user authenticates at the perimeter, enabling lateral movement. Zero Trust grants per-request access to specific applications based on verified identity and live device health, never placing users directly onto the private network.

What is the difference between a PEP and a PDP?

The Policy Enforcement Point (PEP) is an inline proxy that intercepts traffic and applies decisions without holding authorization logic. The Policy Decision Point (PDP) lives outside the traffic path, evaluating security rules and context to instruct the PEP to allow or terminate sessions.

What is SPIFFE/SPIRE, and why is it used in Zero Trust?

SPIFFE is an open standard providing cryptographically verifiable identity (SVIDs) for workloads rather than relying on IP addresses. SPIRE is its reference implementation, automatically attesting container and node metadata to issue and rotate short-lived X.509 certificates for service-to-service mutual TLS.

Does Zero Trust microsegmentation cause significant latency?

No. Because policy evaluation is decoupled from enforcement, inline proxies verify cached rules and local TLS 1.3 certificates in memory. Native sidecar proxies add under one millisecond, while sidecarless eBPF architectures add less than 0.2 milliseconds of latency.

6.4 The Road Ahead: Where Does the API Gateway Fit?

In this first post, we established the canonical NIST SP 800-207 model: the four entities, the four planes, and the distinct operational realities of North-South and East-West traffic.

Notice what was missing: we haven't touched API management, API products, or consumer credentials yet. In enterprise architectures, pure service meshes govern workload identity and transport encryption, but they know nothing about API monetization, developer quotas, or external partner onboarding. Conversely, public load balancers protect network edges, but lack deep API contract awareness.

In Part 2, we will examine where the API Gateway sits in this landscape:

• How Apigee Hybrid's split-plane architecture directly mirrors the NIST PDP/PEP separation.
• How an Identity Facade terminates external credentials, strips client headers, and mints short-lived internal JWT assertions for downstream microservices.
• How to secure autonomous AI agents using the RFC 8628 Mobile Device Flow to eliminate static secret leaks.
• The architectural boundaries and latency trade-offs between API Gateways and Service Meshes in high-throughput enterprise environments.

---

Sources and References

This article is grounded in the source materials from the project's Zero Trust knowledge base and canonical industry standards:

1. Public Links to Architectural & Component Documentation (from Source Materials)

The following public references, technical guides, and architectural documentation were cited within the underlying knowledge base sources to ground the infrastructure components of Zero Trust (excluding Apigee-specific product links):

• Google Cloud Identity-Aware Proxy (IAP) Public Keys (JWKS) — Google Cloud. The public cryptographic JSON Web Key Set (JWKS) endpoint used by downstream PEPs to verify signed JWT assertions (x-goog-iap-jwt-assertion) in North-South Context-Aware Access pipelines (Section 4.2).
• Google Cloud Web App and API Protection (WAAP) — Google Cloud. Edge reference architecture detailing the integration of Cloud Armor (L7 WAF/DDoS scrubbing) and Identity-Aware Proxy for zero-trust perimeter defense (Section 4.1).
• Envoy Proxy SSL/TLS Security Architecture — Envoy Project. Architecture overview covering mutual TLS (mTLS) configuration, validation contexts, CA root bundle verification, and SAN certificate matching for Data Plane PEPs (Sections 3.1 & 5.2).
• NGINX HTTP SSL Module Documentation — NGINX Documentation. Reference guide for client certificate verification, CA truststore configuration, and mTLS handshakes on reverse proxy PEPs (Section 4.2).
• F5 BIG-IP Client SSL Authentication Architecture — F5 DevCentral. Technical implementation guide for hardware-accelerated client certificate validation and PKI mTLS termination on Application Delivery Controllers (ADCs) in private cloud ingress topologies (Section 4.1).
• Google Cloud Load Balancing Overview — Google Cloud. Documentation on external and internal L7/L4 load balancing topologies used for edge TLS offloading, pass-through mTLS forwarding, and Network Endpoint Group (NEG) routing (Section 4.1).

2. Formal Industry Standards & Specifications Cited

• NIST Special Publication 800-207: Zero Trust Architecture (August 2020) — Scott Rose, Oliver Borchert, Stu Mitchell, Sean Connelly. National Institute of Standards and Technology (NIST). DOI: 10.6028/NIST.SP.800-207. Foundational standard establishing ZTA, formal definitions of PDP, PEP, Policy Engine, Policy Administrator, and the three core tenets (Verify Explicitly, Use Least Privilege, Assume Breach).
• SPIFFE & SPIRE Standards — Cloud Native Computing Foundation (CNCF). Standardized URI schemes, SVID X.509 formats, and platform attestation pipelines. Official Documentation: spiffe.io.
• OpenID Continuous Access Evaluation Profile (CAEP) / Shared Signals and Events (SSF) — OpenID Foundation Shared Signals Working Group. Specification for event-driven asynchronous session management: openid.net/specs/openid-caep-specification-1_0.html.
• RFC 8417: Security Event Token (SET) (July 2018) — P. Hunt, Ed., et al., Internet Engineering Task Force (IETF). Cryptographic JWT profile for security events: rfc-editor.org/rfc/rfc8417.

3. Editorial Context & Author Framing Disclosures

• Author Narrative & Opening Context: The reflections on AI-era cybersecurity incident surges and the author's day job supporting Apigee on Google Cloud represent personal professional commentary provided by the author.
• The "Four Planes" Taxonomy: While NIST SP 800-207 formally specifies the Control Plane and Data Plane (with supporting databases), grouping identity and runtime telemetry into distinct "Identity" and "Context & Signal" planes is an organizing framework adopted from enterprise operational practices to clarify component responsibilities.
• Illustrative CAEP Event Payload: The sample JSON token presented in Section 4.3 is an illustrative payload synthesized from the OpenID CAEP and RFC 8417 specifications for pedagogical clarity; specific production implementations should verify exact claim names against current OpenID schema drafts.