The principle: never trust, always verify

Zero Trust (ZT) is, per NIST SP 800-207, a set of security paradigms that moves the defense away from static, network-based perimeters and focuses instead on users, assets, and resources. The central principle: there is no implicit trust based solely on physical or network location. A request from your own data center, i.e. from inside a classic perimeter, must meet the same security requirements as a request from the open internet.

NIST states seven basic tenets. The ones most relevant to APIs:

  • All communication is secured regardless of network location. Location alone does not establish trust; confidentiality, integrity, and source authentication must always be established.
  • Access is granted per session, with the least privilege possible. Authorization for one resource does not automatically grant access to another.
  • Access follows a dynamic policy, which includes the observable state of identity, application, and requesting asset, supplemented with behavioral and environmental attributes.

For APIs, the consequence is direct: it's not enough to authenticate once at the entrance and then trust everything inside the internal network afterward. Every single API call carries its identity with it and is checked against policy.

AspectNIST SP 800-207CISA Zero Trust Maturity Model v2.0
RoleAbstract architecture and principlesMaturity framework for implementation
Core structureLogical components PE, PA, PEPFive pillars plus three cross-cutting capabilities
Pillars / componentsPE, PA, PEP along control and data planeIdentity, Devices, Networks, Applications and Workloads, Data
StagingThree deployment variants (incl. microsegmentation)Four maturity levels: Traditional, Initial, Advanced, Optimal
OriginNIST, USA, 2020CISA, USA, aligned with OMB M-22-09

NIST SP 800-207 and CISA ZTMM compared

Identity per request and default-deny

From the NIST principles follows a clear enforcement pattern for APIs: identity per request instead of trust per network segment. Every call carries a verifiable proof of identity with it, for example an OAuth 2.0 access token (often a JWT) or a client certificate. Authorization is re-evaluated on every request, not just at initial login.

The second consequence is default-deny: whatever is not explicitly permitted is rejected. This principle aligns with the OWASP recommendation against Broken Function Level Authorization (BFLA, API5:2023): the enforcement mechanism should deny all access by default and allow only explicitly granted roles per function (deny all access by default, requiring explicit grants).

Zero Trust therefore doesn't replace authorization in the application, it demands it consistently. Important: a valid token only proves who is calling, not whether this identity is currently allowed to access this specific object. Object-level checking (against BOLA, API1:2023) remains the service's responsibility and belongs in its business logic.

Policy enforcement point at the gateway: PE, PA, PEP

NIST SP 800-207 breaks a Zero Trust architecture down into logical core components, separated into control plane and data plane:

  • Policy Engine (PE): makes the actual access decision. It evaluates enterprise policy plus external signals (e.g. threat feeds) via a trust algorithm and grants, denies, or revokes access.
  • Policy Administrator (PA): establishes or tears down the communication path between subject and resource, generates session-specific tokens, and controls the PEP according to the PE's decision.
  • Policy Enforcement Point (PEP): enables, monitors, and terminates the connection between subject and resource. It is the place where the decision is actually enforced.

For APIs, the API gateway is the natural place for the PEP on north-south traffic: it terminates TLS, checks authentication, and enforces coarse-grained policies per request before it reaches a backend. The division of labor is decisive: the gateway as PEP intercepts at the perimeter, but fine-grained, object-level authorization (BOLA) is still decided by the service. A gateway PEP is necessary but not sufficient, a point where Zero Trust and the layered model of API security converge.

Microsegmentation and mTLS between services

NIST names microsegmentation as one of three implementation variants of a Zero Trust architecture: individual resources, or small groups of related resources, sit behind their own gateway security component, which acts as a PEP and grants access dynamically per request. Instead of one flat, trusted internal network, many small, individually controlled zones emerge, so that a compromised service cannot automatically move laterally to others.

In east-west traffic, i.e. communication between services themselves, the principle all communication is secured is typically implemented via mTLS (mutual TLS). Unlike one-way TLS, both sides authenticate via certificate, so each service gets a cryptographic workload identity. In service mesh architectures (e.g. via sidecar proxies), mTLS is often enforced transparently to the application.

  • TLS 1.3 (RFC 8446) is the transport foundation for encrypted, integrity-protected connections.
  • OAuth 2.0 Mutual-TLS (RFC 8705) additionally binds access tokens to the client certificate (certificate-bound access tokens), so a stolen token is useless without the matching private key.

This creates a continuous thread of identity: from the external client through the PEP at the gateway to the authenticated service-to-service connection.

CISA Zero Trust Maturity Model: the five pillars

Where NIST SP 800-207 describes the abstract architecture, the CISA Zero Trust Maturity Model (ZTMM, version 2.0, aligned with OMB M-22-09) provides a maturity framework for step-by-step implementation. It's organized into five pillars and three cross-cutting capabilities.

The five pillars:

  1. Identity
  2. Devices
  3. Networks
  4. Applications and Workloads, which includes APIs and their services
  5. Data

Crosscutting these are three capabilities: Visibility and Analytics, Automation and Orchestration, and Governance. Every pillar goes through four maturity levels: Traditional, Initial, Advanced, and Optimal. This lets Zero Trust be treated not as all-or-nothing but as a measurable path, along which, for instance, an API landscape matures from static, perimeter-based controls toward per-request authorization and automated policy enforcement.

Scope and limits

Zero Trust is an architectural principle, not a product. NIST stresses that no single component constitutes a complete ZTA, it results from the interplay of PE, PA, and PEPs along consistently enforced policies. The BSI also lists Zero Trust as a recommendation for government agencies and enterprises.

Important boundaries for practice:

  • Zero Trust does not replace application logic. The PEP at the gateway checks identity and coarse policy; object-level authorization (BOLA) and function-level authorization (BFLA) must still be enforced within the service.
  • mTLS secures the transport and workload identity, but does not make a business-level authorization decision about individual records.
  • Maturity, not a switch. Implementation proceeds step by step along the CISA pillars, not in a single migration step.

NIST also names risks of its own for a ZTA, such as compromise of the decision process (PE/PA) or denial-of-service against the PEP: whoever routes all access through a central enforcement point must secure its availability and integrity with particular care.

Sources

Keep reading
EnforcementAPI Gateways as Policy Enforcement Point AuthorizationBroken Function Level Authorization IdentityAPI Authentication