The Configuration Management Domain: defining what systems are and keeping them that way

What the Configuration Management Domain Is For

The Configuration Management domain defines what the systems in the CMMC environment are supposed to be, tracks them as they evolve, and constrains what can run on them. Its nine requirements move from foundational inventory and baseline work through the change management lifecycle and into the functionality restrictions that reduce attack surface. The domain is less about security configuration in the narrow sense and more about the discipline of knowing what exists, approving what changes, and enforcing what is allowed.

The practitioner reading of CM is that it is the operational backbone of every other domain's ongoing effectiveness. A system hardened today drifts tomorrow if change is not controlled. A least-privilege model established at the start erodes if new software arrives without review. An audit baseline depends on knowing what the system looked like before a deviation. The CM controls make the rest of the framework sustainable over time rather than true only at a single moment.

Defense contractors preparing for CMMC Level 2 assessment frequently underestimate CM because it does not produce visible security artifacts the way encryption or access control does. There is no CM equivalent of a firewall rule or an MFA prompt. The evidence is documentation, approval workflows, and records of what was changed and why. That evidence is harder to produce retroactively than most other domains, which is why CM readiness benefits most from starting early.

The Structure of the 9 Controls

The nine CM requirements organize into three clusters that reflect the lifecycle of configuration control.

The first cluster covers baseline and security configuration. These two controls (3.4.1 and 3.4.2) establish what systems the organization has, what their configurations should look like, and how those configurations are documented. The baseline cluster is the reference point that every other control in the domain depends on. Without a baseline, deviation cannot be measured, change cannot be approved against anything, and least functionality cannot be enforced.

The second cluster covers change management. These three controls (3.4.3, 3.4.4, and 3.4.5) address how changes are tracked, analyzed, and authorized. The change management cluster is where the discipline of the domain becomes visible in practice. Every configuration change that is not captured by this cluster creates drift from the baseline.

The third cluster covers functionality restriction. These four controls (3.4.6, 3.4.7, 3.4.8, and 3.4.9) address what is allowed to run on systems. Least functionality, nonessential service disablement, application execution policy, and user-installed software monitoring together define the attack surface the organization permits. This cluster is where CM most directly reduces the risk that every other domain is working to contain.

The first cluster establishes the reference point that the rest of the domain depends on. A baseline is not a one-time deliverable. It is an ongoing description of what systems are supposed to look like, updated as systems evolve and maintained with the same discipline as any other operational artifact.

CM.L2-3.4.1System Baselining

The organization must establish and maintain baseline configurations and inventories of organizational systems, including hardware, software, firmware, and documentation. The control has two assessable components. The first is the inventory itself, which must be complete for the CMMC assessment scope and updated as systems are added or retired. The second is the baseline configuration, which describes the approved state of each system category. Findings in this area often involve inventory that is stale or incomplete, or baselines that exist for common system types while specialized assets and legacy systems are undocumented.

CM.L2-3.4.2Security Configuration Enforcement

The organization must establish and enforce security configuration settings for information technology products employed in organizational systems. Configuration settings are the specific values that control security-relevant behavior. The control requires that those settings are defined, that they are applied consistently, and that they are enforced rather than merely recommended. The authoritative references for configuration settings are typically vendor hardening guides, CIS benchmarks, or DISA STIGs, with organizational tailoring to match the operational environment. The assessable evidence includes both the defined settings and the demonstration that systems conform to them.

The second cluster addresses the discipline of change. Every system eventually requires modification, and the question is not whether change occurs but whether it is controlled. The change management cluster moves from tracking changes through analyzing their impact and restricting who can make them.

CM.L2-3.4.3System Change Management

Changes to organizational systems must be tracked, reviewed, approved or disapproved, and logged. This is the core change control requirement. The organization must know what changes have been requested, which have been approved, which have been implemented, and which have been rejected. Findings often involve change management processes that function well for planned changes and fail for emergency changes, patches, and routine maintenance that operate outside the formal workflow. The assessable standard is that all changes go through some form of tracking, even if the review intensity varies by change category.

CM.L2-3.4.4Security Impact Analysis

The security impact of changes must be analyzed prior to implementation. The control requires that someone qualified evaluate each change against its security consequences before the change is made. The assessable evidence is the documented analysis. An impact analysis that consists of a checkbox in a change ticket does not demonstrate that analysis actually occurred. The analysis should reference the controls the change could affect, the systems in scope, and the residual risk after implementation.

CM.L2-3.4.5Access Restrictions for Change

Physical and logical access restrictions associated with changes to organizational systems must be defined, documented, approved, and enforced. The control requires that only authorized personnel can make changes, and that the authorization is tied to specific systems and change types. This is where CM most directly interacts with Access Control, because the permission to make a change is an access decision. The documented restrictions must match the enforcement in practice, and assessors will compare the two.

The third cluster addresses what is allowed to run on systems. Least functionality, nonessential services, application execution policy, and user-installed software each address a different surface through which unauthorized functionality can enter the environment.

CM.L2-3.4.6Least Functionality

Organizational systems must be configured to provide only essential capabilities. The principle is that any functionality not required to perform an assigned role should not be present. In practice this means removing or disabling installed software, system services, and operating system features that are not needed. The assessable question is not whether the default operating system install has been trimmed, but whether the configuration reflects a deliberate decision about what capabilities each system requires.

CM.L2-3.4.7Nonessential Functionality

The use of nonessential programs, functions, ports, protocols, and services must be restricted, disabled, or prevented. This control extends 3.4.6 to operational runtime behavior. Nonessential ports should not be listening. Nonessential protocols should not be permitted. Nonessential services should not be running. The documentation must identify what is essential and why, and the enforcement must match the documentation. Assessors frequently find systems where the documented essential services list is short and the actual running services list is long.

