CM-6: Configuration Settings

Quick-reference card

What this control requires

CM-06 requires organizations to establish, document, enforce, and monitor secure configuration settings for every system component. The control targets the specific parameters inside hardware, software, and firmware that directly shape your security posture, and it applies to systems you operate as well as those managed by third parties on your behalf.

In practice, this means defining a secure baseline for settings like access control lists, firewall rules, authentication parameters, open ports, enabled services, and remote connection protocols. Your configuration baselines should reflect the most restrictive mode consistent with operational needs, drawing from recognized benchmarks such as Center for Internet Security (CIS) Benchmarks, Security Technical Implementation Guides (STIGs), or the United States Government Configuration Baseline (USGCB). Privacy-related parameters, including data processing and retention permissions, fall under this control as well.

But defining settings isn’t enough on its own. CM-06 also requires you to implement the documented settings across all applicable components, formally identify and approve any deviations that operational requirements demand, and continuously monitor for unauthorized changes. Automated tools that support the Security Content Automation Protocol (SCAP) can streamline tracking and enforcement, but the underlying discipline is organizational: someone owns the configuration, someone approves exceptions, and someone monitors drift. Without that accountability chain, documented settings are just paperwork.

Why it matters

Misconfigured systems remain one of the most reliable entry points for attackers, and they don’t require sophisticated exploits to abuse. A single overlooked default credential, an unnecessary open port, or a permissive access control setting can expose sensitive data to anyone who knows where to look. CM-06 exists because configuration management failures aren’t hypothetical risks; they’re recurring, documented causes of breaches that affect organizations of every size.

The stakes increase when third-party vendors manage systems on your behalf. Your organization remains accountable for the security posture of those systems, but you lose direct visibility into how they’re configured. When vendor portals, cloud environments, or hosted applications ship with insecure defaults or get reconfigured without your knowledge, you inherit the exposure without necessarily knowing it exists.

Specifically, when configuration settings aren’t governed by policy, drift accumulates silently. Systems that were secure at deployment gradually diverge from their baselines as patches are applied, features are enabled, and administrators make ad hoc changes. By the time an auditor or attacker discovers the gap, the deviation may have existed for months.

Keenan and Associates portal misconfiguration

In October 2015, Keenan and Associates, a Torrance, California health plan administrator serving employer groups and public agencies, discovered that documents containing health plan member information had been indexed by public search engines. The exposure originated from a third-party vendor portal used to host benefit documents. The portal had been configured incorrectly, removing access restrictions that should have limited document retrieval to authenticated users.

The result was that approximately 35,000 member records, including names, addresses, phone numbers, dates of birth, medical plan identifiers, and in some cases Social Security numbers, became publicly discoverable through standard search engines. Keenan had outsourced the portal operation without establishing or verifying that the vendor’s security configuration met its requirements. The CM-06 failure is evident across three gaps. No documented configuration baseline was applied to the vendor system, no verification process confirmed the settings were enforced, and no monitoring detected the misconfiguration before search engines indexed the exposed documents.

This case illustrates why CM-06’s scope explicitly extends to systems operated by third parties. Configuration accountability doesn’t stop at your organizational boundary.

What attackers exploit

When configuration settings aren’t governed, attackers target predictable weaknesses:

• Default credentials and factory settings. Many systems ship with well-known default usernames and passwords. Automated scanning tools check for these first, and cloud misconfigurations frequently trace back to unchanged defaults.
• Overly permissive access controls. File shares, databases, and APIs configured with broader permissions than necessary let attackers move laterally or exfiltrate data without triggering alerts.
• Unnecessary services and open ports. Every enabled service and open port expands the attack surface. Attackers scan for services that shouldn’t be internet-facing and exploit known vulnerabilities in those services.
• Disabled logging and monitoring. When audit logging is turned off or configured to capture insufficient detail, attackers operate without leaving evidence. Configuration drift in logging settings is especially dangerous because it’s invisible until you need the logs.
• Unpatched or outdated firmware settings. Firmware-level configurations that haven’t been updated to reflect current security requirements can introduce vulnerabilities that software patches alone can’t address.

