CMMC Level 2 Device Risk in Entra Conditional Access

A stolen password should not open the door to Controlled Unclassified Information. When I help teams build CMMC conditional access controls, I want identity, device health, and audit evidence to work together, not sit in separate dashboards.

That is where Microsoft Defender for Endpoint, Intune, and Microsoft Entra Conditional Access fit well. Used correctly, they can block risky or unmanaged devices from reaching Microsoft 365 resources, while giving me clean evidence for a Level 2 assessment. The details matter, so I’ll start with where this control fits and where it does not.

Key Takeaways

• Defender for Endpoint feeds device risk into Intune, and Intune marks the device compliant or noncompliant. Entra Conditional Access then uses that status to allow or block access.
• For CUI-facing Microsoft 365 apps, I usually require MFA and a compliant device, with Intune set to allow only devices at Low risk or better.
• BYOD, emergency access accounts, and legacy service patterns need separate handling. I document them as exceptions, not quiet bypasses.
• Good audit evidence includes Entra sign-in logs, Conditional Access results, Intune compliance reports, Defender device data, and change records.
• This control supports CMMC Level 2, but it is not a full compliance program by itself.

Where device risk fits in a CMMC Level 2 program

CMMC Level 2 is about protecting CUI with a real set of operational controls, not a marketing badge. Conditional access tied to device health helps most with access control, endpoint protection, and the discipline of restricting data to approved users on approved systems.

I never position this as a complete answer. It is one strong control inside a larger system that also needs policies, training, incident response, vulnerability management, documentation, and evidence. A front gate matters, but the gate is not the whole fence.

Microsoft maps Entra capabilities to CMMC practices in its CMMC Level 2 access control guidance and its additional Entra controls for CMMC Level 2. Those references are useful because they keep the conversation grounded in actual practice mappings instead of vague security claims.

For most organizations I work with, the practical goal is simple. If a user handles CUI, I want that person to sign in with strong authentication from a device that meets policy, reports into management, and does not carry an elevated risk signal. That supports the idea behind limiting users to permitted functions and approved systems.

Device risk is not a compliance certificate. It is a live signal that helps me decide whether a device should reach protected resources right now.

That distinction matters during assessments. An assessor may appreciate that risky devices are blocked, but they will still ask how I defined the scope, documented access decisions, trained users, handled exceptions, and reviewed the control over time.

How Defender for Endpoint, Intune, and Entra work together

The integration works best when I treat it as a chain. Defender for Endpoint produces the risk signal, Intune turns that signal into device compliance status, and Entra Conditional Access enforces access based on that status.

Defender for Endpoint watches the endpoint for malicious activity, missing protections, suspicious behavior, and other threat indicators. In supported environments, it assigns a machine risk level that can range from clear to higher risk states. That signal becomes valuable when I connect Defender and Intune.

In Intune, I create or update a compliance policy and enable the Microsoft Defender for Endpoint setting that requires the device to be at or under a chosen machine risk score. Most teams I support land on Low as the target state for CUI users. During a pilot, I may start at Medium to avoid false starts, then tighten to Low once the fleet is stable.

Once Intune marks the device compliant or noncompliant, Entra Conditional Access can use the grant control Require device to be marked as compliant. At sign-in, Entra checks the policy, evaluates the user, app, client type, and device state, then allows or blocks access to Exchange Online, SharePoint Online, Teams, and other Microsoft 365 services.

That flow is the core of this design. Defender does not directly block the user from Microsoft 365 in the policy I am describing. It informs Intune. Intune publishes compliance. Entra enforces the gate.

Licensing matters here. Risk-based identity features and Privileged Identity Management require Microsoft Entra ID P2 per user. Advanced endpoint detection and response features tied to this pattern typically require Microsoft Defender for Endpoint Plan 2. In many environments, Microsoft 365 E5 or G5 includes those capabilities, while E3, G3, and Business Premium do not include the full stack by default. I also keep in mind that server onboarding needs separate licensing, such as Defender for Servers or Defender for Endpoint Server, because user E5 licenses do not cover servers.

Tenant choice matters too. For CUI under DoD rules, commercial Microsoft 365 is usually the wrong place to stop the discussion. If export controls such as ITAR or EAR apply, GCC High is usually mandatory. For other CUI cases, GCC may fit, but many contractors still choose GCC High because of DFARS cloud requirements and simpler audit positioning.

The Conditional Access policies I trust most

I prefer a small number of clear policies over a sprawl of overlapping rules. For CUI-focused access, I usually build policy sets around user groups, app scope, and device trust rather than office locations.

The core user policy

My baseline policy for CUI handlers targets a dedicated Entra group, not the whole company at first. I scope it to Microsoft 365 or to the exact cloud apps that contain CUI. Then I apply it to browser sessions and modern desktop or mobile clients, because attackers do not care which client the user picked.

For grant controls, I usually select Require multifactor authentication and Require device to be marked as compliant, then choose Require all selected controls. That combination matters. If I use the “one of” setting by mistake, a user may satisfy MFA but still sign in from a noncompliant device.

For privileged admins, I go further. I often require a compliant device plus stronger MFA through authentication strengths, and I keep admin roles under separate protection. If the team uses Privileged Identity Management, I tie admin elevation to the same disciplined model.

This quick matrix shows how I usually translate policy intent into enforcement.

Use case	Intune compliance rule	Entra grant controls	Practical result
CUI user on managed Windows device	Device must be at or under Low Defender risk	MFA + require compliant device	Blocks unmanaged or higher-risk endpoints
M365 admin account	Low, sometimes tighter in pilot groups	Strong MFA + require compliant device	Reduces admin exposure during sign-in
General staff, non-CUI apps	Medium during pilot, Low after cleanup	MFA + require compliant device for selected apps	Easier rollout with less user friction
Personal mobile access to low-risk data	Separate mobile policy, app-based controls	MFA + approved app or app protection	Keeps BYOD away from CUI workloads

