NIST Cloud-Native Security Series: SP 800-204, 800-210 and 800-215 in Practice

NIST has published a whole shelf of cloud-native security guidance, but it is spread across nine Special Publications written over five years, and most teams only ever read one of them. The SP 800-204 series covers microservices, service meshes, DevSecOps pipelines and software supply chain security; SP 800-210 covers access control across IaaS, PaaS and SaaS; SP 800-215 covers the enterprise network once the perimeter has gone; and SP 800-207A and SP 800-233 sit alongside them. This guide maps the set, explains what each document actually asks for, and shows how to turn the numbered recommendations into a working control set. It is for cloud architects, platform and DevSecOps teams, and assessors who need to cite the right document. Microservices design itself is covered in the Microservices Security Guide, so this page concentrates on the parts of the series that guide does not cover.

Source note: publication titles, dates and section references are from the NIST CSRC pages and PDFs cited below, as at November 2026. Confirm against the official text before relying on it.

Key takeaways

• Read the series as layers, not alternatives. 800-210 sets access control by cloud service model, 800-215 sets the network landscape, the 800-204 series and 800-207A set application and service mesh controls, and 800-204C and 800-204D cover how code reaches production.
• All are guidance, none is a control catalogue. They give recommendations with identifiers such as PULL-PUSH-REQ-3 or HAE-NCF-2, not SHALL statements; map them to SP 800-53 controls when you need assessable requirements.
• 800-204C treats five kinds of code as pipelines. Application code, application services (mesh) code, infrastructure as code, policy as code and observability as code each get a CI/CD pipeline, and NIST highly recommends pull-based GitOps over push-based deployment.
• 800-204D makes provenance enforceable. Signed attestations for environment, process, materials and artifacts, plus a signed policy that says what a deployable artifact must prove.
• Identity runs through every document. Workload identity (SPIFFE is cited in 800-215), phishing-resistant user authentication at AAL3, OAuth 2.0 tokens for cloud applications and attribute-based access control recur across the series.

The series at a glance

Status and dates below were checked on the NIST CSRC publication pages in November 2026. All are final; none of the pages lists a newer revision.

SP 800-204, 204A and 204B are covered in depth in the Microservices Security Guide and the Service Mesh Security Guide, and 800-207A has its own NIST SP 800-207A Zero Trust for Cloud-Native Applications Guide. The sections below focus on 800-210, 800-215, 800-204C and 800-204D.

SP 800-210: access control by service model

SP 800-210 starts from the NIST SP 800-145 cloud characteristics and explains why each complicates access control: broad network access widens exposure, resource pooling risks leakage between tenants through co-located resources or unwiped memory, rapid elasticity means new virtual machines must be verified quickly, and measured service means consumers should be able to read but not alter metering data. Its central idea is that the service models are hierarchical: IaaS guidance also applies to PaaS and SaaS, and PaaS guidance also applies to SaaS.

Section 6 adds inter-operation and intra-operation: access between a consumer's virtual machines should be enabled only for the collaboration period and then disabled, and inconsistent subject attributes across providers can grant unintended permissions. That is the multi-cloud attribute mapping problem that federation designs must solve; see Cross-cloud workload identity federation. The publication's appendix maps its guidance to SP 800-53 access control controls (AC-3, AC-4, AC-5, AC-6, AC-17, AC-21), using Rev. 4 identifiers that remain present in Rev. 5.

SP 800-215: the enterprise network without a perimeter

SP 800-215 defines the enterprise network as cloud virtual networks, on-premises networks and the WAN segments joining them, and argues that perimeter firewalls, VPNs and MPLS no longer fit. It notes that most traffic is now east-west, that VPNs hair-pin cloud traffic through the corporate edge, and that user tokens alone are not enough for microservices, which also need portable cryptographic workload identities that are validated continuously.

Its numbered recommendations are short enough to adopt directly:

For microsegmentation, 800-215 compares segment-based, virtualised server-based, host-based and identity-based approaches, and points to identity-based segmentation (policies tied to service identities with mutual authentication, suited to policy as code) as the approach that survives workload movement. It then covers software-defined perimeter, SD-WAN and SASE. Practical design for those is in the Network Segmentation Guide and the SASE and SSE Guide.

SP 800-204C: DevSecOps for five kinds of code

800-204C's most useful idea is that a cloud-native application is not one codebase but five, each needing its own pipeline and its own checks:

• Application code: business logic, protected with SAST, secret detection, SCA and DAST.
• Application services code: the service mesh configuration for discovery, routing, resilience and security.
• Infrastructure as code: scanned before merge into the GitOps repository, with drift detection after deployment and during runtime.
• Policy as code: zero trust and authorisation rules, periodically rescanned against current threats.
• Observability as code: logging, tracing and monitoring configuration.

The document recommends stopping the pipeline on build, test or audit failure, keeping developers to application code only, multi-party signing of artifacts with verification before production release, and scanning service mesh configuration for problems such as information leakage in authorisation policies. On workflow, it describes push-based deployment as insecure because CI scripts run outside the deployment trust domain and CD tools hold production keys, and highly recommends the pull-based GitOps model where an in-cluster operator pulls changes. It also links DevSecOps evidence to continuous authority to operate. See the GitOps Security Guide and the CI/CD Security Guide.

SP 800-204D: supply chain controls in the pipeline

800-204D adds the integrity layer. Its two goals are to defend the CI/CD pipeline and build process, and to ensure the integrity of upstream sources and artifacts. It deliberately does not prescribe SBOM or attestation formats, so pair it with a format such as SLSA provenance (see the SLSA and Build Provenance Guide).

