CMMC Level 2 Practice 3.4.2: Establish and enforce security configuration settings for information technology products

To meet CMMC Level 2 Practice 3.4.2, you must define secure configuration baselines for the IT products in your CUI environment, deploy those settings consistently, and enforce them so drift is detected and corrected. Assessors will look for repeatable technical enforcement plus durable evidence that settings are approved, implemented, monitored, and updated. ¹

Key takeaways:

• You need approved configuration baselines per product type (OS, endpoints, servers, network gear, cloud, apps) and a process to keep them current. ¹
• “Enforce” means technical controls (MDM/GPO/IaC/secure templates) plus monitoring and remediation for configuration drift.
• Evidence must show what the baseline is, where it applies, how it’s deployed, and proof it’s working during the assessment window. ²

cmmc level 2 practice 3.4.2: establish and enforce security configuration settings for information technology products requirement is a configuration management control with a simple assessor expectation: you can’t rely on “tribal knowledge” or one-time hardening. You need a documented baseline and a way to make systems conform to it in real operations.

For a Compliance Officer, CCO, or GRC lead, the fastest path is to scope the “IT products” that store, process, or transmit CUI (or directly protect those systems), then standardize secure settings by product family. Your security team will implement the mechanisms (Group Policy, MDM, endpoint management, network configuration management, cloud policies, infrastructure-as-code), but GRC owns making it auditable: approval, change control, exceptions, and evidence capture.

This practice is mapped to NIST SP 800-171 Rev. 2 requirement 3.4.2 and is assessed under the DoD CMMC Program. ^{1 2} Your operational goal is to make secure configuration a routine: baseline, deploy, monitor drift, remediate, and update.

Regulatory text

Provided excerpt: “CMMC Level 2 practice mapped to NIST SP 800-171 Rev. 2 requirement 3.4.2 (Establish and enforce security configuration settings for information technology products).” ¹

What the operator must do:

1. Establish security configuration settings by defining approved secure baselines for the IT products in scope for CMMC Level 2. ¹
2. Enforce those settings through technical means and operational governance so endpoints, servers, network devices, and cloud resources do not drift into insecure states without detection and correction. ¹
3. Maintain assessment-ready documentation aligned to CMMC expectations and be able to demonstrate implementation and ongoing operation. ^{2 3}

Plain-English interpretation

This requirement means: pick a secure way to configure each technology you use, write it down, deploy it consistently, and keep it that way. If a system deviates, your tooling or process must catch it and drive it back to the approved state (or record an approved exception).

Settings that commonly fall under this practice include (examples, not a checklist): authentication and session controls, local admin restrictions, logging configuration, encryption and protocol settings, firewall rules, services/ports, secure remote management, and hardening of default accounts and interfaces.

Who it applies to (entity and operational context)

Applies to: Defense contractors and other federal contractors handling CUI and pursuing/maintaining CMMC Level 2. ^{2 3}

Operational context:

• In-scope environment: Any IT product that stores, processes, or transmits CUI, plus supporting systems that provide security or administrative control over that environment (for example, identity, endpoint management, vulnerability tooling). Scoping is assessed in CMMC and must be defensible. ²
• IT products: End-user devices, servers, network devices, hypervisors, managed databases, SaaS admin consoles, cloud accounts/subscriptions/projects, and security tools that control configurations.

What you actually need to do (step-by-step)

Step 1: Build an “in-scope product inventory” you can manage

Create a list of product families and where they run:

• Endpoint OS types, server OS types
• Mobile devices and MDM-managed profiles
• Network devices (firewalls, switches, routers, VPN)
• Cloud services and tenant-level security settings
• Key applications (email, collaboration, browsers, remote access tools)

Minimum fields: owner, environment (CUI/non-CUI), configuration authority (where settings are enforced), and link to the baseline document.

Step 2: Define secure baselines per product family

For each product family, publish a baseline that includes:

• Required settings (clear, testable statements)
• Rationale (brief, security reason)
• Enforcement method (GPO, MDM profile, firewall manager, cloud policy, IaC pipeline)
• Exception criteria (what qualifies, who approves, compensating controls)
• Versioning and approval (who approved, date, change history)

Practical tip: write baselines in a format that maps directly to tooling. If the baseline says “Disable SMBv1,” your evidence should show the GPO/MDM/policy that does it plus a compliance report that confirms status.

Step 3: Implement technical enforcement (not just policy)

Assessors expect proof that settings are actually applied. Common enforcement patterns:

• Windows: Group Policy Objects, security baselines, configuration profiles
• macOS: MDM configuration profiles and compliance rules
• Linux: configuration management (Ansible, Puppet, Chef) and hardened images
• Network: centralized management templates, configuration lock, approved change workflow
• Cloud: organization policies, conditional access equivalents, CSPM guardrails, IaC with peer review

Document the “system of enforcement” per product type so you can explain how drift is prevented or corrected.

Step 4: Add drift detection and response

“Enforce” also means you can tell when devices fall out of compliance:

• Run configuration compliance checks (MDM compliance, endpoint posture, CIS-style checks, cloud config checks).
• Define what happens when drift is found: ticket created, owner assigned, remediation SLA (your internal target), and escalation rules.
• Track exceptions separately so “noncompliance” is either remediated or explicitly approved.

Step 5: Tie baselines to change control

Operationalize baseline updates:

• Trigger baseline review when major version changes occur, new products are introduced, or security advisories require configuration changes.
• Require security review for configuration changes affecting the CUI boundary.
• Maintain a record of change approvals and testing notes for material baseline changes.

Step 6: Make evidence capture recurring

