Conditional Access device filter – no, not that one, the good one!

What is a device filter and why do we care when working with the cloud?

While working in securing our Microsoft 365 tenants you should all know by now that MFA requirement configured through Conditional Access is one the most important tools we have at our disposal. But this job involves a lot more then simple MFA ON/OFF and it is important to look at all the tools and options available in Conditional Access.

One of these options are related to clients, which is a very important part of our security posture. Most people working with Conditional Access are aware of the two options regarding clients under Controls:

• Require device to be marked as compliant
• Require Microsoft Entra hybrid joined device

The problems with these settings are:

1. They’re VERY limited in scoping. You can choose between either Intune compliant (yes/no) and/or Entra hybrid joined (yes/no)
2. Since they are located under “Grant“: You can easily use them (intentionally or unintentionally) to skip MFA for compliant or hybrid joined devices, which you definitely shouldn’t do unless it’s absolutely necessary!

Instead, you should use the device as a condition to either block access or add extra restrictions along with MFA. Luckily Conditional Access was updated a while back to include a proper device filtering feature! 🥳

The proper device filter

The proper device filter is located under “Conditions” and then “Filter for devices” in your Conditional Access policies.

Here you can select a filter to either include in your policy or exclude from your policy, and already here we see a huge improvement in the flexibility. Flexibility is after all one of the core strengths of Conditional Access so having a flexible device filter is only natural.

Below we see a list of several properties we can build this filter out of. (The hidden part of the list in the screenshot below is ext.attribute1-15). This allows for very specific filters which again is either included in the policy or excluded from it.

But what are the correct operators and values ?

Excellent question! First of all you have this Microsoft Learn article to help you get started. If you still want examples or need to check a specific device/value, my go-to method is to use PowerShell and check what the Graph API says. For example, this very quick and dirty script will connect to Graph with read-only permissions and list all properties for the specified device (“Computer01” in this example):

Connect-MgGraph -scopes "device.read.all" 
$devicename = "Computer01"
Get-MgDevice | where {$_.DisplayName -like $devicename} | fl

Looking on the picture below: Checking for devices based on their operating system can yield some unexpected and strange results. Therefore, I recommend thoroughly testing your policies which contains a device filter, and take a look in your own tenant using Graph.

🚨Be aware that device filtering has some quirks. Device filters in Conditional Access are evaluated against devices registered in Entra, so policies with a positive operator (contains, equals etc) will not apply to devices not registered. Also note that Ext.attribute 1-15 requires the device to be either Hybrid domain joined or Intune compliant. The details are listed here and I highly recommend that you read them!

Cool – now what?

First of all: I hope you like Boolean algebra, you will need it! 😉

Here’s a few examples to help you get started. These are only generic examples and should be considered a starting point which must be adjusted to your specific tenant and environment.

1. Block devices by operating system.

In this example: Say you have an environment where you want to block iOS devices (No offence to you iOS users). I think most of us will immediately think this is a simple Conditional Access policy:

• Only include iOS as operating system in the policy
• Block access

Like the filter below:

Will this policy work as intended? NO! 😱

Do you know why? Because, as I wrote in the previous chapter: “policies with a positive operator (contains, equals etc) will not apply to devices not registered.” So users on an iOS device which is not registered in Entra one way or another, will bypass this filter. In order to solve this we must use double negatives (Sorry to your grammar-nerds out there 😉). We simply change “Include in policy” to “Exclude from policy” and we change “Equals” to “Not equals“.

❗However, like I explained in details in this post, I think a much better approach is to block everything by default and open up for traffic you wish to allow. So while your initial description of the requirement can be “We need to block iOS devices“, a better approach would be “We must only allow Windows, Mac and Android devices“. Another reason why this is a better approach is that you also block devices which reports as “unknown” and other scenarios you maybe wasn’t aware of. For example that managed iOS devices reports as “IPhone” or “Ipad” and not as “iOS”. So let’s change the device filter for this scenario. In this case the device filter in the block rule will contain a device filter like this:

This will filter out any devices not meeting one of the three operating system requirements.

2. Enforce privileged access workstation for admin

In this example: Say that you want to harden the security for your privileged accounts, and you want to limit their ability to login to only from a Privileged Access Workstation (PAW). PAWs are highly secure devices specifically configured to safeguard administrative credentials and reduce the risk of cyberattacks.

Here I would create a block policy scoped to the privileged accounts and exclude the DeviceID of the PAWs, which will strictly limit which devices these accounts can log in from. A device ID in Microsoft Entra is a unique identifier assigned to a device registered in the tenant. This is similar to the user or group GUID, and is a globally unique identifier of that specific device. You can also, if applicable, add other requirements like being Intune Compliant.

Notice in the picture below that I have manually edited the rule syntax. I did this to ensure the compliance requirement applies to both clients, using a parentheses to align with the correct Boolean logic. Without the parenthesis, the compliance requirement will only apply to the second device. I told you that you will need to know Boolean algebra!

3. Require compliant device to access a resource

In this example: Suppose you want to restrict access to a resource so that it is only accessible from an Intune-compliant device. As mentioned earlier, you can add a filter to check whether the device is compliant (True/False). Additionally, you can further customize this by including filters for Enrollment Profile, device ownership, manufacturer, etc, if a simple ‘is compliant’ check is not specific enough. So many options! So much flexibility! 😍 Again set up a block rule with a device filter excluded from the rule.

4. Enforce MFA registration only from an Entra joined device

It always a good idea to limit how your users can register their MFA methods. Here I will suggest a block rule with a device filter as exclusion. Here we can use “TrustType” and the value depends on how your devices are joined. There are only 3 valid options here:

1. “AzureAD” = Entra joined devices
2. “ServerAD” = Entra hybrid joined devices
3. “Workplace” = Entra registered devices

Conclusion

So in conclusion, the device filter in Conditional Access is a powerful tool for bolstering your organization’s security posture. By allowing precise control over which devices can access your resources, you can, for example, ensure that only compliant and trusted devices are granted access. This feature is particularly useful for enforcing security policies, managing access in diverse environments, and supporting a Zero Trust architecture.

Also, it’s important to be aware of its quirks and limitations as I mentioned in the beginning. For instance, the device filter relies heavily on accurate device registration and it’s behavior is not always predicable for non-registered devices. Keep in mind that negative operators is needed. Additionally, the complexity of configuring these filters requires a thorough understanding of your organization’s device landscape and security needs.

And ALWAYS test your Conditional Access policies!!

Now I want to thank you for reading this post and I hope it was useful and you learned something new. Hopefully you can use the potential of the device filter in Conditional Access to create a more secure and resilient IT environment. With careful planning and execution, I’m sure this feature can become a cornerstone of your security strategy!