NIST 800-53 for Kubernetes: what CM-6 requires

How NIST 800-53 applies to containers and Kubernetes

When a contract, agency or regulator requires NIST SP 800-53 for a platform that runs containers on Kubernetes, the organization owns its controls, its cluster configuration and the evidence those settings produce. An independent assessor is the only party that issues a conclusion on whether the controls are met. An implementation partner can prepare the clusters, the policies and the evidence pipeline, but neither the partner nor the scanner output is an assessment result. The answer depends on four variables. The first is the impact baseline, since SP 800-53B selects different controls and enhancements for low, moderate and high systems, and CM-6 enhancements (1) and (2) apply in the high baseline only. The second is the number of clusters, because each cluster needs its own baseline configuration and deviation records. The third is whether the platform is self-hosted or run by a cloud provider, which decides how much of the control set is inherited from the provider and how much stays with the organization. The fourth is how mature the evidence pipeline is, meaning whether scan results, admission decisions and configuration checks are collected automatically or assembled by hand before each assessment.

NIST SP 800-190, *Application Container Security Guide*, dates from September 2017 and explains container-specific risks, including those introduced by orchestrators. It predates the Release 5.2.0 update of 27 August 2025, so teams should check its guidance against the current control text in the CPRT or OSCAL catalog. NIST does not publish a cost or timeline for this work, and NIST's risk management FAQ states that it does not estimate compliance costs. Teams should ask any partner for a written scope that names the clusters, the baseline, the managed services in use and the evidence each control will produce, and should confirm with their assessor which evidence format and sampling approach they will accept before the work starts.

Which SP 800-53 controls a container platform is usually tested against

Assessors reviewing a container platform tend to focus on a small set of control areas that touch the cluster, the images it runs and the network around it. The cards below describe what each area asks for and what evidence usually satisfies it. Exact enhancements depend on the baseline selected in SP 800-53B, so confirm scope with your assessor before you build evidence.

Configuration settings under CM-6

CM-6 asks the organization to define and document secure configuration settings for system components, implement them, and record any approved deviations. For a cluster, this means a written hardened baseline for the control plane, nodes and workloads, plus a record of who approved each exception. Evidence usually includes the baseline document, scan reports showing drift against it, and approved deviation records. Check whether your baseline selects the automated management enhancements from CM-6(1), which apply only at the high baseline.

Baseline configuration and inventory

CM-2 requires a documented baseline configuration, and CM-8 requires an inventory of system components. In a container environment, the inventory must cover clusters, namespaces, node pools, base images and running workloads, not just virtual machines. Assessors often ask how the inventory stays current when pods are created and destroyed continuously. Evidence can include exported cluster state, image digests tied to deployed workloads and a reconciliation record between the declared baseline and the live environment.

Flaw remediation and vulnerability scanning

SI-2 covers flaw remediation, and RA-5 covers vulnerability monitoring and scanning. Both apply to base images, language packages, the Kubernetes version and the node operating system. Assessors typically look for scan results on images before deployment, a defined remediation timeline and records showing that vulnerable images were rebuilt or replaced. Confirm with the assessor how scan coverage is defined for images in registries versus images running in clusters, because each may need its own evidence.

Access control and audit logging

The AC family governs who can reach the cluster API, how roles are granted and how privileged access is limited. The AU family governs which events are logged, how records are protected and how they are reviewed. For Kubernetes, the evidence is usually role bindings exported from the cluster, service account reviews, API server audit policy and log records showing administrative actions. Confirm which AC and AU enhancements your baseline requires, since they differ between low, moderate and high.

Boundary and communications protection

The SC family covers boundary protection, network segmentation, transmission protection and cryptographic key management. In a cluster, assessors examine network policies that isolate namespaces, ingress and egress controls, encryption of traffic between services and how certificates and keys are issued and rotated. Evidence commonly includes policy manifests stored in version control, test results showing that unauthorized traffic is blocked and key management records. Confirm with your assessor which SC controls apply to the cluster boundary and which sit with the cloud provider.

What CM-6 asks for in a cluster and how to evidence it