How to implement

Most organizations treat CM-06 as a one-time hardening exercise rather than a continuous enforcement discipline. That gap between initial configuration and ongoing monitoring is exactly where configuration drift turns into audit findings and security incidents.

For your organization

Start by inventorying all system components that fall under your security boundary, including servers, network devices, endpoints, cloud resources, and applications. You can’t enforce configuration settings on systems you don’t know about.

The next step is selecting a recognized secure configuration benchmark for each component category. CIS Benchmarks cover most common operating systems, databases, and cloud platforms. STIGs apply to federal and defense environments. Your chosen benchmark becomes the foundation for your organization’s configuration baseline.

In practice, you’ll document your configuration baselines in a configuration management plan that maps each benchmark to the specific system components it governs. Include the rationale for any deviations from the benchmark’s recommended settings. Operational requirements sometimes justify less restrictive configurations, but those deviations must be formally documented, risk-assessed, and approved by the appropriate authority.

Specifically, deploy your baselines using configuration management tools that can push settings to endpoints and verify compliance at scale. Manual configuration is error-prone and doesn’t scale beyond a handful of systems. Automated enforcement also generates the evidence auditors need: deployment logs, compliance scan results, and drift detection alerts.

But enforcement without monitoring leaves gaps. Schedule regular compliance scans and configure alerts for unauthorized changes. When drift is detected, investigate whether it resulted from an approved change, an unauthorized modification, or a system error, then remediate accordingly.

Where most teams fall short is in maintenance. Common mistakes include treating configuration baselines as a one-time exercise, failing to update baselines when new vulnerabilities or benchmark revisions are published, and relying on manual checklists instead of automated enforcement.

For your vendors

Your vendors manage systems that process, store, or transmit your data, and CM-06 holds you responsible for the configuration posture of those systems. Start your vendor assessment by asking targeted questions that reveal whether the vendor has a mature configuration management practice.

Key security questionnaire questions to include:

• What secure configuration benchmarks do you follow (for example, CIS Benchmarks, STIGs, or vendor-specific hardening guides)?
• How do you enforce configuration baselines across production systems?
• What is your process for documenting and approving deviations from your configuration baseline?
• How do you monitor for configuration drift, and what is your mean time to detect unauthorized changes?
• Can you provide evidence of your most recent configuration compliance scan?

But questionnaires alone aren’t sufficient. Request specific evidence beyond self-attestation. Configuration compliance scan reports, change control records, and approved deviation registers demonstrate that the vendor doesn’t just have a policy on paper but actively enforces and monitors their settings. Automated scan results with timestamps are stronger evidence than narrative descriptions.

In practice, the red flags are predictable. Vendors who can’t name the benchmarks they follow, who lack automated configuration enforcement, or who have no formal deviation approval process are all warning signs. A vendor that relies entirely on manual configuration and periodic audits is more likely to have the kind of undetected drift that exposed Keenan and Associates’ member data.

Verification shouldn’t stop at onboarding. Include configuration management requirements in your vendor contracts, and review vendor compliance periodically. Require notification when the vendor makes material changes to system configurations that affect your data.

Evidence examples

Cross-framework mapping

ISO 27001:2022 control 8.9 addresses configuration management broadly, covering the establishment, documentation, implementation, monitoring, and review of configurations for hardware, software, services, and networks. It aligns closely with CM-06’s intent but doesn’t prescribe the same level of detail around deviation documentation and approval.

NIST SP 800-171 Rev 3 control 03.04.02 maps directly to CM-06 for controlled unclassified information (CUI) environments. Organizations subject to Defense Federal Acquisition Regulation Supplement (DFARS) or Cybersecurity Maturity Model Certification (CMMC) requirements will find that satisfying CM-06 substantially addresses 03.04.02 as well.

