How to Enforce Device Compliance Policies in Microsoft Intune for CMMC and DFARS

Why Device Compliance Enforcement Matters for Defense Contractors

If your organization handles Controlled Unclassified Information, every endpoint that touches that data is a potential liability. Microsoft Intune gives defense contractors a powerful platform for defining, enforcing, and documenting device compliance — but the tool alone does not make you compliant. The policies behind it do.

For contractors subject to CMMC, CUI, and DFARS requirements, Intune compliance policies translate directly into demonstrable controls. When a C3PAO auditor or DCSA reviewer asks how you enforce configuration standards across endpoints, a well-configured Intune environment backed by documented policy is one of the strongest answers you can give.

This post walks through the practical steps to configure and enforce device compliance policies in Microsoft Intune aligned to CMMC 2.0 Level 2 and DFARS 252.204-7012 requirements.

Understanding the Regulatory Connection

CMMC 2.0 Level 2 maps directly to NIST SP 800-171, which includes controls across configuration management, access control, identification and authentication, and system and communications protection. Many of these controls require you to enforce specific device states — encrypted storage, minimum OS versions, active antivirus, screen lock timeouts, and more.

DFARS 252.204-7012 requires contractors to implement adequate security that is at minimum consistent with NIST SP 800-171. That means device compliance is not optional. Failing to enforce it is not a gap in your configuration. It is a contractual deficiency.

For a deeper look at how these frameworks overlap, the comparison of DFARS 252.204-7012 and CMMC 2.0 is worth reviewing before you start building your Intune policy set.

Step 1: Define Your Compliance Baseline Before You Configure Anything

The most common mistake organizations make is jumping into the Intune console before they have defined what compliance means in their environment. Before you create a single policy, answer these questions:

• Which devices are in scope for CUI access?
• What operating systems and versions are authorized?
• What is the minimum acceptable encryption standard?
• Are personally owned (BYOD) devices permitted, and if so, under what conditions?
• What is your policy for non-compliant devices — block access, notify, or quarantine?

Your answers feed directly into Intune compliance policy settings and Conditional Access rules. Document your baseline in your System Security Plan. Auditors will look for this alignment between your written policies and your technical configuration. If you have not yet developed a formal SSP, our post on SSP and POA&M fundamentals provides a solid starting framework.

Step 2: Create Platform-Specific Compliance Policies in Intune

Microsoft Intune applies compliance policies per platform. You will need separate policies for Windows 10/11, iOS/iPadOS, Android, and macOS if those platforms exist in your environment. For most defense contractors, Windows is the primary focus, but mobile device management requirements under CMMC apply to any device accessing CUI.

Windows Compliance Policy Settings to Prioritize

For CMMC alignment, your Windows compliance policies should enforce the following at a minimum:

• BitLocker encryption required — Maps to NIST SP 800-171 control 3.13.16 (protect CUI at rest)
• Secure Boot enabled — Supports system integrity and boot integrity controls
• Code integrity enabled — Prevents unauthorized code from loading at startup
• Minimum OS version — Enforce a supported, patched OS baseline; do not permit end-of-life versions
• Antivirus and antispyware active and up to date — Required under CMMC SI (System and Information Integrity) domain
• Firewall enabled — Directly supports access control and boundary protection requirements
• Password complexity and lockout settings — Maps to IA (Identification and Authentication) controls under NIST SP 800-171
• Microsoft Defender real-time protection active — Supports malicious code protection requirements

These settings are not theoretical. They correspond to specific NIST SP 800-171 controls that C3PAO assessors will evaluate. For a breakdown of what assessors actually examine, see what CMMC assessors look for by domain.

Step 3: Configure Conditional Access to Enforce Compliance

A compliance policy without Conditional Access enforcement is a policy that cannot actually block access. Intune compliance policies alone mark a device as compliant or non-compliant — they do not block access by themselves. That enforcement layer comes from Azure Active Directory Conditional Access.

Configure Conditional Access policies to require that devices be marked compliant by Intune before they can access Microsoft 365, SharePoint, Teams, or any other application that may host CUI. Key Conditional Access configurations for CMMC environments include:

