Azure Conditional Access for CMMC: Practical Configuration for the Controls That Trip Up Most Organizations

Where Azure Meets CMMC

For organizations running Microsoft 365 and Azure AD (now Entra ID), conditional access policies are the primary enforcement mechanism for a significant number of CMMC Level 2 controls. Access control, identification and authentication, system and communications protection: conditional access touches all of them.

The challenge is that most organizations either over-configure (locking down so aggressively that users can't work) or under-configure (deploying a handful of policies that cover the obvious cases but miss the edge conditions assessors will test). This article walks through the practical configuration decisions that matter for CMMC.

The Controls Conditional Access Addresses

Conditional access policies directly support implementation of several NIST SP 800-171 control families. The most relevant ones:

AC.L2-3.1.1 (Authorized Access Control): Limiting system access to authorized users. Conditional access enforces this by requiring specific conditions (device compliance, location, MFA) before granting access to resources.

AC.L2-3.1.3 (Control CUI Flow): Controlling CUI data flows. Conditional access can restrict which devices and locations can access CUI-bearing applications, preventing access from unmanaged devices or untrusted networks.

IA.L2-3.5.3 (Multi-Factor Authentication): MFA for all users accessing CUI systems. Conditional access is the policy engine that enforces MFA requirements based on user, application, device, and risk conditions.

AC.L2-3.1.18 (Mobile Device Connection): Controlling connection of mobile devices. Conditional access combined with Intune compliance policies restricts access from mobile devices that don't meet security baselines.

Policy Architecture That Works

Rather than building dozens of granular policies, organize your conditional access around three tiers:

Tier 1: Baseline (all users, all apps)

These apply universally. Every user, every cloud app, no exceptions except break-glass accounts.

Require MFA for all users. This is non-negotiable for CMMC. Use "Require authentication strength" with phishing-resistant MFA (FIDO2, Windows Hello, certificate-based) as your target, with standard MFA as the minimum.

Block legacy authentication. Legacy protocols (IMAP, POP3, SMTP basic auth) don't support MFA and are a common attack vector. Block them entirely via conditional access.

Require compliant devices for access to all cloud applications. This ensures only Intune-managed, policy-compliant devices can access your environment.

Tier 2: CUI-specific (CUI applications, CUI users)

These apply to the applications and user groups that handle CUI. Scope them using security groups and application assignments.

Block access from non-compliant or unmanaged devices to CUI applications (SharePoint sites, Teams channels, specific SaaS apps where CUI is processed).

Restrict access to approved locations. If CUI processing should only occur from corporate networks or approved remote locations, use named locations to enforce geographic and IP-based restrictions.

Require app protection policies for mobile access. If mobile access to CUI is permitted, require Intune app protection policies that enforce encryption, prevent copy/paste to unmanaged apps, and require PIN/biometric authentication.

Tier 3: Administrative (privileged accounts)

Privileged accounts (Global Admin, Exchange Admin, Security Admin) get the strictest policies.

Require phishing-resistant MFA. Standard MFA is not sufficient for admin accounts under CMMC. Require FIDO2 keys or Windows Hello for Business.

Restrict to compliant devices and approved locations. Admin actions should only occur from managed workstations on trusted networks.

Block persistent browser sessions. Force re-authentication for admin accounts to limit session hijacking risk.

The Gaps Assessors Find

Even organizations with conditional access deployed commonly have these gaps:

Break-glass accounts without monitoring. Every environment needs emergency access accounts that bypass conditional access. But assessors want to see that these accounts are monitored via alerting, that their credentials are stored securely, and that usage is reviewed. A break-glass account with no monitoring is an uncontrolled privileged access path.

Guest and external user gaps. Conditional access policies often focus on internal users and miss B2B guest accounts. If external collaborators access CUI-bearing Teams channels or SharePoint sites, they need to be covered by conditional access policies with equivalent rigor.

App-specific gaps. Organizations deploy broad policies but miss specific applications. That third-party engineering tool that accesses Azure AD for authentication? If it handles CUI and isn't covered by conditional access, it's a gap.

No regular policy review. Conditional access policies configured during initial deployment and never reviewed. As the environment evolves (new apps, new user groups, new locations), the policies drift from the documented security posture. Assessors want to see evidence of periodic review.

Testing Before Assessment Day

Before your C3PAO walks in, test every conditional access policy against the actual assessment scenarios:

Can a user access CUI from an unmanaged personal device? (Should be blocked.)

Can a user access CUI without MFA? (Should be impossible.)

Can a legacy authentication client connect to Exchange? (Should be blocked.)

Can a guest user access a CUI-bearing SharePoint site from an unmanaged device? (Should be blocked.)

Can an admin perform privileged operations from a non-compliant device? (Should be blocked.)

Document the test results. Assessors appreciate seeing evidence that the organization has validated its own controls, not just configured them.