CM-6 asks the organization to set configuration settings for its system components at the most restrictive mode that still meets operational needs, to document those settings as a defined set of common secure configurations, to implement them, to record and approve any deviation, and to monitor and control changes to the settings. In a Kubernetes cluster the components in scope include node operating system settings such as kubelet arguments and kernel parameters, API server and controller manager flags, admission configuration, pod security settings and namespace-level policies. The control does not name Kubernetes. The organization must decide which settings form its baseline, write that baseline down, and show that the running cluster matches it. Start by listing each component type, its owner and the settings the organization treats as security-relevant, then assign a documented approver for every exception.

Evidence for CM-6 is usually a set of artifacts that tie a written baseline to observable cluster state. The baseline document lists the settings and the rule each one must meet. Machine-checkable versions of those rules can run against nodes and the control plane, and ComplianceAsCode content, which NIST-aligned guidance points to as a source of rules for Kubernetes and OpenShift, is one place to find them. Scanner output from tools such as Trivy, which reports misconfigurations in Kubernetes clusters, and admission policy definitions in Kyverno, which can deny or report resources that break the baseline, show how the baseline is enforced. Keep the approved deviation register, the change records that touch these settings and the admission audit results together. Confirm with your assessor which of these artifacts they will accept as evidence for your environment before you build the set.

CM-6(1) (automated management, application, and verification) and CM-6(2) (respond to unauthorized changes) are selected only in the high baseline under SP 800-53B Release 5.2.0. A cluster that falls under a moderate or low baseline is not required to select them, but many teams automate verification anyway because drift detection and admission enforcement make the manual evidence cheaper to keep current. If your system is categorized as high, confirm the exact enhancement language and the expected automation level with your assessor, and plan for alerting and response to unauthorized changes to node, control plane and namespace settings. Check the NIST CPRT entry for CM-06 to confirm the current wording before you write it into your plan.

Which checks fit self-hosted Kubernetes, OpenShift and EKS

On clusters you run yourself, ComplianceAsCode is the open-source content source to evaluate first. It began in 2011 as the SCAP Security Guide, was renamed in September 2018, and publishes security policy content for the platform and the hosts beneath it. For the cluster itself, its content is delivered as CEL rules that the compliance-operator evaluates on Kubernetes and OpenShift. The underlying nodes are covered by separate content for RHEL, Fedora, Ubuntu, Debian and SUSE, delivered as SCAP source data streams (XCCDF and OVAL), Ansible playbooks and Bash scripts.

Cluster rules: CEL rules evaluated by the compliance-operator report results against the cluster configuration.
Host content: SCAP data streams, Ansible and Bash cover the operating system on each node, which is a separate scope from the cluster.
Remediation: Ansible playbooks and Bash scripts can apply settings, but each change should go through your change control process before it runs.
Deviations: Findings you accept as deviations under CM-6 need documented approval and a review date, which the scanner does not provide.
Coverage: Confirm which rules match your Kubernetes or OpenShift version and your host operating system in the ComplianceAsCode/content repository.

Before relying on a result, check that the content version matches your platform and that you can export results for the assessor.

Which open-source tool produces which container evidence

This table compares four tools against the evidence each can produce for NIST SP 800-53 container and Kubernetes controls, where each runs and when it fits. Read each row as a record source that feeds an assessor's review, not as a finding that decides compliance. Confirm each tool's coverage against your own control selection before relying on its output.

Tool	Evidence it can produce	Where it runs	When it fits
Trivy (Apache-2.0)	Image and cluster scan reports for known vulnerabilities, infrastructure as code misconfigurations, exposed secrets and software licenses	CI pipelines, image registries, and against live Kubernetes clusters	Supports vulnerability monitoring and scanning evidence for RA and SI flaw remediation records, once scan frequency and triage are documented
Kyverno (Apache-2.0)	Admission policy records showing which resources were validated, mutated, generated or removed, plus image verification results and CLI scan output	Inside the cluster as an admission controller, and as a CLI run from a pipeline or workstation	Supports configuration enforcement evidence for CM-6 and CM-7 when policies map to the organization's approved settings and deviations are recorded
ComplianceAsCode with the compliance-operator	SCAP source data streams, OVAL and XCCDF results and CEL rule outcomes for cluster and node configuration, produced on a scan schedule	Kubernetes and OpenShift clusters through the compliance-operator, which applies content built from the ComplianceAsCode repository	Suits teams that need a compliance-oriented baseline scan of nodes and cluster settings and want output in formats assessors can read
AWS Security Hub CSPM (NIST SP 800-53 Rev. 5 standard)	Automated control check findings for certain AWS services, including EKS-related checks, with status history in the Security Hub console	Within the AWS account and Region where Security Hub CSPM is enabled	Fits EKS accounts where the cloud provider checks are the primary record; AWS states the controls do not cover manual requirements and recommends enabling AWS Config resource recording first
Coverage check (all four tools)	Mapping of each tool's checks to the control IDs the organization selected, with gaps listed	Documented in the system security plan and assessment workpapers	Required before any tool output is cited as evidence, because a tool produces records and does not decide whether a control is met

