Zero Trust

Zero trust is a security model that grants no implicit trust. Every request must be authenticated and authorized against the resource it targets, no matter which network it arrives from. The perimeter model it replaces trusts whatever is already inside an office network or a VPN. An old industry saying wanted the network to be "like an M&M, with a hard crunchy outside and a soft chewy center". Zero trust is not a product, a firewall, or a WAF feature. NIST describes it as not a single architecture but a set of guiding principles for workflow, system design and operations. Forrester analyst John Kindervag named the model in a September 2010 report. NIST SP 800-207 (August 2020) is the reference document that formalizes it. SP 800-207 separates zero trust, the principles, from a zero trust architecture (ZTA), which is an enterprise's plan for applying them.

How it works

NIST defines zero trust as a collection of concepts and ideas designed to minimize uncertainty in enforcing accurate, least privilege per-request access decisions in information systems and services in the face of a network viewed as compromised. Seven tenets carry it. The tenets that decide how a web property is built are these. Every data source and computing service counts as a resource. Access is granted per session with the least privileges needed to complete the task. Authorization to one resource never automatically grants access to another. All communication is secured regardless of network location, so a request from inside a legacy perimeter must meet the same requirements as a request from any other network. Authentication and authorization are dynamic and strictly enforced before access is allowed. Continual monitoring occurs during a session, with possible reauthentication. Trust is never granted implicitly. It is continually evaluated.

NIST splits the machinery in two. A policy decision point (PDP) rules on each request. A policy enforcement point (PEP) applies that ruling. The PEP sits as close to the resource as it can be placed. The PDP itself divides into two parts. A policy engine makes and logs the grant-or-deny decision. A policy administrator executes it by telling the PEP to open or shut the session.

For traffic routed through a CDN there are two enforcement points. The client-facing edge is the first. It validates a JWT or an identity-provider session before forwarding anything. It can also weigh device posture. The origin is the second. It answers only the CDN, identified by an mTLS client certificate. Alternatively, it holds no public address at all. Requests that pass the edge do reach the origin. What zero trust removes is the unauthenticated path to it, not the traffic.

Why it matters for a CDN

NIST's guidance is to move PDPs and PEPs closer to the resource. A CDN edge is the closest programmable point to the client that is still yours. Every request passes it before the origin sees anything, so an identity or posture check there discards unauthorized traffic while it is still cheap. That check happens off the origin's CPU, off its bandwidth, outside the network entirely. The same edge changes what the origin is. NIST frames zero trust as protecting resources not network segments, as the network location is no longer seen as the prime component to the security posture of the resource. An origin behind mutual TLS with a locked-down firewall is exactly that. It is a resource with one authenticated caller rather than a member of a trusted network.

What CDNs do

Behaviour varies by vendor. Every one of these features is opt-in. Some of them are opt-in per plan.

• Cloudflare Access acts as an identity-aware proxy in front of a web application. It checks each request against Access policies before allowing it through. It uses signals from existing identity providers, device posture providers and other selectors.
• Cloudflare API Shield validates JWTs at the edge. It cryptographically verifies incoming tokens before they reach the origin API. It detects tokens that are expired, tampered with, or not yet valid. It is an API Shield feature rather than a zone-wide default.
• For the origin leg, Authenticated Origin Pulls adds a layer of TLS client certificate authentication. This applies to the connection between Cloudflare and the origin, so HTTPS requests from outside Cloudflare receive no response.
• Cloudflare Tunnel goes further than authenticating the leg. The cloudflared daemon makes outbound-only connections. So the origin needs no publicly routable IP address and no open inbound port. Cloudflare rates it very secure and available to all customers. Cloudflare rates an IP allowlist only moderately secure.
• Akamai Enterprise Application Access delivers access to applications rather than the entire network. Users do not reach applications directly. The apps are hidden from the internet. A dual-cloud architecture closes all inbound firewall ports. It gives authenticated users access only to their own applications.

Watch out for

• Zero trust is not one check at the door. Authorization is per session and continually re-evaluated, so adding a VPN or a single sign-on screen in front of an otherwise flat network does not make the architecture zero trust.
• The decision machinery becomes the trust boundary. NIST warns that a compromised policy administrator could allow access to resources that would otherwise not be approved. NIST also warns that any administrator with configuration access to the policy engine's rules can make unapproved changes. A compromised CDN account is the same failure with a different name. The checks are silently not applied.
• Cloudflare's certificate for global Authenticated Origin Pulls is not exclusive to your account. It guarantees only that a request came from the Cloudflare network. It does not guarantee that the request came from your zone, so another Cloudflare customer's traffic can satisfy it.
• Authenticated Origin Pulls does not apply when the edge-to-origin TLS encryption mode is Off or Flexible. It layers on top of Full or Full (strict) mode instead. Separately, the origin's IP address can leak. Anyone who discovers it can send requests directly. This bypasses the CDN and everything running on it.
• An IP allowlist authenticates a network path, not a caller. Cloudflare rates it only moderately secure. Cloudflare flags it as vulnerable to IP spoofing, so pair it with a certificate or a credential instead of leaning on it alone.
• A public, unauthenticated site cannot demand an identity from every visitor. NIST expects this gap. Most enterprise infrastructures will operate in a hybrid zero trust and perimeter-based mode. Enforce identity on authenticated and privileged paths. Hold anonymous traffic with the WAF and rate limiting.

Best practice

• Authenticate the edge-to-origin leg with mTLS. Use your own certificate at zone or per-hostname level rather than the shared global one. This lets the origin distinguish your CDN traffic from the CDN's other customers.
• Better still, take the origin off the public internet. An outbound-only tunnel or an equivalent broker leaves no inbound port to allowlist and no origin IP to leak.
• Enforce identity at the edge, ahead of the origin. Validate JWTs or identity-provider sessions close to the client. Never leave the origin to adjudicate direct access on its own.
• Grant the least privilege each session needs. Re-check authorization during the session. Do not hand out broad network reach to anyone who authenticated once.
• Treat the CDN as inside your trust boundary. Protect, audit and rotate its account credentials and signing keys. Review policy changes the way you review code.
• Assume the network is already compromised. Monitor the origin for requests that did not come through the edge. Treat any working direct path as an incident.
• Expect a hybrid state and migrate workflow by workflow. NIST calls the transition a journey that cannot simply be accomplished with a wholesale replacement of technology.