Microsoft 365 for CMMC Level 2: Which Settings Satisfy Which Practices

M365 handles most of the technical controls for CMMC Level 2. The question is which specific settings satisfy which practices - and where M365 alone is not enough. This is that guide, written by someone with an AZ-500 cert and real implementation experience.

Most CMMC content focuses on what controls you need. This post is about how to actually implement them in Microsoft 365 - the platform most defense contractors are already running. Because knowing that practice 3.5.3 requires multifactor authentication is one thing. Knowing exactly which M365 policy to turn on, where to find it, and what it needs to say to satisfy a C3PAO assessor is another.

This post maps NIST SP 800-171 Rev 2 practices to specific Microsoft 365 features, organized by CMMC domain. Where a practice maps cleanly to an M365 setting, we will tell you what it is. Where M365 alone is not sufficient, we will say that too.

Access Control (AC) - 3.1.x

The Access Control domain has 22 practices and maps heavily to Azure Active Directory (now Entra ID) and Conditional Access.

3.1.1 - Limit access to authorized users: Azure AD user accounts with proper provisioning and deprovisioning workflows. Entra ID Governance handles lifecycle management. Every user who touches CUI needs an account tied to their identity - no shared accounts, no generic logins. The "admin@company.onmicrosoft.com" default account that nobody ever locked down is exactly what assessors look for first.

3.1.3 - Control CUI data flow: Microsoft Purview Information Protection. Label CUI-bearing content with sensitivity labels, configure label policies to block external sharing of labeled items. This is not a checkbox you tick once - it requires training users to apply labels and auditing that they do.

3.1.12 through 3.1.15 - Remote access controls: Conditional Access policies. Require compliant devices (Intune enrollment), block legacy authentication protocols, restrict access by location or device state. A Conditional Access policy that requires MFA + compliant device for all remote access covers multiple practices at once.

3.1.19 - Encrypt CUI on mobile devices: Intune device compliance policies with encryption requirements. iOS and Android both support BitLocker/device encryption enforced through MDM profiles. If a mobile device is not encrypted, Intune can block it from accessing corporate resources until it is.

Identification and Authentication (IA) - 3.5.x

This is where M365 shines. The IA domain maps almost directly to Entra ID and M365 authentication policies.

3.5.3 - Multifactor authentication: Entra ID MFA, enforced via Conditional Access. "Security Defaults" is not sufficient for CMMC - it is a good start, but you need granular Conditional Access policies that enforce MFA for all users, not just administrators, and that you can document and evidence. Create a named CA policy, document it in your SSP, and retain screenshots as evidence. Assessors want to see the policy, not just hear that MFA is on.

3.5.7 - Password complexity: Entra ID Password Protection. Configure the banned password list and complexity requirements through Azure AD password policies. If using AD on-premises synced to Entra, configure password policies through Group Policy and ensure password hash sync is enabled.

3.5.10 - Cryptographically protected passwords: This is handled by Entra ID's underlying infrastructure for cloud accounts. For hybrid environments, ensure NTLM is disabled where possible and Kerberos is the authentication protocol of record. The key thing assessors look for is that passwords are not stored or transmitted in plaintext anywhere in the environment.

Audit and Accountability (AU) - 3.3.x

The AU domain requires comprehensive logging - and M365 has the logging, but you need to turn it on, retain it long enough, and have a process for reviewing it.

3.3.1 - Create and retain audit logs: Microsoft Purview Audit (formerly Unified Audit Log). Must be explicitly enabled - it is not on by default in all tenants. Go to the Microsoft Purview portal and confirm audit logging is enabled. Retention: Standard Audit retains logs for 90 days. For CMMC you want longer - Audit Premium (E5 or add-on) extends to one year. If you cannot afford E5, export logs to Azure Storage or a SIEM regularly.

3.3.2 - Trace actions to individual users: The unified audit log captures user principal names for all logged events. Ensure no shared mailboxes or shared credentials are used to perform administrative actions, or those actions cannot be attributed to an individual.