The takeaway is simple. I keep the strictest policies where CUI and admin risk live, and I phase the rest in with intent.

Conditions that help, and conditions that mislead

I use named groups heavily because they let me map policy to real job functions. That matters for CMMC and for daily operations. If your finance clerk never touches CUI, that user should not consume the same policy and licensing mix as your program manager who does.

I also use device filters carefully, but I do not use a trusted office IP as a substitute for device trust. A risky laptop inside the building is still a risky laptop. Likewise, I avoid broad exclusions that quietly turn into permanent gaps.

If I want a second opinion outside Microsoft documentation, I find Penthara’s Entra CMMC overview useful as a practitioner-oriented reference. It aligns with the same basic point I see in the field: identity and endpoint signals are strongest when they are enforced together.

BYOD, exceptions, and break-glass accounts without losing control

BYOD is where many good security designs start to bend. A personal device can be convenient, but convenience does not equal suitability for CUI.

For Windows and macOS, I can enroll personal devices and make them comply with policy. That is technically possible. Still, many defense contractors decide that personal devices should never process or store CUI, because ownership, support boundaries, legal hold, and device hardening get messy fast.

On mobile, the story is different. I may allow Outlook or Teams on personal iOS and Android devices with app protection policies for low-risk business activity. Even then, I treat that as a separate use case. It does not mean the device is approved for CUI. If CUI is in scope, I prefer managed corporate endpoints or a tightly controlled virtual access model.

Exceptions need sunlight. If an executive insists on an unmanaged tablet, I want that decision documented, time-bound, and paired with compensating controls. Hidden exceptions are where access models weaken.

Break-glass accounts deserve their own lane. I keep emergency access accounts excluded from normal Conditional Access rules so I can recover from tenant lockout, but I do not use them for daily work. I make them cloud-only, tightly monitored, and hard to abuse. I test them on a schedule, store credentials securely, and keep them out of mailboxes and routine workflows.

Service identities also need attention. Traditional user-based Conditional Access policies do not solve every workload identity issue, so I separate app and automation accounts from human access policy design. That prevents confusion during audits and avoids accidental outages.

The main point is discipline. BYOD, exceptions, and emergency access can coexist with strong CMMC-minded controls, but only when I define the boundary and keep the exceptions visible.

Logging, reporting, and evidence for auditors

A control is easier to defend when I can prove it worked last Tuesday, not only on the day I built it. That is why logging and evidence matter as much as the policy itself.

In Entra, I collect sign-in logs that show the user, application, location, client type, and Conditional Access result. I want to see which policy applied, whether access was granted or blocked, and what grant controls were satisfied. Report-only mode is also useful during rollout because it shows what would have happened before I enforce the policy.

In Intune, I keep the compliance policy configuration, the device compliance state, and reports that show why a device fell out of compliance. If the reason was Defender risk, I want that recorded clearly. In Defender for Endpoint, I keep device inventory, alert history, exposure context, and remediation activity tied to the same endpoints.

For a CMMC Level 2 assessment, screenshots help, but screenshots alone are thin evidence. I pair them with exports, change tickets, policy version history, SSP references, role assignments, and a short explanation of how the control supports the scoped CUI boundary. Assessors usually care about repeatability. They want to know the control is managed, reviewed, and understood.

I also keep evidence of exception handling. If I excluded a break-glass account or blocked BYOD for CUI, I document why, who approved it, and how I review it. That closes the gap between technical settings and governance.

Licensing, tenant choices, and rollout for smaller teams

This is where strategy saves money and pain. I start with the people who touch CUI, the apps they use, and the devices they rely on. Then I map licensing and policy scope to that reality.

For many small and mid-sized organizations, Microsoft Entra ID P2 and Defender for Endpoint Plan 2 are the licensing line between basic security and enforceable device-risk access decisions. Microsoft 365 E5 or G5 usually includes the needed stack. Business Premium is strong for baseline operations, but it does not include every advanced feature I need for risk-based access and full endpoint response. If you run servers, plan for separate server coverage. If your government SKU does not include Teams, confirm that before rollout.

I see this discipline pay off far beyond one compliance project. The same model supports Small Business IT, Cloud Infrastructure, Office 365 Migration, and older Data Center Technology environments where identity sprawl still exists. It even matters in verticals that depend on Restaurant POS Support and Kitchen Technology Solutions, because frontline users often have Microsoft 365 access even when their main work happens in a specialized system.

That is why I treat this as part of Cybersecurity Services, Endpoint Security, Device Hardening, Cloud Management, and Business Continuity & Security. As a Business Technology Partner, I fold it into Technology Consulting, Infrastructure Optimization, Digital Transformation, Secure Cloud Architecture, and IT Strategy for SMBs. For clients who need Managed IT for Small Business, this becomes one piece of Tailored Technology Services and Innovative IT Solutions, not an isolated project that fades after go-live.

My rollout pattern is simple. First, I clean up identities, stale devices, and group membership. Next, I onboard endpoints to Defender and Intune. Then I pilot policies in report-only mode, move to a limited enforcement group, and expand by role. I brief users before each phase so blocked sign-ins are expected, not mysterious. That approach reduces help desk noise and gives me better evidence.

Conclusion

When I build device-based access for CMMC Level 2, I want one clear outcome: users reach CUI only from devices I trust and can prove I manage. Defender for Endpoint, Intune, and Entra Conditional Access do that well when the policies, licensing, and documentation line up.

The strongest takeaway is discipline. If I scope CUI roles carefully, require MFA plus compliant devices, control exceptions, and keep evidence ready, this control becomes practical security instead of policy theater.