CM.L2-3.4.8Application Execution Policy

The organization must apply a deny-by-exception policy to prevent the use of unauthorized software, or a deny-all-permit-by-exception policy to allow execution only of authorized software. In practice this typically means application control technology such as allowlisting or equivalent capabilities that prevent unauthorized executables from running. The control permits either approach, but the chosen approach must be enforced in practice rather than defined only on paper. Findings often involve policies that name a tool or capability without demonstrating that the tool actually enforces the policy across the assessment scope.

CM.L2-3.4.9User-Installed Software

User-installed software must be controlled and monitored. The control addresses the surface through which most unauthorized software enters environments: through users installing what they need to do their work. The implementation usually combines technical prevention (restricting installation rights) with monitoring (detecting attempted or successful installations). A policy that prohibits user installation is not sufficient on its own. The control requires that the prohibition is enforced and that attempts are visible to the organization.

Where Configuration Management Intersects with Other Domains

Configuration Management touches nearly every other domain because it governs the operational state that those domains depend on.

Access Control provides the authorization chain that 3.4.5 enforces for change activity. The right to make a configuration change is an access right, and CM inherits whatever strength or weakness AC provides. A weak AC implementation produces CM findings because changes can be made by people who should not be authorized to make them.

Audit and Accountability captures the change events that 3.4.3 requires to be tracked. The change log and the audit log are different artifacts, but they reference the same events, and assessors look for consistency between them. A change that appears in the change management system but not in the audit log, or the reverse, indicates a gap somewhere in the pipeline.

Risk Assessment informs the security impact analysis in 3.4.4. The analysis of a change cannot be separated from the risk picture it modifies, and the inputs to 3.4.4 trace back to the risk assessment process that establishes the baseline understanding of what the organization protects.

System and Information Integrity depends on CM baselines for its monitoring work. Integrity monitoring compares the current state against an approved state, and that approved state is the CM baseline. When the baseline is incomplete or out of date, SI controls produce false positives or miss genuine deviations.

System and Communications Protection includes many of the specific configuration settings that CM enforces under 3.4.2. Encryption settings, boundary protection configurations, and network segmentation rules are SC controls, but the enforcement of those settings across the fleet is a CM responsibility.

Physical Protection interacts with CM through 3.4.5, which includes physical access restrictions for change activity. A server that can be reached physically without authorization presents a CM problem as much as a PE problem, because physical access permits configuration change outside the controlled workflow.

Common Implementation Pitfalls

Several patterns come up repeatedly in Configuration Management readiness work.

Baselines that describe an ideal state the systems do not actually match. The baseline document exists and reads well, but a sample of actual systems reveals configuration differences that were never reconciled. The assessor does not evaluate the baseline document in isolation. They evaluate whether the systems conform to it.

Change management with a permanent emergency exception. The change control process works for planned changes and is bypassed for urgent ones. Over time, most changes happen under the emergency exception, and the formal process becomes aspirational rather than operational. The remediation is not stricter emergency rules but a recognition that emergency changes still require tracking, even if the review is retrospective.

Security impact analysis reduced to a checkbox. The change ticket includes a field for impact analysis, and the field is always checked with minimal content. The 3.4.4 obligation is satisfied when someone qualified actually evaluates the security consequences, documents the analysis, and signs off on the residual risk. A checkbox does not meet that standard.

Least functionality defined by the default install. The baseline reflects what the operating system included out of the box rather than what the system actually needs to do its job. Unused services remain enabled because no one has looked at them, and the attack surface is larger than it needs to be. The 3.4.6 standard is affirmative selection of essential capabilities, not passive acceptance of defaults.

Application execution policy that is not actually enforced. The organization has an allowlisting tool, but it is in audit mode rather than enforcement mode, or it covers only a subset of systems. The policy document says the control is in place. The actual runtime behavior shows that unauthorized executables still run. Assessors look at the runtime state, not at the policy.

User-installed software detected but not acted on. The monitoring capability under 3.4.9 generates alerts, and the alerts accumulate without response. A detection that does not trigger action is equivalent to no detection at all. The control requires both the monitoring and the operational response to what the monitoring finds.

Configuration drift that has never been reconciled. Systems move away from baseline over time through routine operations, patches, and one-off adjustments. Periodic reconciliation is part of keeping baselines meaningful, and its absence produces baselines that describe systems as they were rather than as they are.

Where to Start

For an organization new to the CM domain, the first work is the inventory.

The foundational deliverable is a complete list of systems in the CMMC assessment scope, categorized by type, with enough detail to support baseline work. Without the inventory, baselines cannot be defined with precision, configuration settings cannot be enforced uniformly, and change control cannot identify what is changing. The inventory is both a CM requirement and an enabler for every other CM control.

The second deliverable is the baseline description for each system category. This does not need to be exhaustive at the start. It needs to be accurate. A baseline that covers the major categories and acknowledges where specialized assets need separate treatment is better than an aspirational baseline that claims coverage it does not have.

The third deliverable is the change management process. How changes are requested, who reviews them, how impact is analyzed, how approval is recorded, and how implementation is tracked. The process document is the reference point for 3.4.3, 3.4.4, and 3.4.5 together, and it can be scaled down to match the organization's actual operational reality. A small manufacturer does not need an enterprise change advisory board. It needs a process that matches its scale and produces the evidence that assessment requires.

With the inventory, baselines, and change process in place, the functionality restriction cluster becomes implementation work against a documented foundation. The remaining controls in the domain have a defensible reference point to work against, and the assessment evidence follows naturally from how the controls are actually operated.