Conditional Access Policies for CMMC Compliance & Audit Evidence

If you handle CUI, your sign-in rules can’t be “best effort.” They have to be enforceable, repeatable, and easy to prove to an assessor.

For many DoD contractors I work with (especially teams doing Office 365 Migration and ongoing Cloud Management), Microsoft Entra ID Conditional Access becomes the front door. It controls who can sign in, from what device, and under what conditions. Done right, it also produces the audit trail you’ll need for CMMC Level 2.

Quick disclaimer up front: Conditional Access supports CMMC controls, but it doesn’t guarantee compliance by itself. It depends on device compliance, strong MFA methods, logging and monitoring, and documented procedures.

CMMC 2.0 basics, scoping, and where Conditional Access fits

CMMC 2.0 has three levels. In plain terms, Level 1 is basic protection for FCI, Level 2 is the big one for most contractors handling CUI (aligned to NIST SP 800-171 Rev. 2), and Level 3 is for the highest-risk programs.

As of January 2026, CMMC is no longer theoretical. The rollout is underway, with CMMC requirements showing up in new DoD contracts starting in Phase 1 (Nov 2025 to Nov 2026), and more contracts shifting toward third-party C3PAO assessments starting in Phase 2 (Nov 2026). That timing matters because Conditional Access takes planning, testing, and evidence collection, not a weekend change window.

Where does Conditional Access help most? It supports the parts of CMMC that live in the identity layer:

• Access Control (AC): who gets in, from what device, and to which apps.
• Identification & Authentication (IA): MFA, stronger methods, admin sign-in rules.
• Audit & Accountability (AU): sign-in logs, policy change logs, review records.

Microsoft has been publishing CMMC-focused Entra guidance, including an overview on configuring Microsoft Entra ID for CMMC compliance and deeper sections like CMMC Level 2 access control configuration.

The part that trips teams up is scoping. Before I write a single policy, I want a clean answer to: what systems touch CUI, and which identities can reach them? If scoping is fuzzy, policies become a mess of exclusions, and exclusions become your audit risk.

Simple scoping approach for DoD contractors using Microsoft 365

I keep scoping practical and tied to the SSP:

• List the CUI apps and locations: SharePoint, OneDrive, Teams, Exchange, and any SaaS or line-of-business apps where CUI lands.
• Define in-scope users: employees, admins, vendors, and guest users. If they can touch CUI, they’re in scope.
• Define allowed devices: Intune-managed endpoints, hybrid-joined devices, and approved mobile devices with Endpoint Security controls.

This is where Endpoint Security and Device Hardening stop being “IT hygiene” and become access requirements. Conditional Access can require a compliant device, but it can’t make a device compliant. Intune, baselines, encryption, patching, and secure configs do that.

Conditional access cmmc mapping table you can paste into your SSP

CMMC family focus	Conditional Access capability	Example policy name	Evidence artifact to show an assessor
IA (MFA expectation)	Require MFA for sign-ins to CUI apps	CA-03 Require MFA for CUI Apps	Policy export, sign-in logs showing “MFA required” result
IA / AC	Block legacy authentication	CA-02 Block Legacy Authentication	Policy export, sign-in logs showing legacy auth blocked
AC (device-based access)	Require compliant or hybrid-joined device	CA-04 Require Compliant Device for CUI	Intune compliance report, sign-in logs showing “device compliant” requirement
IA / AC (admins)	Protect privileged roles with stricter rules	CA-05 Privileged Role Sign-In Protection	Role assignments, policy export, admin sign-in logs
AU (reviewable logging)	Centralize sign-in and audit logs	LOG-01 Forward Entra Logs to SIEM	SIEM ingestion proof, alert rules, review records

If you want additional context on common implementations, this Conditional Access and CMMC overview is a useful cross-check, but I always validate it against your actual scope and contract language.

Prerequisites and architecture for an assessor-ready Conditional Access setup

For Small Business IT teams, the fastest path is to treat Conditional Access like part of Secure Cloud Architecture, not a single toggle. In my Technology Consulting work, I frame this as Infrastructure Optimization with proof attached.

Identity, device, and app foundations (Entra ID, Intune, and CUI app list)

Conditional Access only works as well as your identity and device inventory:

• Identity foundation: clean user lifecycle, no shared admin accounts, and clear groups like “CUI Users” and “Privileged Admins.” If you’re hybrid, sync should be stable and documented.
• Device foundation: Intune enrollment, compliance policies (encryption, screen lock, OS version), and baseline hardening. This is where Endpoint Security becomes measurable.
• App foundation: a confirmed list of cloud apps that store or process CUI, including third-party SaaS.

I also separate environments on purpose. A restaurant business might rely on Restaurant POS Support and Kitchen Technology Solutions, and those systems should not become an unmanaged side door into CUI. The rule is simple: if it touches CUI identities or devices, it falls under the same access policies.

