1Overview
CM.L2-3.4.2 puts security into the baseline. It requires that the organization establish and enforce security configuration settings for the IT products it uses, so that systems are not merely inventoried but hardened to a defined secure standard. It is a five-point requirement that cannot be deferred on a plan of action.
A system left at vendor defaults is rarely secure, because defaults favor easy setup over safety: unnecessary services on, weak settings enabled, sample accounts present. This control asks the organization to define secure configuration settings for its products, fold them into the baseline of 3.4.1, and enforce them so systems actually run that way. Where the baseline control describes how systems are built, this one requires that the description include a hardened security configuration and that the configuration be enforced rather than aspirational.
Establish and enforce security configuration settings for information technology products employed in organizational systems.
The requirement pairs establish with enforce. To establish is to define the secure settings, often drawn from recognized hardening guidance, and include them in the baseline. To enforce is to make systems actually apply those settings and keep them applied, so that hardening is the real state of the environment, not a document describing an ideal. The five-point weight reflects that a hardened configuration removes much of the attack surface an adversary would otherwise exploit.
2The Assessment Objectives
NIST SP 800-171A frames 3.4.2 around two objectives: establish the settings in the baseline, and enforce them.
Security configuration settings for information technology products are established and included in the baseline configuration. The organization has defined secure settings for its products.
Security configuration settings for information technology products are enforced. Systems actually apply and keep the defined settings.
The two objectives are establishing the secure settings and enforcing them. The common gap is at objective [b], where secure settings are documented but not actually applied or held in place, so systems drift back toward defaults. The assessor looks for hardening that is enforced and maintained, not merely written down.
3Failure Patterns
The failures are about default configurations and hardening that is documented but not enforced.
Vendor defaults left in place
Systems running at vendor defaults carry unnecessary services, weak settings, and sample accounts that widen the attack surface. Defining and applying secure settings is what this control requires, and leaving defaults fails it.
Hardening on paper only
A documented hardening standard that is never applied leaves objective [b] unmet, because the real systems do not match the document. Enforcement through configuration management is what turns the standard into the actual state.
Configuration drift
Even where settings are applied, systems drift as changes accumulate, so without enforcement the hardening decays. Continuous or periodic enforcement keeps systems at the defined configuration over time.
No standard to build from
Without a recognized hardening baseline to draw on, secure settings are invented ad hoc and inconsistently. Using established hardening guidance gives the settings a defensible, consistent basis.
4Ownership
This is an IT-owned technical control, and its work is defining secure settings and enforcing them across systems.
| Role | Responsibility for this control |
|---|---|
| IT and system administrator | Defines the secure settings, includes them in the baseline, and enforces them across systems. Owns the technical evidence. |
| Security or compliance lead | Confirms the settings draw on recognized hardening guidance and that enforcement keeps systems at the standard. |
| Program lead | Includes configuration enforcement in periodic review and retains the evidence. |
5Tooling
The control is delivered by hardening standards applied through central configuration management.
| Objectives | Tooling | What it provides |
|---|---|---|
| [a] | Recognized hardening guidance, security baselines | Defined secure settings included in the baseline for each product. |
| [b] apply | Group Policy, Intune, configuration management tools | Application of the defined settings across systems. |
| [b] maintain | Configuration compliance monitoring, drift detection | Enforcement that keeps systems at the defined configuration over time. |
The caveat is that applying settings once is not enforcing them, because systems drift. Central configuration management that both applies and re-applies the settings, with monitoring for drift, is what satisfies the enforce objective. The assessor examines whether systems actually run at the defined secure configuration, so enforcement over time has to be demonstrable.
6Evidence
The satisfied version of 3.4.2 shows defined secure settings enforced across systems.
| Evidence | What it demonstrates |
|---|---|
| Defined security settings | Objective [a]. The secure configuration included in the baseline. |
| Enforcement configuration | Objective [b]. The application of settings across systems. |
| Compliance or drift monitoring | Objective [b]. Evidence systems stay at the defined configuration. |
The evidence should show that secure settings are defined and actually enforced on systems over time, not just documented. The hardening standard paired with enforcement and drift monitoring is the clearest demonstration, and because this control cannot sit on a plan of action, the enforcement has to be real at the time of assessment.
Defaults are built for setup, not for safety
Systems left at vendor defaults carry an attack surface that a defined, enforced hardening standard removes, and the usual gap is hardening that lives on paper while systems drift. Defining secure settings and enforcing them across the environment is part of the onsite readiness work this practice does, and it is one of the controls that must be met rather than deferred.
Start CMMC Readiness or call 802-335-26627Sources
- NIST Special Publication 800-171 Rev 2, Protecting Controlled Unclassified Information in Nonfederal Systems and Organizations, requirement 3.4.2. csrc.nist.gov
- NIST Special Publication 800-171A, Assessing Security Requirements for Controlled Unclassified Information, assessment objectives 3.4.2[a] and 3.4.2[b]. csrc.nist.gov
- 32 CFR 170.24, CMMC Scoring Methodology, listing CM.L2-3.4.2 among the five-point basic security requirements. ecfr.gov