How a container control assessment moves from scope to evidence

This sequence takes a containerized platform from an agreed boundary to an evidence package that an independent assessor can test against SP 800-53A procedures. The organization owns each control, the implementation partner prepares systems and evidence, and only the independent assessor reaches a conclusion on the results.

Define the assessment boundary
The organization and the implementation partner list every cluster, namespace, image registry, build pipeline, CI runner, secrets store and administrative workstation that touches the system in scope. They also record which components are shared platform services and which belong to a single application. The output is a signed boundary statement with a component inventory, and it is done when the organization confirms that nothing processing in-scope data sits outside it. Ask the partner to write the phase durations into the fixed-scope proposal.
Select the impact baseline
The organization assigns an impact level to the information the boundary handles and uses SP 800-53B to select the low, moderate or high baseline, plus any privacy baseline that applies. Each baseline selection is then tailored to the container platform, which may add or remove controls based on documented risk decisions. The output is a baseline selection record that lists every control and enhancement in scope, and it is done when the control owner for each item is named. Confirm with the assessor, before work starts, which tailoring decisions they expect to see justified.
Configure settings and document CM-6 deviations
Engineers set the cluster, node, runtime and namespace configurations to the most restrictive mode that still meets operational needs, following the common secure configurations the organization has defined under CM-6. Each setting that departs from the chosen benchmark is recorded as a deviation with a justification and an approver. The output is a configuration baseline in version control plus a deviation register, and it is done when a scan of the live cluster matches the baseline or shows only approved differences. Where the high baseline applies, CM-6(1) and CM-6(2) add automated management and response to unauthorized changes, so the partner should confirm which of these the organization needs before design begins.
Enable scanning and admission policies
Teams wire image, configuration and vulnerability scanning into the build pipeline and the running cluster, and they deploy admission policies that decide which workloads may start. Open-source tools such as Trivy and Kyverno are common choices for this work, but the organization should confirm each capability against current vendor documentation before relying on it. The output is a set of tested scan jobs and admission policies with recorded test results showing that known-bad images and non-compliant manifests are blocked or reported. This step is complete when a deliberately noncompliant test workload is rejected and the rejection is logged.
Collect and retain evidence
The partner sets up scheduled exports of scan reports, policy decisions, audit logs, configuration snapshots, change records and access reviews into a retained evidence store that the organization controls. Each artifact is tagged with the control identifier it supports, the date it was produced and the system component it covers. The output is an evidence index mapping each in-scope control to its artifacts, and the step is done when a sample of artifacts can be retrieved and reproduced for each control. Ask the partner how retention periods will be set, and confirm them with the organization's own records policy.
Run an internal check against SP 800-53A procedures
Before the independent assessor arrives, the organization's internal team walks through the assessment procedures in SP 800-53A for each in-scope control. For each determination statement, the team examines the artifacts, interviews the control owner and tests the mechanism where the procedure calls for it, then records a gap or a pass. The output is an internal assessment worksheet with gaps logged to the plan of action and milestones, and the step is done when every gap has an owner and a remediation decision. The organization, not the partner, makes the final call on each control's status.
Hand the package to the independent assessor
The organization assembles the system security and privacy plan, the baseline and tailoring record, the configuration baseline and deviation register, the evidence index, the internal worksheet and the open plan of action and milestones items into a single package. The partner helps prepare the package and answers questions about how the systems were built, but the independent assessor is the party that tests controls and issues findings. The output is a delivered, indexed package and a kickoff record with the assessor, and this step is complete when the assessor confirms it can begin testing.