Related controls

• AC-3 — Access Enforcement: Access enforcement mechanisms rely on correctly configured permissions. CM-06 ensures those permission settings are documented, applied, and monitored rather than left to individual administrator judgment.
• AC-19 — Access Control for Mobile Devices: Mobile device configurations, including encryption settings, remote wipe capabilities, and network access policies, must be governed by the same configuration baseline discipline that CM-06 requires for all system components.
• AU-2 — Event Logging: Logging configurations determine what events your systems capture. CM-06 governs the settings that control log scope, retention, and destination, making it a prerequisite for effective event logging.
• AU-6 — Audit Record Review, Analysis, and Reporting: Reviewing audit records can reveal unauthorized configuration changes. AU-6 depends on CM-06 to ensure logging configurations haven’t been tampered with or reduced in scope.
• CA-9 — Internal System Connections: Internal connections between system components require documented configuration settings to prevent unauthorized data flows. CM-06 provides the configuration governance that CA-9’s connection controls depend on.
• CM-2 — Baseline Configuration: CM-2 establishes the overall system baseline, while CM-06 focuses specifically on the individual configuration settings within that baseline. CM-2 is the architecture; CM-06 is the detail.
• CM-3 — Configuration Change Control: CM-3 governs the process for requesting, approving, and implementing changes. CM-06 ensures that the resulting configuration settings after each change still align with the documented secure baseline.
• CM-5 — Access Restrictions for Change: CM-5 controls who can modify system configurations. CM-06 controls what those configurations should be. Together, they ensure that only authorized personnel make changes and that those changes align with security requirements.
• CM-7 — Least Functionality: CM-7 requires disabling unnecessary functions, ports, protocols, and services. CM-06 documents and enforces the settings that implement least functionality at the component level.
• CM-11 — User-installed Software: User-installed software introduces unmanaged configuration settings. CM-11 restricts what users can install; CM-06 ensures that approved software is configured securely.

Frequently asked questions

What is NIST SP 800-53 CM-06?

CM-06 is the configuration settings control within the NIST SP 800-53 security and privacy framework. It requires organizations to establish documented secure configuration settings for all system components, implement those settings, formally approve any deviations, and continuously monitor for unauthorized changes. The control applies across LOW, MODERATE, and HIGH baselines, making it a universal requirement for federal information systems and a widely adopted benchmark for private-sector security programs.

What happens if CM-06 is not implemented?

Organizations without CM-06 controls face unmanaged configuration drift that silently expands their attack surface over time. Default credentials, overly permissive access controls, and unnecessary services remain active on production systems because no one defined what the secure settings should be or verified that they were applied. Audit findings, regulatory penalties, and breach liability follow when a misconfiguration leads to data exposure. The Keenan and Associates case demonstrates how a single unchecked vendor configuration setting can expose tens of thousands of records.

How do you audit CM-06?

Auditing CM-06 starts with verifying that documented configuration baselines exist for each system component category and that those baselines reference recognized secure benchmarks. Next, compare live system configurations against the documented baselines using automated scanning tools. Review the deviation register to confirm that every approved exception has a documented risk justification and an authorizing signature. Examine change control records to verify that configuration changes follow the approved process. Finally, confirm that continuous monitoring is active by reviewing drift detection alerts and remediation records from the audit period.

What is the difference between a baseline configuration and configuration settings?

A baseline configuration, governed by CM-2, is the documented snapshot of a system’s overall architecture, including its components, network topology, and logical structure at a specific point in time. Configuration settings, governed by CM-06, are the specific parameters within that baseline: registry values, firewall rules, access permissions, enabled services, and authentication thresholds. Think of the baseline as the blueprint for what your system looks like; configuration settings are the detailed specifications for how each component behaves. Both controls work together, but CM-02 answers “what is in the system” while CM-06 answers “how is each component configured.”