The attacks this targets are not theoretical. The tj-actions/changed-files compromise leaked CI/CD secrets from thousands of repositories through a poisoned third-party action, and the Codecov breach turned a modified CI script into a secrets harvester; trusted-source checks and attested inputs are exactly what 800-204D asks for.

How to implement the series

1. Scope and baseline: list which documents apply (800-210 for every cloud tenancy, 800-215 for the network, the 204 series where you run microservices or a mesh) and record current state against each numbered recommendation.
2. Identity first: enforce HAE-NCF-2 (enterprise identity provider, phishing-resistant MFA) and issue workload identities before writing segmentation policy, because identity-tier rules need identities to refer to.
3. Pipelines second: split pipelines by the five 800-204C code types, add stop-on-failure gates, and move production deployment to pull-based GitOps.
4. Attest and gate: generate build attestations, then enforce DEPLOY-REQ-3 and 4 at admission in audit mode for one release cycle before switching to blocking (see the Kubernetes Admission Control Guide).
5. Segment by identity: roll out identity-based segmentation one namespace or service group at a time in permissive mode, then enforce. Roll back by reverting the policy commit in Git, which GitOps makes a single change.
6. Tie to authorisation: map the evidence to SP 800-53 controls so assessors can use pipeline outputs for continuous monitoring.

Decision guidance

• Which document to start with: if you have no service mesh, start with 800-210 and 800-215; the 204 series assumes containers on an orchestration platform.
• Mesh or no mesh: 800-204C argues that Kubernetes alone lacks pod-level identity-based access control and mTLS. If you adopt a mesh, use SP 800-233 to choose a data plane model against your risk profile.
• Small teams: prioritise 800-215's identity recommendations and 800-204D's secret scanning and sandboxed pull requests, which are cheap and high value.
• Regulated and federal estates: use 800-204C and 204D evidence to support continuous authorisation, alongside the FedRAMP Guide where FedRAMP applies.

Where identity fits

Most recommendations in the series are identity controls in disguise: workload identities for every service, short-lived tokens, OAuth scopes per application, signing keys for artifacts, and pipeline credentials kept out of developers' reach. These are non-human identities, and they need owners, rotation and inventory. See the Cloud Workload Identity Guide, the SPIFFE and SPIRE Guide and the CI/CD Pipeline Identity Security Guide.

Detection and measurement

• Percentage of production deployments with a verified build attestation and recent scan evidence.
• Percentage of service-to-service traffic covered by identity-tier policy in enforcing mode.
• Drift events detected per month between Git and running clusters, and median time to resolve.
• Percentage of user access routed through the enterprise identity provider with phishing-resistant MFA.
• Pipelines that run untrusted contributor code with secret access (target: zero).

Log control plane API calls (800-210 Section 3.4), admission decisions, pipeline approvals and signing events, and alert on deployments that bypass the GitOps operator.

Framework mapping

800-204D's own appendix maps its recommendations to SSDF practices; see the NIST Secure Software Development Framework (SSDF, SP 800-218) Guide. CIS Controls v8.1 Control 16 (Application Software Security) and Control 12 (Network Infrastructure Management) cover similar ground at control level, and ISO/IEC 27001:2022 A.5.23 (information security for use of cloud services), A.8.22 (segregation of networks) and A.8.25 (secure development life cycle) are the closest Annex A controls.

Common failure patterns

• Citing 800-204 for everything: teams reference the original 2019 document and miss the pipeline and supply chain requirements added in 204C and 204D.
• Push-based deployment with production keys in CI: exactly the model 800-204C calls insecure; a compromised CI job becomes a compromised cluster.
• Running fork pull requests with secrets: breaks PULL-PUSH-REQ-3 and is how many CI secret thefts start.
• IaC scanned but never compared to runtime: drift goes unseen because manual kubectl changes are allowed.
• Attestations generated but not enforced: provenance exists, but no admission policy checks it.
• Inconsistent attributes across clouds: the 800-210 inter-operation problem, where the same role name means different rights in each provider.

Practitioner checklist

• Record which of the nine publications apply to each environment and who owns each.
• Assess current state against HAE-NCF-1 to 5 and the 800-204D REQ identifiers.
• Split pipelines by the five code types and stop on any build, test or audit failure.
• Move production deployment to a pull-based GitOps operator and remove production keys from CI.
• Sandbox outside contributor workflows with no secret or network access.
• Generate signed build attestations and enforce them at admission.
• Issue workload identities and roll out identity-based segmentation in permissive, then enforcing, mode.
• Log and review cloud control plane access control API calls.
• Map evidence to SP 800-53 controls for continuous monitoring.

Standards and references

• NIST: SP 800-210 General Access Control Guidance for Cloud Systems
• NIST: SP 800-215 Guide to a Secure Enterprise Network Landscape
• NIST: SP 800-204C Implementation of DevSecOps for a Microservices-based Application with Service Mesh
• NIST: SP 800-204D Strategies for the Integration of Software Supply Chain Security in DevSecOps CI/CD Pipelines
• NIST: SP 800-204 Security Strategies for Microservices-based Application Systems
• NIST: SP 800-204A Building Secure Microservices-based Applications Using Service-Mesh Architecture
• NIST: SP 800-204B Attribute-based Access Control for Microservices-based Applications using a Service Mesh
• NIST: SP 800-233 Service Mesh Proxy Models for Cloud-Native Applications

Related NHI Mgmt Group resources: Microservices Security Guide · NIST SP 800-207A Zero Trust for Cloud-Native Applications Guide · NIST SP 800-190 Container Security Guide · Service Mesh Security Guide