What makes container work cost more or take longer

Container and Kubernetes programs rarely cost the same twice, because the same control set lands differently on a single small cluster than on a multi-tenant platform. The drivers below show which decisions push effort up or down, and what each one means for the internal staff time, implementation partner scope, tooling and assessor work a quote should reflect.

Number of clusters and environments

Each cluster, namespace layout and environment (development, test, staging, production) carries its own configuration settings under CM-6, its own admission policies and its own evidence trail. More clusters multiply the baseline definitions, scan targets and drift checks that must be documented and monitored. Fewer, well-templated clusters usually lower the effort. Ask the implementation partner to state whether the quote covers one reference cluster replicated across environments or each environment built and assessed separately.

Multi-tenancy and team count

The more teams that build and deploy images, the more people need to follow the same secure configuration rules, and the more exceptions must be approved and documented. Shared clusters add isolation questions that a single-team cluster never raises. Count the teams that will push images and the number of tenants sharing a control plane before estimating internal training and policy effort. Illustrative example: a platform serving twelve teams needs a deviation process that a single-team platform can skip.

Third-party and base images

Images pulled from public registries or vendor base layers arrive with their own packages, update cadence and sometimes unknown provenance. Each image source adds scanning scope, a patch responsibility to assign, and supply chain evidence to collect under the supply chain and flaw remediation controls. A short, approved base image catalog generally reduces this work. Ask which image sources the organization already allows and who owns rebuilding them when a vulnerability is disclosed.

Managed versus self-hosted control planes

A managed Kubernetes service shifts some control plane hardening, patching and logging to the cloud provider, which narrows the set of controls the organization must evidence itself. A self-hosted control plane keeps all of that work in-house, including API server settings, etcd protection and upgrade testing. Confirm with the provider which responsibilities it documents and which the organization still owns, because that split sets the size of the implementation partner's scope.

Selected baseline

The SP 800-53B baseline chosen for the system determines how many enhancements apply. CM-6(1) and CM-6(2) appear in the high baseline only, so a moderate system does not need to automate configuration verification or respond to unauthorized changes under those enhancements. Moving from moderate to high therefore adds automation and monitoring work that is not visible in the base control text. Confirm the impact level and any tailoring with the authorizing official before scoping.

Automatically generated evidence

Admission logs, scan reports, policy reports and drift alerts that a cluster produces without manual effort reduce the time spent collecting evidence for assessors. Where these outputs are absent or stored only on nodes, staff must screenshot, export and file them by hand for every assessment cycle. Ask what the existing pipeline already retains, for how long, and whether an independent assessor can rerun the checks. Gaps here usually cost more than any single tool license.

Who owns the controls, who prepares the evidence and who assesses

The organization that operates the system owns every SP 800-53 control it selects, including the container and Kubernetes controls that sit under CM-6 configuration settings. NIST frames the Rev. 5 controls as part of an organization-wide risk management process, so the decisions about which settings are acceptable, which risks to accept and which deviations to allow belong to the organization's own leadership and system owners, not to an outside party.

Risk decisions: Choose the baseline and tailoring for each cluster, decide which risks remain open, and record the acceptance in the system security and privacy plan.
CM-6 deviations: Approve and document each deviation from the defined secure configurations, and name the person accountable for it.
Change control: Decide which configuration changes to the cluster, its images and its policies go through review before they are applied.
Incident handling: Run detection, response and reporting for container and cluster incidents under the organization's own incident response plan.
Sign-off: Accept the evidence, sign the authorization or internal approval, and keep the records the assessor will request.

Before engaging any partner, confirm that the named owners for these decisions exist in your own governance structure.

What usually delays container work and how to avoid it

Most delays in container assessments do not come from the technology itself. They come from gaps in inventory, undocumented decisions and evidence gathered too late. The cards below cover the pitfalls we see most often and the step that prevents each one.

No inventory of images and base layers

Assessors asking how CM-6 and the flaw remediation controls apply to containers will first ask what is running. If nobody can list the images, their tags, digests and base layers, every later check rests on guesswork. Build a registry inventory that records image digests, the base image each one was built from and the cluster where it runs. Confirm that Trivy scans can be matched back to this inventory, so a finding points to a specific deployed workload.

