Filtering without Endpoint Manager/EntraID device joins: A creative workaround based on Conditional Access for Azure/Microsoft 365.

 A couple of months ago, I was tasked with providing a filter mechanism for a small spin-off team. At first glance, the obvious solution seemed to be leveraging device compliance statuses through Endpoint Manager. This is a fairly standard approach—straightforward and scalable. However, there was one major challenge: none of the devices were joined to EntraID (formerly Azure AD), neither as Azure AD-joined nor Hybrid AD-joined. Additionally, smartphones weren’t registered in Intune.

No devices, no enrollment, no compliance—so no chance at all? Not quite.

There is, in fact, a workaround! While it's not a perfect solution, and definitely not one that scales indefinitely, it worked well for our specific use case. Let me walk you through how we made it work.

The Workaround: Conditional Access with Device Filters

The idea was to use a device filter-based Conditional Access policy. This approach leverages device attributes to enforce access control rules. While not overly complex, it’s effective for smaller environments where you can define clear patterns for identifying corporate devices.

Here’s the core concept: as long as a device is Azure registered

Article content
Dialog during MS Office setup

... which can either be initiated by the user or silently configured by IT—you can use device properties as filtering criteria. In our case, the two properties that proved sufficient were:

  • device.displayName: We established a naming convention for corporate devices, allowing us to easily identify them.
  • device.deviceID: We used this unique identifier to refine the filtering mechanism further.

By combining these two properties, we were able to filter corporate devices effectively, ensuring only approved devices could access the resources.

Article content
Device filter section
Article content
Success :) The access is blocked from an unauthorized private / non-corp device

Limitations and Considerations

It’s important to note that this solution is not 100% bulletproof and isn’t designed to handle thousands of devices. When building complex rules or using too many unique identifiers (like deviceID), you also need to be mindful of Azure’s character limits—the total rule size is capped at 3,072 characters. This is something to carefully consider if your environment grows or requires more granular filtering.

For example, you can define a rule like this:

plaintextCopy Codedevice.deviceID -notin ["ID1", "ID2", ..., "IDn"]

This approach allows you to exclude specific devices from the policy. While useful, it quickly becomes unwieldy as the number of devices increases.

When Does This Work Best?

This workaround is ideal for smaller setups where:

  • Devices are Azure registered (but not necessarily joined or compliant).
  • You have clear naming conventions for identifying corporate devices.
  • The scale is limited, and you don’t need to manage thousands of devices.

For larger environments, it’s better to stick with scalable solutions like Endpoint Manager with proper device compliance policies. However, for our spin-off’s purposes, this lightweight solution worked perfectly.

Takeaway

While this filtering method is not a one-size-fits-all solution, it’s a handy workaround for situations where device enrollment in compliance tools isn’t an option. By leveraging device properties like device.displayName and device.deviceID through Conditional Access policies, you can create a functional, targeted filtering mechanism—even in less-than-ideal circumstances. For us it was simply a trade off between - trust towards EntraID joined/hybrid-joined devices, the implementation efforts with Endpoint Manager and also the dependencies towards further Microsoft services.

Remember: simplicity and clarity are key. This type of solution works best when you balance its limitations with your actual needs. For us, it was all about striking that balance—and it delivered exactly what we needed.

Comments

Post a Comment

Popular posts from this blog

4 Most common Issues while registering devices with Microsoft Intune MDM

Image
  The built-in Mobile Device Management (MDM) for Office 365 helps you secure and manage your users' mobile devices like iPhones, iPads, Androids, and Windows phones. You can create and manage device security policies, remotely wipe a device, and view detailed device reports. During implementation or deployment, there are some common issues which occur in many of the environment  1-   Windows Update Sometimes you will notice that Windows Update is showing-Up-To-Date but in actual, the version needed for the MDM Registration is not updating automatically and eventually fails every time in the loop Solution Suggested Go to this  link  upgrade your Windows 10 to the latest version You will find a home page like the screenshot below. Click on UPDATE Now button. It will download a .exe file. Run the file and click on UPDATE Now button and press YES. Here it will update your Windows 10 to the Latest Version Note:  You can still work during downloading a...
Read more

Managing Windows Updates with Intune: Best Practices with Update Rings

Image
  Keeping Windows devices up to date is one of the most critical, and often most overlooked, aspects of endpoint security. With Microsoft Intune, you can manage Windows updates centrally using Update Rings , giving you control over when updates install, how users experience restarts, and how you test updates before broad deployment. In this guide, I’ll walk you through: What update rings are Why they’re essential for patch compliance How to configure them in Intune Best practices for rollout and user experience 1. What Are Windows Update Rings in Intune? Update rings in Intune allow you to: Define when and how Windows updates are delivered Set deadlines for installation and restarts Delay feature updates (e.g., to test before production) Control user experience during updates They apply to Windows 10 and 11 devices enrolled in Intune, including those provisioned via Autopilot. 2. Why Update Management Matters Without structured update management, you risk: Devices missing crit...
Read more

The Intune Device Lifecycle: From Onboarding to Retirement (Best Practices)

  Managing endpoints isn’t just about deployment, it’s about handling the entire device lifecycle : from onboarding and day-to-day management to secure deprovisioning when a device is no longer in use. Microsoft Intune provides a streamlined, policy-driven approach to each phase of this lifecycle, and when done right, it reduces IT overhead, increases security, and improves the user experience. In this post, I’ll walk you through the key stages of managing a device in Intune from start to finish, and how to handle each one effectively. Stage 1: Provisioning & Onboarding This is where the device journey begins, and it sets the tone for everything that follows. Tools and features to use: Windows Autopilot for zero-touch setup Enrollment Status Page (ESP) to control setup sequence Dynamic groups to assign configurations automatically Baseline security policies (compliance, Defender, encryption) Goal: Make the first experience smooth, secure, and consistent for every user. Sta...
Read more