How I Use Entra ID Device Filters for CMMC Level 2

One weak laptop can open a path to Controlled Unclassified Information, even when the rest of Microsoft 365 looks locked down. I see that often when teams turn on Conditional Access but never narrow access to approved endpoints.

That is where Entra ID device filters help. When I pair them with Intune compliance, strong grant controls, and clean device records, I can limit CUI access to devices my team actually trusts. The details matter, so I start with the compliance goal before I write a single rule.

Why device filters matter when CUI lives in Microsoft 365

CMMC 2.0 Level 2 expects me to control access to CUI, not only by user, but also by device. Conditional Access is a strong control point for that job because it sits between the sign-in and the app. Microsoft explains the feature set well in its device filter guidance for Conditional Access and its Conditional Access deployment planning guidance.

A device filter does not replace compliance. It narrows which endpoints a policy targets. Then the grant controls decide what must be true before access is allowed. For CUI, I usually want only managed, approved, and well-documented devices to reach SharePoint, Teams, Exchange Online, or line-of-business apps.

Device filters help me narrow access to approved hardware. They do not replace Intune compliance, logging, incident response, or admin controls.

That distinction matters for CMMC Level 2. Filters support access control, but I still need broader administrative safeguards, audit records, device hardening, incident handling, and system security practices. If I need encryption on mobile devices or tighter removable media control, I rely on Intune, Endpoint Security, and Device Hardening settings, not the filter alone.

In my Small Business IT work, I treat this as one layer inside larger Cybersecurity Services. It connects to Cloud Infrastructure, Cloud Management, Secure Cloud Architecture, and Business Continuity & Security. It also shows up during Office 365 Migration, Data Center Technology refreshes, and Infrastructure Optimization projects, because poor device identity data breaks policy logic. For clients that need Restaurant POS Support or Kitchen Technology Solutions, I use the same discipline. Approved devices get access, personal ones do not. That is part of real Digital Transformation, smart Technology Consulting, and practical Managed IT for Small Business. It is also why many companies want a Business Technology Partner that brings Tailored Technology Services, Innovative IT Solutions, and a grounded IT Strategy for SMBs.

Know the device states before you write rules

Before I build any filter, I sort out three ideas that people often mix together: Entra joined, hybrid joined, and compliant. These are related, but they are not the same thing.

This quick table shows how I separate them.

| Device state | What it means | Why I care for CUI | | | | | | Microsoft Entra joined | The device is joined directly to Entra and has a cloud identity | Good for cloud-first corporate endpoints | | Microsoft Entra hybrid joined | The device is joined to on-prem AD and registered in Entra | Useful when legacy AD still matters | | Compliant device | Intune says the device meets policy, such as encryption, OS, AV, or risk rules | Strong signal for secure access decisions |

A device can be Entra joined and still fail compliance. A device can also be compliant without being fully joined in the way I expect. That is why I never use join type as a shortcut for security posture.

Microsoft’s guidance on requiring compliant or hybrid joined devices is the baseline I follow. For most CUI scenarios, I want grant controls that require a compliant device, and sometimes I also allow hybrid joined devices during a transition period. Registered or “Workplace” devices are where I get cautious. They may exist in the directory, but that does not make them appropriate for sensitive data.

If the environment still has legacy Windows management, hybrid join may stay in scope for a while. If the company is cloud-first, I prefer Microsoft Entra joined devices with Intune compliance because the policy path is cleaner and easier to audit.

How I build Conditional Access with device filters

When I create a CUI policy, I keep it simple first. Then I add precision.

1. I scope the policy to the users and apps that handle CUI, not every user in the tenant.
2. Next, I set a device filter that targets only approved endpoint types, such as company-owned Entra joined or hybrid joined devices.
3. Then I apply grant controls, usually MFA plus “require device to be marked as compliant,” based on Microsoft’s grant control guidance.
4. Finally, I exclude emergency access accounts and test accounts so I do not lock out administration.

A simple example might include devices where device.trustType -eq "AzureAD" or device.trustType -eq "ServerAD", then limit the result further with device.deviceOwnership -eq "Company". That pattern helps me keep personal devices away from CUI, even if a user signs in with valid credentials.

I also build separate policies for different realities. A finance team with only managed laptops can have a strict compliant-device rule. A plant floor kiosk or shared station may need a different policy if the business process is controlled and documented. That matters in regulated environments, because one giant policy often creates more exceptions than protection.

The main lesson is simple. Filters decide which devices the policy sees. Grant controls decide what those devices must prove. I need both parts working together.

The device attributes I trust most, and the ones I validate first

The safest filter rules are the ones tied to stable, populated attributes. In practice, I start with trustType and ownership, because those are easier to reason about than a random hardware field.

device.trustType helps me separate Microsoft Entra joined, hybrid joined, and workplace-registered devices. device.deviceOwnership helps me distinguish company gear from personal gear, when the value is accurate. That gives me a clean first pass.

I use extension attributes when I need a hand-picked allow list. For example, I might stamp extensionAttribute1 with CUI-Approved for a small set of engineering workstations. That is useful when a device must pass an extra business review. However, I validate this carefully. Microsoft notes that extension attribute behavior has extra conditions, and those rules often depend on the device being compliant or Microsoft Entra hybrid joined. I never assume these attributes will behave the same way across every tenant without checking the current documentation and testing against real device objects.

Model and manufacturer filters can help, but I treat them as supporting signals, not my primary lock. A rule such as device.manufacturer -eq "Microsoft Corporation" or device.model -contains "Surface" can work if those values are populated cleanly. Still, inventory data varies. I inspect actual device records before I trust it. That is even more important for field devices, shared tablets, and niche systems used in Restaurant POS Support or Kitchen Technology Solutions, where hardware naming can be inconsistent.

If the device record is messy, the filter will be messy too. I clean the data before I trust the policy.

Test safely with report-only mode and pilot groups

I never point a fresh CUI policy at all users. First, I put it in report-only mode. Then I assign it to a pilot group with IT staff, compliance staff, and a few real users from the affected workflow.

That gives me three things. I can see which sign-ins the policy would block, confirm the filter matches the right device set, and catch gaps in ownership or compliance data before production. I also review the sign-in logs and compare them against the device inventory. If a device should have matched but did not, the directory record usually explains why.

For teams new to this, I also check Microsoft’s device compliance with Conditional Access guidance. As of May 2026, the core Entra device filter approach has not changed in a major way, but cloud features and licensing details can shift. Because of that, I verify behavior in the tenant I am protecting, not the tenant I protected last year.

Pilot results also support CMMC evidence. I document policy names, rule logic, target groups, exceptions, approval dates, and test outcomes. That record helps during internal reviews and keeps changes under control after go-live.

Final thoughts

When I protect CUI with Conditional Access, the best results come from clean device identity, strong Intune compliance, and tightly scoped filters. Entra device filters are powerful because they let me narrow access to hardware I know and manage.

They are still only one control. For CMMC 2.0 Level 2, I back them with broader Cybersecurity Services, Endpoint Security, Device Hardening, audit records, and incident response discipline.

If the device record is accurate, the policy can be precise. That is the difference between a filter that looks good on paper and one that holds up when access to CUI is on the line.