Undocumented deviations from secure configurations

CM-6 expects teams to document the secure configuration they adopt and to approve and record any deviation from it. Containers make deviations easy to create, for example a privileged pod added during an incident or a host namespace enabled for a single debugging session. Require every deviation to name the workload, the reason, the approver, the compensating control and an expiry date. Review open deviations at each change board meeting so exceptions do not quietly become the standard.

Scanners run once instead of continuously

A scan that ran before the last release says little about the cluster that is running today. Image vulnerabilities, misconfigurations and secrets change as new images are built and as base layers receive updates. Run image scans in the build pipeline and cluster scans on a schedule, and keep the results in a store that the assessment team can query by date. Confirm how long scan results are retained so the evidence covers the full assessment period.

Admission policies without an exception process

Kyverno policies that block non-compliant resources protect the cluster, but a policy that blocks a critical deployment with no route to approval will be disabled under pressure. Assessors will look for the same discipline they expect for any control, meaning a documented owner, a request path and a record of each exception. Pair each enforced policy with a time-limited exception workflow, and log every policy change as a configuration change that goes through review.

Cloud checks enabled after resources exist

AWS Security Hub CSPM controls for NIST SP 800-53 Rev. 5 rely on AWS Config data, and AWS recommends enabling AWS Config resource recording first. Clusters and node groups created before recording was on will have no configuration history for the period before it started, which leaves gaps an assessor will find. Turn on AWS Config recording in every account and region before building the EKS environment, and confirm which controls depend on resource types that are not yet recorded.

Assessment package assembled after the fact

Teams often gather screenshots, scan exports and policy files in the final weeks before an assessment, when the original context is gone. Evidence collected this way is hard to tie to dates and owners, and it rarely shows that controls worked over time. Set up a recurring evidence collection job that saves policy versions, scan results, deviation records and admission logs to a dated location. Ask the assessor early which artifacts they expect so the package is built from those requirements.

Questions buyers ask about NIST 800-53 for containers and Kubernetes

Is NIST SP 800-190 required, or is it only guidance?

NIST SP 800-190, the *Application Container Security Guide*, is guidance, not a requirement in itself. It explains the security concerns of container technologies, including risks from the orchestrator, and recommends adapting technical processes and culture to the way containers change development, patching and upgrades. Your obligations come from the SP 800-53 controls your system is assessed against, the baseline your authorizing body selects, and any contract or program that references them. Use SP 800-190 as a design reference for how the controls apply to images, registries, orchestrators and runtime. Confirm with your authorizing official or contracting officer which control set and baseline govern your cluster before you scope the work.

How is CM-6 evidenced for a Kubernetes cluster?

CM-6 asks you to establish, document and implement configuration settings that reflect the most restrictive mode consistent with operational needs, to approve and record deviations, and to monitor changes. For a cluster, assessors usually look for a written set of settings for the control plane, nodes, namespaces and workloads, a machine-readable benchmark or policy that checks those settings, scan results from a recent run, and a record of approved exceptions with owners and review dates. Change records from your GitOps or pipeline history show that changes are monitored and controlled. In the high baseline, CM-6(1) and CM-6(2) add automated management and response to unauthorized changes, so check which enhancements your baseline selects.

Can an open-source stack produce the container evidence on its own?

An open-source stack can produce much of the technical evidence, but it does not produce the whole control package by itself. Scanners such as Trivy and admission policy engines such as Kyverno can generate vulnerability, misconfiguration and policy results, and ComplianceAsCode content can evaluate Kubernetes and OpenShift settings. Those outputs still need an owner, a documented procedure, a risk decision for every finding you accept, a system security plan entry and a record of how results were reviewed. Organizations also need to confirm that each tool's rules actually map to the control language they must meet, because a passing scan does not prove every SP 800-53 requirement is met. Plan for that gap in the scope.

What does the work need from our internal staff?

