CM.L2-3.4.2 is about enforcement. You have security configuration baselines in place (that’s CM.L2-3.4.1). Now you need to push those baselines out to your devices and make sure they stay in place. This means using management tools to enforce settings centrally, monitoring for changes, and taking action when devices drift out of compliance.
For small contractors, this typically means Intune for cloud-managed devices, Group Policy for domain-joined Windows machines, or a combination of both. In practice, this control doesn’t get deep scrutiny in most assessments. The assessor mainly wants to see that you have a standard build and can show the policy specs that enforce it on each endpoint. CIS benchmarks and DISA STIGs haven’t been a major assessment topic for most small contractors, though referencing them strengthens your position.
What the assessor is actually evaluating
The assessor is looking for evidence that your security configurations are actively enforced across devices, not just defined in a policy document. Specifically, they want to see:
- What settings are you enforcing? Can you show a list of enforced settings that aligns with your baselines?
- How are they pushed? What tool or process ensures devices receive and maintain these configurations?
- What happens when devices drift? Do you detect when a setting changes, and do you re-enforce it or block device access?
- What are the consequences for non-compliance? Do non-compliant devices lose access to organizational resources?
Intune compliance policies and configuration profiles are the modern answer. Group Policy works well for domain-joined machines. For cloud-only environments, Intune is where this enforcement happens. The assessor expects you to have compliance dashboards showing device status.
Common enforced settings at the L2 level include screen lock timeout (10-15 minutes), password complexity, BitLocker or full-disk encryption, firewall enabled, automatic updates enabled, and restrictions on USB or removable media.
How to present your evidence
- Compliance dashboard. Export a screenshot from Intune or Group Policy showing device compliance status. Make sure the dashboard clearly shows the enforced configurations and which devices are compliant.
- Policy document. Provide a copy of your baseline configurations (from CM.L2-3.4.1). Cross-reference this with the enforced configurations in Intune or Group Policy.
- Enforcement mechanism. Show the Intune compliance policy or Group Policy Object (GPO) that implements these settings. Include the specific settings being enforced (not just the name of the policy).
- Drift detection and remediation. Show how you monitor for drift. If a device falls out of compliance, what happens? Does Intune re-enforce the setting? Do you have Conditional Access rules that block access?
- Conditional Access rules. If you’re using Intune, show the Conditional Access policies that require device compliance. This ties enforcement to access control.
All Windows devices that access or process CUI are managed through Microsoft Intune and joined to our Azure AD tenant. We have defined baseline configurations for Windows 10/11 devices, including password policy (minimum 12 characters, complexity required), screen lock timeout (10 minutes), BitLocker encryption, Windows Defender Firewall enabled, and automatic Windows Update scheduling for Patch Tuesdays. These configurations are enforced through Intune compliance policies and configuration profiles. All domain-joined machines are managed via Group Policy Objects that enforce the same baseline settings. Compliance status is monitored daily through Intune dashboards. Devices that fall out of compliance are automatically remediated through Intune; if remediation fails, the device is blocked from accessing organizational email and cloud resources via Conditional Access rules. For contractors and remote workers, enrollment in Intune is required before access to CUI systems is granted.
Common failures
Configurations documented but not enforced. You have a security policy document that lists all the settings devices should have, but you’re not pushing those settings through Intune or Group Policy. The settings might be configured on devices manually, but there’s no ongoing enforcement or drift detection. The assessor will ask: “If I change this setting on my device, what happens?” If the answer is nothing, you fail this practice.
No drift detection. You enforced baseline configurations six months ago via Intune or GPO, but you don’t actively monitor whether devices still comply. A user disables Windows Defender Firewall, and you never know. Without drift detection, you can’t prove enforcement is active.
BYOD devices with no MDM. You have personal devices accessing CUI without any management tool enforcing security configurations. Even if users are required to follow security policies, there’s no technical enforcement.
Compliance policies without consequences. Intune shows device compliance status, but non-compliant devices still have full access to everything. Enforcement requires teeth—if you’re not blocking access or remediating drift, you’re not really enforcing.
Non-standardized enforcement. You enforce baselines on some machines via Intune and others via manual configuration scripts or manual patching. This is inconsistent and difficult to audit.
If you use an MSP or MSSP
Your MSP or MSSP typically manages Intune or Group Policy configuration and can provide compliance dashboards showing which devices meet your baselines. When you work with them, make sure you have written agreements defining:
- What baseline configurations they will enforce.
- How frequently they monitor compliance.
- What actions they take when devices fall out of compliance (re-enforce, alert you, block access).
- How they report compliance status to you for your own records.
Your MSP should be able to provide compliance reports on demand. During an assessment, you should be able to run a report showing device compliance yourself, not just rely on the MSP. If your MSP blocks access to non-compliant devices via Conditional Access, make sure you understand how that rule works and can explain it to the assessor.
Keep answers short. Show the evidence, don't describe it. Let the assessor drive. For more on how to present in the assessment room, see How to Present Evidence in the Assessment Room.
Q&A: What the assessor asks and what good answers sound like
Disclaimer: This guidance is provided for informational purposes to help organizations prepare for CMMC assessments. It is not a substitute for official CMMC documentation, NIST guidelines, or professional security advice. Organizations should consult with qualified CMMC assessors and security professionals to ensure their practices meet CMMC requirements in their specific context. Requirements and assessment criteria may change; verify against the official CMMC standards and your assessment scope.