What Is NIST 800-190? Definition & Examples

NIST 800-190 is the U.S. guidance document for application container security. It frames container risk across build, deployment, runtime, and host layers, helping teams understand where controls should be applied. The guidance is commonly used to structure hardening, monitoring, and governance for containerized workloads.

What NIST 800-190 Is Used For

NIST SP 800-190 gives teams a practical way to think about container security as a layered problem, not a single control point. It is most useful when you need to map responsibilities across image build, registry handling, orchestration, host configuration, and runtime enforcement.

That layered view matters because container risk often appears in the seams, for example when an image is trusted too early, a deployment policy is too permissive, or runtime isolation is weaker than the workload assumes. NIST 800-190 helps practitioners decide where to put controls rather than treating the container platform as inherently secure.

Container Security Boundaries and Control Layers

The guidance is built around the idea that container environments have multiple trust boundaries. Build-time controls help reduce supply-chain exposure, deployment controls shape what reaches the cluster, runtime controls limit what a running container can do, and host-layer controls reduce the blast radius if a container is compromised.

That structure is important because a weakness in one layer can undermine the others. A hardened image does not compensate for unsafe orchestration settings, and strong cluster policy does not fully offset a host that is misconfigured or overexposed.

For teams using IAM and IGA Basics, the same control logic applies at different scopes: who or what can deploy, what it can access, and how privilege is reviewed over time.

Why NIST 800-190 Still Matters in Modern Cloud-Native Environments

Container platforms change quickly, but the security questions remain consistent: what is trusted, what is isolated, and what happens when trust fails. NIST 800-190 remains relevant because it is focused on operational control points, not on any single vendor implementation or orchestration product.

It is especially helpful when teams are standardising security across many workloads, because it gives a shared vocabulary for image hygiene, registry trust, runtime confinement, and host hardening. That makes it easier to separate platform risk from application risk and to assign ownership clearly.

For policy and access design, Authorisation Models Guide provides a useful companion view on how permissions and policy decisions should map to container operations.

Typical Failure Modes and Security Implications

The main failure pattern in container security is not usually one dramatic flaw, but a chain of small assumptions: a vulnerable image, overly broad orchestration permissions, exposed management interfaces, weak network segmentation, or a container runtime that can reach more of the host than intended. NIST 800-190 is useful because it encourages teams to think about these as connected weaknesses.

Another common issue is drift between build assumptions and production reality. If an image is scanned once but not governed after release, or if runtime restrictions are defined but not enforced consistently, the container may end up carrying far more risk than the original design intended.

From a defensive standpoint, NIST SP 800-190 Container Security is often used alongside host, orchestration, and monitoring controls so that compromise in one layer does not become full platform compromise.

How Practitioners Should Interpret the Guidance

NIST 800-190 should be read as a control-architecture guide, not as a checklist that makes containers secure by itself. The practical takeaway is to use it to assign ownership across build pipelines, platform operations, and runtime monitoring, then validate that those responsibilities are actually enforced in production.

Zero Trust Identity Guide is a useful mental model here because container security improves when trust is continuously verified rather than assumed at deployment time. In practice, that means the platform should be able to constrain privilege even when a workload is already running.

Practitioner takeaway: treat NIST 800-190 as a way to distribute container security across the full lifecycle, not as a single hardening document for the cluster alone.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

NIST SP 800-53 Rev 5 provides the primary governance reference for this term.

Framework	Control / Reference	Relevance
NIST SP 800-53 Rev 5	SC-28 — Protection of Information at Rest	Container images, layers, and persisted secrets often require storage protection controls.
	SI-3 — Malicious Code Protection	Container images and runtime content need scanning and malicious-code detection.
	AC-6 — Least Privilege	Container orchestration and runtime permissions should be restricted to the minimum required.
Recommendation — Protect stored container artifacts and sensitive data with approved encryption and access controls. Scan container images and runtime content for malicious code before deployment and during operation. Reduce container and orchestration privileges to the minimum needed for each workload.

NIST 800-190