The work needs named internal owners who can make decisions that an implementation partner cannot make for you. Typical roles include a system owner who accepts risk, a platform lead who approves configuration baselines and exceptions, a security lead who owns the policies and reviews scan results, and an identity or access administrator for cluster and registry accounts. Engineers must be available to explain pipelines, cluster topology and workload ownership, and someone must hold the system security and privacy plan and the POA&M. DeployOpen plans, implements, hardens and documents self-hosted platforms in your own infrastructure and prepares the evidence, but your organization owns its controls. Ask any partner to list these roles in the written scope, with the hours each one needs.

Does a managed Kubernetes service remove the need for these controls?

No. A managed Kubernetes service shares some responsibilities with the provider, but it does not transfer your obligations under SP 800-53. The provider may handle parts of the control plane and physical infrastructure, while your organization still configures workloads, namespaces, network policy, secrets, images, identities and logging. Cloud provider checks, such as the NIST SP 800-53 Rev. 5 standard in AWS Security Hub CSPM, support a subset of requirements for certain services and do not cover controls that need manual checks. AWS recommends enabling AWS Config resource recording first. Map each control to the party that operates it, and record the inherited controls in your plan so the assessor can see the boundary.

Who issues the assessment result for our containerized system?

The assessment result comes from your authorizing body or the independent assessor that your contract or program requires, not from DeployOpen or from NIST. NIST publishes SP 800-53, the assessment procedures in SP 800-53A and the baselines in SP 800-53B, but it does not assess or certify systems. Under FISMA, Inspectors General independently assess agency systems. For federal and contractor programs, the authorizing official makes the risk decision based on an assessment report. DeployOpen prepares systems, controls and evidence for those assessments and does not issue audit reports, attestations or certifications. Confirm with the buyer which assessor or authorizing body they accept before you start preparing evidence.

What drives the cost of this work, and where do I get figures?

Cost depends on the number of clusters and environments, the number of workloads and images, the baseline and enhancements you must meet, how much of the stack you already run, whether you need custom policies or integrations, the depth of testing you require, and how much ongoing evidence collection you need after the first assessment. One-time costs usually include design, hardening, policy authoring, tool integration and the first evidence package. Recurring costs include scanning, patching, control monitoring, audit support and upgrades. Figures should come from a written scope, not from this page. Ask any provider for a quote that lists deliverables, assumptions, client-side roles and exclusions. DeployOpen does not publish a price list, and any quote follows from the written scope.

Does NIST publish cost or timeline estimates for this work?

No. NIST's risk management FAQ states that NIST does not estimate certification or compliance costs and does not set federal implementation timelines, which it leaves to OMB Circular A-130. NIST also says it does not offer or endorse any compliance program or tool. For planning, use the SP 800-53 baseline you must meet, the number of clusters and workloads in scope and the assessor's requirements as inputs, then ask your authorizing body, contracting officer or program office for their expected schedule and documentation. Treat any published duration or price that does not cite its source with caution.

How DeployOpen scopes and prepares container evidence

DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For NIST 800-53 work on containers and Kubernetes, we prepare the systems, configuration settings and evidence that an independent assessor will examine, while your organization owns its controls and the assessor issues any report.

How we scope

Agree in writing which clusters, namespaces, registries and CI pipelines fall inside the assessed boundary before work starts.
Map the CM-6 configuration settings your organization has defined to the specific Kubernetes and OpenShift checks in scope.
Confirm which controls your organization owns, which are inherited from a cloud provider and which you will test with the assessor.

How we build

Configure admission policies, such as Kyverno rules, to enforce approved image sources and workload settings at deployment time.
Run compliance-as-code content, such as ComplianceAsCode rules evaluated by the compliance-operator, and record the results against each in-scope setting.
Run open-source scanners like Trivy against images and cluster configurations, then triage findings with your remediation owners.

How we hand over

Deliver the configuration baseline, policy definitions, scan configurations and scan outputs in a form your assessor can examine and repeat.
Document deviations from the defined settings with approval records, so the exception trail is complete for each finding.
Provide runbooks for operating the tooling so your own team can rerun checks and keep evidence current after handover.

How we support

Offer ongoing support, upgrades and continuous testing as a retainer after the initial scope is delivered.
Review changes to cluster versions, policies and scanner releases against the agreed scope and update evidence accordingly.
Coordinate with your independent assessor on evidence requests, while the assessor retains sole responsibility for its findings.