NIST SP 800-207A: zero trust for cloud-native, multi-cloud applications

NIST SP 800-207A ("A Zero Trust Architecture Model for Access Control in Cloud-Native Applications in Multi-Cloud Environments") is a NIST Special Publication, final as of September 2023 and authored by Ramaswamy Chandramouli (NIST) and Zack Butcher (Tetrate), that takes the zero trust principles of NIST SP 800-207 and works out what they mean specifically for cloud-native applications spread across multiple cloud providers and on-premises environments. Its own abstract frames the problem directly: "One of the basic tenets of zero trust is to remove the implicit trust in users, services, and devices based only on their network location, affiliation, and ownership." SP 800-207A's objective, per that same abstract, is "to provide guidance for realizing an architecture that can enforce granular application-level policies while meeting the runtime requirements of ZTA for multi-cloud and hybrid environments."

Why network-location trust isn't enough for cloud-native

The base NIST SP 800-207 model already rejects the idea that being inside a network perimeter should imply trust. SP 800-207A pushes that further for cloud-native applications specifically: per its abstract, "a key paradigm shift in ZTAs is the change in focus from security controls based on segmentation and isolation using network parameters (e.g., Internet Protocol (IP) addresses, subnets, perimeter) to identities." For an application made of many microservices spread across several clouds, a firewall rule keyed to an IP range cannot reliably express "this specific service is allowed to call that specific service" — so the model shifts enforcement to service and application identity instead.

Network-tier policy vs. identity-tier policy

SP 800-207A defines two distinct policy tiers that a zero trust deployment has to reconcile:

Policy tier	Definition (as stated in the publication)
Network-tier	"Allowed communication between enterprise network elements (e.g., firewall rules, which are relatively static)."
Identity-tier	"Access scope for services and resources based on service and user identities (e.g., dynamic application-to-application communication rules based on identities through a dedicated infrastructure layer)."

The document's point is that these two tiers are complementary, not competing: network-tier controls remain a coarse, relatively static baseline, while identity-tier controls carry the dynamic, fine-grained enforcement that cloud-native applications actually need as services scale up, move, and get redeployed across clouds.

The infrastructure the model assumes

Enforcing identity-tier policy consistently across clouds requires specific platform components. Per the abstract, this "requires a platform that consists of Application Programming Interface (API) gateways, sidecar proxies, and application identity infrastructures (e.g., Secure Production Identity Framework for Everyone [SPIFFE]) that can enforce those policies irrespective of the location of the services or applications, whether on-premises or on multiple clouds." The publication's own keyword list names the specific building blocks this implies: ingress gateways and egress gateways (controlling traffic entering and leaving a cluster or cloud boundary), transit gateways, sidecar proxies attached to individual services, and the broader service mesh pattern that ties them together — with SPIFFE providing the cryptographic service-identity layer those components rely on.

How this extends SP 800-207

SP 800-207A does not replace the base zero trust architecture document — it builds on it. Its abstract is explicit that "NIST Special Publication 800-207 has laid out a comprehensive set of zero trust principles and referenced zero trust architectures (ZTA) for turning those concepts into reality," and that SP 800-207A's role is to work out the application-level, multi-cloud specifics that the general-purpose SP 800-207 model does not itself prescribe. Organizations that have already mapped SP 800-207's principles against device or network access (see our SP 800-207 guide) can treat SP 800-207A as the next layer down, specifically for the application and service-to-service traffic running behind those access decisions.

Where this matters for connected devices

Most connected-device and firmware products now depend on cloud backends — fleet management APIs, telemetry ingestion, OTA update services — that are themselves built as cloud-native, multi-service applications. SP 800-207A's identity-tier model gives device and firmware teams a vendor-neutral way to reason about how those backend services should authenticate and authorize each other, independent of which cloud or clouds the backend actually runs on.

SoftWSP's device and firmware security work can help map a connected-device backend's service-to-service access against this model rather than relying on network-location trust alone: see device & firmware security services.

This guide summarises a public NIST publication; it does not constitute legal or compliance advice.