Your evidence should not be a scramble before assessment. Put evidence capture on a recurring cadence:

• Export compliance reports from MDM/GPO/config tools
• Sample device configs across each product family
• Keep exception logs current
• Keep baseline versions and approvals current

Where Daydream fits naturally: Daydream can track 3.4.2 as a requirement with assigned owners, map the baseline documents to the control, and schedule recurring evidence pulls (reports, screenshots, exports) so you have a clean assessment package instead of last-minute collection.

Required evidence and artifacts to retain

Maintain an assessor-ready package organized by product family:

Governance artifacts

• Configuration Management Policy or standard (covers baselines, enforcement, exceptions, and change control) ¹
• Baseline documents with version history and approvals
• Exception process and exception register (approved deviations + compensating controls)
• Scope statement: what systems/products are in the CUI environment ²

Technical artifacts (implementation proof)

• GPO/MDM profile exports or screenshots showing key settings
• Configuration management code snippets (redact secrets), pipeline approvals
• Cloud policy exports (tenant/org-level controls)
• Configuration compliance reports showing device/resource compliance status
• Drift remediation tickets and closure evidence
• Samples: “gold image” build scripts, hardened templates, or approved device build docs

Keep evidence focused on settings tied to security outcomes. Avoid dumping raw configuration for everything unless it proves a control point.

Common exam/audit questions and hangups

Assessors and internal auditors commonly press on:

• “Show me the baseline.” They want a named, versioned document per major product family. ¹
• “Show me enforcement.” A written baseline without a technical mechanism reads as aspirational.
• “How do you prevent drift?” They will ask for compliance reports and remediation workflow evidence.
• “What about exceptions?” If exceptions exist, they must be approved, time-bounded where practical, and tracked with compensating controls.
• “What’s in scope?” If you can’t clearly define which IT products are part of the CUI environment, every other answer gets harder. ²

Frequent implementation mistakes and how to avoid them

1. One baseline document for “everything.”
   Fix: split by product family and enforcement tool. Keep each baseline testable.

2. Baselines exist, but builds are manual.
   Fix: require device enrollment and centralized management for in-scope endpoints; use templates/IaC for cloud and network.

3. No evidence of ongoing operation.
   Fix: capture periodic compliance reports and a small sample of remediation tickets that show drift detection works.

4. Shadow IT in the CUI boundary.
   Fix: align procurement and onboarding so new tools cannot enter the CUI environment without a baseline and enforcement plan.

5. Exceptions become permanent.
   Fix: require documented compensating controls and periodic re-approval; close exceptions when blockers are resolved.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement, so this page does not list specific cases.

Risk-wise, weak configuration control increases the chance of preventable compromise paths (default settings, exposed management services, weak authentication posture) and can also create CMMC assessment risk if you cannot show consistent enforcement and evidence. The most common failure mode in practice is not “no hardening,” but “hardening happened once and drifted.” CMMC assessments reward repeatable mechanisms and clean evidence packaging. ^{2 3}

Practical 30/60/90-day execution plan

First 30 days (stabilize scope and baselines)

• Confirm the CUI environment boundary and list in-scope product families. ²
• Assign an owner per product family (IT ops, cloud, network, endpoint).
• Publish baseline templates and an exception template.
• Draft baselines for the highest-risk/highest-volume assets (endpoints, identity, remote access, firewalls).

Days 31–60 (enforce and instrument)

• Implement enforcement mechanisms per baseline (GPO/MDM, network templates, cloud org policies, IaC controls).
• Turn on configuration compliance reporting for each tool and define a remediation workflow.
• Start collecting evidence artifacts in a single repository aligned to 3.4.2 (baseline + enforcement proof + reports). Daydream can manage control mapping and recurring evidence requests so owners submit the right artifacts on time.

Days 61–90 (prove operations and close gaps)

• Run a drift-detection cycle: find out-of-policy settings, remediate, and retain ticket evidence.
• Review and formalize exceptions; remove expired or unnecessary exceptions.
• Run an internal “mini-assessment” walkthrough: pick one device/resource per product family and trace baseline → enforcement → compliance report → remediation sample.

Frequently Asked Questions

Do we need a CIS benchmark to satisfy 3.4.2?

The requirement is to establish and enforce security configuration settings, not to adopt a specific benchmark. A benchmark can help, but assessors care most that your baselines are approved, implemented, and enforced with evidence. ¹

What counts as “enforcement” versus a documented standard?

Enforcement means the settings are applied through technical control points (MDM/GPO/templates/IaC policies) and you can detect and correct drift. A PDF baseline without tooling and monitoring rarely holds up in assessment.

How do we handle SaaS products where we can’t control every setting?

Document the settings you can control (admin console configuration, tenant security settings, conditional access equivalents) and show how you review and maintain them. For gaps, document compensating controls or choose a different product for the CUI environment.

Are one-time hardening scripts enough?

One-time scripts can help establish a baseline, but you still need a way to keep systems aligned over time through management tooling, compliance checks, and remediation workflow evidence.

How do we scope “information technology products” for this practice?

Start with systems that store/process/transmit CUI and then include systems that administer or secure that environment (identity, endpoint management, network security tooling). Keep the scope defensible and consistent with your CMMC boundary documentation. ²

What evidence is most persuasive to an assessor?

A versioned baseline, the actual enforced configuration object (policy/profile/template), and a current compliance report with at least one example remediation ticket. That combination demonstrates design and operating effectiveness. ¹

Footnotes

1. NIST SP 800-171 Rev. 2

2. DoD CMMC Program Guidance

3. 32 CFR Part 170