If your organization does business with the U.S. Department of Defense, or plans to, you need to know about a major change that just went into force.
CMMC, or Cybersecurity Maturity Model Certification, is the Department of Defense’s standard for ensuring contractors meet basic cybersecurity requirements. It was designed to protect sensitive government data across the entire defense supply chain.
As of November 2025, CMMC is no longer optional. A new rule allows the DoD to require certification in contract bids, marking the official start of enforcement.
That rule, issued under the Defense Federal Acquisition Regulation Supplement (DFARS 48 CFR), formally adds CMMC to the federal contracting process. For many suppliers, cybersecurity certification is now a prerequisite to compete.
This article covers:
- Key changes introduced on November 10, 2025
- What CMMC baseline hardening really requires
- What defense contractors need to do now to stay competitive
The New DFARS Rule and What It Means
The Department of Defense has finalized a new rule that makes CMMC requirements part of the federal contracting process. As of November 10, 2025, contracting officers can begin requiring cybersecurity certification from companies that want to do business with the DoD. This rule is part of a phased rollout over three years and gives the government flexibility to apply CMMC where it matters most. It works alongside an existing regulation that defines how the CMMC program is structured, including the different certification levels and how assessments are handled. For most suppliers handling sensitive information, this means Level 2 certification, based on NIST security controls, will be required before they can bid. The key takeaway is simple. CMMC is no longer optional. If you want to compete for DoD contracts, you need to be able to prove your cybersecurity program meets the standard.
CMMC baseline hardening requirements
Baseline configuration is a foundational requirement in CMMC because it turns security policy into verifiable, repeatable technical control. At CMMC Level 2, it appears most directly in the Configuration Management domain, particularly in CM.L2-3.4.1, which requires organizations to establish and maintain baseline configurations for systems that process, store, or transmit CUI.
In practice, this means contractors must be able to clearly define what a “secure” system looks like for each system class – such as endpoints, servers, or cloud workloads – align those standards to recognized benchmarks like the CIS Benchmarks, and demonstrate that the baselines are consistently applied across the CMMC system boundary.
Get The Step-by-Step Guide to CIS Benchmark Compliance
Assessors are not just looking for a baseline document. They want to see evidence that the baseline is enforced, maintained over time, and reflected in running systems. Without documented and enforced baseline configurations, organizations struggle to prove consistency, scope, and control effectiveness. This makes baseline configuration one of the most common root causes of CMMC readiness gaps and assessment findings.
Baseline configuration requirements appear in the following CMMC controls: CM.L2-3.4.1, CM.L2-3.4.2, and CM.L2-3.4.6.
CM.L2-3.4.1 – Establish and maintain baseline configurations
The CMMC standard is unambiguous about the need for defined and maintained baselines. CM.L2-3.4.1 requires organizations to:
“Establish and maintain baseline configurations and inventories of organizational systems (including hardware, software, firmware, and documentation) throughout the respective system development life cycles.”
(CMMC 2.0 Level 2, CM.L2-3.4.1 — verify in the rule text / assessment guide)
What this means in practice:
A baseline is not a one-time hardening checklist. Assessors expect to see:
- Documented secure configuration standards (e.g., CIS Benchmarks)
- Evidence that those standards are actively applied to in-scope systems
- Asset inventories that align to the defined CMMC system boundary
Common failure point:
Organizations rely on tribal knowledge or default builds but cannot show a formally approved baseline which is constantly implemented tied to specific systems- Servers, Workstations, etc.
Why hardening matters:
Without a defined baseline, you cannot prove consistency—and without consistency, CMMC controls fail under scrutiny.
CM.L2-3.4.2 – Control changes to configurations
CMMC does not assume configurations remain secure once deployed. CM.L2-3.4.2 requires organizations to:
“Control changes to the system configuration during the system life cycle.”
(CMMC 2.0 Level 2, CM.L2-3.4.2 — verify in the rule text / assessment guide)
What this means in practice:
Assessors look for process + evidence, including:
- Change control procedures tied to in-scope systems
- Records showing configuration changes were reviewed and approved
- Proof that security settings persist after patching, upgrades, or emergency fixes
Common failure point:
Patch management exists, but security settings regress after updates—and no one is monitoring or documenting it.
Why hardening matters:
Configuration hardening only counts if it survives operational change. Drift detection, validation scans, and rollback procedures convert change management into audit-ready proof.
CM.L2-3.4.6 – Employ least functionality
Least functionality is often misunderstood as a design concept rather than an enforceable configuration requirement. CM.L2-3.4.6 requires organizations to:
“Employ the principle of least functionality by configuring organizational systems to provide only essential capabilities.”
(CMMC 2.0 Level 2, CM.L2-3.4.6 — verify in the rule text / assessment guide)
What this means in practice:
Assessors expect to see:
- Disabled unnecessary services, ports, protocols, and features
- Hardened default configurations (not vendor defaults)
- Justification or approval records for any non-essential functionality
Common failure point:
Systems are “secured” but still run unused services, legacy protocols, or admin tools “just in case.”
Why hardening matters:
Least functionality is enforced through configuration, not policy. Hardened builds, service baselines, and deviation tracking are how organizations demonstrate compliance.
Why Hardening Must Be Prioritized in CMMC
Baseline hardening is no longer an implied “best practice” in CMMC, it is a foundational requirement that directly affects compliance outcomes. With the November 10th CMMC rule changes, expectations around configuration management, least functionality, and system protection have become clearer and more enforceable, leaving little room for informal or inconsistent approaches. Organizations that fail to prioritize hardening risk increased assessment findings, higher remediation costs, and delayed certification. By making hardening a deliberate, documented, and continuously maintained activity, contractors not only reduce their attack surface but also demonstrate maturity, repeatability, and readiness.
Want to learn more?
Want to learn more about what CMMC requires, or find where your gaps might be? Our team can help you map your current controls to the standard, identify weak spots, and build a path to audit readiness. Reach out to start a conversation.