• Require compliant device for all cloud app access
• Block legacy authentication protocols, which bypass modern authentication controls
• Require multi-factor authentication for all users (mandatory under CMMC Level 2)
• Restrict access from non-managed or non-compliant devices to CUI repositories
• Apply sign-in risk and user risk policies where Microsoft Entra ID P2 licensing is available

This enforcement model also intersects with your Data Loss Prevention strategy. For more on protecting CUI at the application layer, see our guide on understanding Data Loss Prevention.

Step 4: Set Non-Compliance Actions and Grace Periods Deliberately

Intune allows you to configure what happens when a device falls out of compliance. Your options include marking the device non-compliant immediately, sending a notification, remotely locking the device, or retiring it. You can also configure grace periods.

For a CMMC environment, grace periods must be used carefully. A grace period that allows non-compliant devices to continue accessing CUI — even temporarily — creates a real vulnerability and a potential audit finding. Define grace periods only for non-critical compliance violations, such as an OS update that requires a scheduled maintenance window. For encryption or antivirus failures, the non-compliance action should be immediate access restriction.

Document your non-compliance action logic in your SSP and make sure it is reviewed as part of your ongoing compliance monitoring program. This is precisely the kind of operational detail that separates contractors who pass audits from those who do not.

Step 5: Use Compliance Reporting and Monitoring Continuously

Intune provides built-in compliance reports that show device status, policy assignment status, and trend data. For CMMC purposes, this reporting is not optional background noise — it is evidence. When an assessor asks whether you monitor endpoint compliance, your Intune dashboard and exported reports are part of the answer.

Establish a regular review cadence for compliance reports. Flag persistent non-compliance, investigate root causes, and document remediation. Integrating Intune compliance data with Microsoft Sentinel or your SIEM, if applicable, strengthens your continuous monitoring posture further.

For contractors looking to understand how endpoint security fits into the broader compliance picture, that foundational context helps frame why continuous monitoring is not a nice-to-have — it is a CMMC requirement under the Audit and Accountability domain.

Step 6: Document Everything for Your System Security Plan

Every compliance policy you configure in Intune needs a corresponding entry in your System Security Plan. The SSP must describe the control, how it is implemented, and what system or tool enforces it. Screenshots of Intune policy configurations, exported compliance reports, and Conditional Access rule documentation all serve as supporting evidence during a CMMC assessment.

If your SSP currently has placeholder language like "endpoint compliance is enforced through MDM," that is not sufficient. Assessors will ask for specifics. Your documentation needs to name the tool, describe the policy settings, and explain how the enforcement mechanism works. Organizations that have gaps in SSP documentation tied to Intune are commonly cited in readiness assessments. For more on what that documentation needs to look like, see the complete list of documentation required for CMMC certification.

Common Intune Configuration Mistakes That Create Compliance Risk

Based on what we see in the field, here are the most frequent Intune compliance mistakes at defense contractors:

1. Compliance policies assigned but Conditional Access not configured — The policy marks devices non-compliant but nothing is blocked.
2. BYOD devices excluded from compliance scope — If a personal device accesses CUI, it must be managed or access must be blocked.
3. Grace periods too long — Devices with expired antivirus or disabled encryption remain in production.
4. No documentation linking Intune settings to NIST SP 800-171 controls — Technical configurations exist but are not mapped in the SSP.
5. Legacy authentication not blocked — MFA enforcement is bypassed by protocols that do not support modern authentication.

Get Expert Help Configuring Intune for CMMC

Microsoft Intune compliance is one component of a much larger CMMC compliance program. Getting the technical configuration right matters, but it has to be aligned to your written policies, your SSP, and your broader security controls framework. At Cleared Systems, our team helps defense contractors configure Intune environments that satisfy assessors, document configurations that hold up under audit, and build the compliance programs behind the technology.

If you are preparing for a CMMC assessment or working to close gaps in your current endpoint compliance posture, our IT compliance services are built for exactly this kind of engagement. You can also review our engagement models to find the right fit for your organization's size, timeline, and budget. Contact Cleared Systems today to schedule a consultation with a compliance specialist who understands both the technical and regulatory sides of CMMC endpoint management.