3.3.5 - Correlate audit records for investigation: Microsoft Sentinel (Azure SIEM) is the enterprise answer here. For smaller contractors who cannot justify Sentinel's cost, a third-party SIEM that ingests M365 logs (Huntress MDR, for example) can satisfy this practice more affordably. "Correlation" at minimum means you can answer: "What did user X do on date Y, across all systems?"

Configuration Management (CM) - 3.4.x

3.4.1 - Baseline configurations: Intune Configuration Profiles. Document your baseline - which settings are required, what the defaults are, what deviations are approved. The documentation of the baseline is as important as the baseline itself. Assessors will ask to see your documented configuration baseline, not just your Intune portal.

3.4.6 and 3.4.7 - Least functionality and disabling nonessential services: Microsoft 365 has a sprawling feature set and many connectors and integrations enabled by default. Review the M365 Admin Center for connectors, third-party integrations, and OAuth app permissions. Anything that does not have a documented business need should be disabled. This includes legacy protocols: Basic Authentication was deprecated by Microsoft, but legacy auth connectors may still be active in older tenants.

3.4.8 - Deny unauthorized software: Microsoft Defender Application Control (WDAC) or AppLocker for Windows endpoints. Requires planning and testing but is increasingly expected for mature CMMC implementations. At minimum, a documented application whitelist policy that is enforced via technical controls satisfies this practice better than a policy document alone.

System and Communications Protection (SC) - 3.13.x

3.13.8 - Encrypt CUI in transit: M365 uses TLS 1.2+ for all communications by default. Confirm your email connectors and SharePoint/OneDrive configurations enforce TLS. For email, configure transport rules to require TLS for domains that handle CUI. Use the Exchange Admin Center's connector settings to enforce encrypted connections with specific partners.

3.13.11 - FIPS-validated cryptography: Windows and M365 can be configured to use FIPS 140-2 validated cryptographic modules. Enable FIPS compliance mode in Windows Security Policy. Note that this can break some applications - test thoroughly before deploying broadly. M365 services running in GCC/GCC High are operated in FIPS-compliant environments by Microsoft.

3.13.16 - Protect CUI at rest: BitLocker for Windows devices (enforced via Intune), Azure Storage Service Encryption for cloud data, and SharePoint encryption (handled by Microsoft for GCC tenants). Confirm BitLocker is enabled on all endpoints that may store CUI, with recovery keys escrowed in Entra ID or MBAM.

System and Information Integrity (SI) - 3.14.x

3.14.2 - Malicious code protection: Microsoft Defender for Endpoint. For CMMC, Defender should be in active mode (not passive), with cloud-delivered protection enabled, real-time protection on, and tamper protection enabled to prevent users from disabling it. Document the Defender configuration in your SSP and retain evidence screenshots.

3.14.6 - Monitor for attacks: Microsoft Defender for Endpoint's advanced hunting and alert management. At minimum, someone needs to be reviewing Defender alerts regularly - this is not a set-and-forget tool. For small contractors without a SOC, an MDR provider that monitors Defender telemetry is a practical answer.

What M365 Does Not Cover

Microsoft 365 is powerful, but it does not solve everything. Practices that typically require additional tools or processes beyond M365:

• 3.11.2 - Vulnerability scanning: M365 Defender has some vulnerability management (Defender Vulnerability Management), but you likely need a dedicated scanner like Tenable Nessus or Qualys for full network coverage.
• 3.6.1 - Incident response capability: M365 has playbooks and automation, but an IR plan is a people-and-process requirement, not just a technology one. You need a documented IR Plan, defined roles, and tested procedures.
• Physical protection (PE) practices: M365 has nothing to say about who has physical access to your server room or whether visitors are escorted. Those are on-site controls.
• 3.4.1 - Documented baselines: Intune can enforce configurations, but someone has to write the documentation. A System Security Plan describing every configuration decision is required regardless of how well your Intune is configured.