Licensing and logging retention, plus SIEM options for CMMC evidence

Most Conditional Access features require Entra ID P1. Risk-based controls often require P2. Device compliance typically needs Intune or a suite that includes it.

Logging is where many teams fail audits. Entra has retention limits, so I usually forward sign-in and audit logs to a SIEM (Microsoft Sentinel or another platform). Retention should match your policy, many teams target 90 days to 1 year or more, based on contracts and risk. This ties directly to Business Continuity & Security and helps in incident response, not just audits. Microsoft’s CMMC-focused Entra material on additional Level 2 controls is a helpful reference point for what evidence reviewers expect.

My recommended Conditional Access policy set for CMMC, rollout plan, and audit evidence

When I build a conditional access cmmc baseline, I focus on two goals: block unsafe access by default, and produce clear evidence without manual heroics. I roll it out in phases so production doesn’t explode.

Step-by-step Conditional Access policies (sample names and settings)

1. CA-01 Baseline MFA for All Users: Target all users, require MFA. Exclude two break-glass accounts. Prefer phishing-resistant MFA where possible (FIDO2 keys), otherwise authenticator app.
2. CA-02 Block Legacy Authentication: Block legacy clients and legacy protocols that bypass modern MFA. This closes a common “quiet” gap.
3. CA-03 Require Compliant or Hybrid-Joined Device for CUI Apps: Target “CUI Users” and your CUI apps, require device compliance (Intune) or hybrid-joined state. Block unmanaged devices for CUI.
4. CA-04 Privileged Role Sign-In Protection: Target directory roles, require strong MFA and compliant device. If you have P2, add sign-in risk controls, then document how you review alerts.
5. CA-05 Guest Access to Collaboration Apps: Require MFA for guests, limit guest access to the specific sites/teams needed. For sensitive CUI locations, consider web-only access and stricter session limits.
6. CA-06 Location Controls: Use named locations for known networks (office, VPN egress). Block impossible or clearly risky geographies if your policy allows, but don’t overuse location rules as a crutch.
7. CA-07 Session Controls for Data Protection: For unmanaged devices, restrict downloads and apply session controls through Defender for Cloud Apps where it fits your risk model.

Rollout phases I use: Report-only for baseline and legacy blocks, then a pilot group, then full enforcement. I tighten exclusions every week until only documented exceptions remain.

Break-glass approach: Two cloud-only emergency accounts, long random passwords stored in a protected vault, excluded from Conditional Access, monitored with alerting, and used only with a written SOP and a ticket.

Evidence for assessors, common pitfalls, compensating controls, and my quick checklist

Evidence for Assessors (what I export and how often)

• Conditional Access policy export or screenshots (on change, and quarterly review)
• Entra sign-in logs showing MFA prompts and policy results (weekly sampling)
• Audit logs for admin changes to policies (weekly)
• MFA registration reports (monthly)
• Intune compliance reports for in-scope devices (weekly or monthly)
• SIEM dashboards and alert rules (monthly review evidence)
• Change tickets and written SOPs for access reviews and break-glass use

Common pitfalls I see

• Legacy auth left on “for one device”
• Too many exclusions, especially for executives and service accounts
• Unmanaged BYOD still allowed for CUI apps
• Relying on per-user MFA instead of Conditional Access
• No log forwarding, or retention too short to support AU review
• No written procedures, so controls can’t be shown as repeatable

Compensating controls (when you must document an exception)

• App passwords disabled, mailbox protocol restrictions enforced
• MDM required for mobile access, app protection policies where needed
• Sensitivity labels and DLP for CUI locations
• Defender for Cloud Apps session controls for unmanaged endpoints
• Approved exceptions with dates, owners, and review cadence

Implementation checklist

• Scope CUI apps, users, and devices, align to the SSP
• Entra groups for CUI users and privileged admins
• Intune compliance policies plus Device Hardening baselines
• Baseline MFA and admin protections enforced
• Guest access rules documented and restricted
• Session controls for unmanaged devices where appropriate
• Logs forwarded to SIEM with defined retention
• Review cadence set, evidence captured, SOPs written

Conclusion

When I’m trying to make conditional access cmmc work in the real world, I treat Conditional Access as my “policy gate” for CUI. It helps me prove enforceable MFA, device-based access limits, and repeatable audit evidence, which is exactly what CMMC assessors want to see.

It’s still not a full compliance solution. You’ll only pass if device compliance, Endpoint Security, logging, monitoring, and written procedures are all in place. If you want help from a Business Technology Partner, I can run a scope review, build a rollout plan, and provide ongoing monitoring as part of Cybersecurity Services and Cloud Management for small and mid-sized contractors.