Conditional Access device filter: why yours matches nothing, and what it cannot protect

A Conditional Access device filter looks like a group membership test and behaves like nothing of the sort. It is evaluated against the device object in the directory, so a device that has never registered has no attributes at all, and every positive operator you write against it quietly fails to match. That is not a bug and Microsoft documents it plainly, but it is the most common reason a filter appears to do nothing. Here is what the filter actually reads, and the point where it stops being a control.

A Conditional Access device filter is a condition, not a grant control. It decides which sign-ins a policy applies to and nothing at all about what happens once it does. If the policy set underneath is wrong, a precise filter only makes it wrong for a smaller audience. The Conditional Access policy design guide covers that layer. This page is only about the condition.

One disclosure before the detail. My tenant is a lab with no enrolled devices, so I have not run this against a production estate. What follows is the documented behaviour, verified against Microsoft Learn on 19 August 2026, plus the places I would expect it to bite.

What a Conditional Access device filter actually evaluates

The filter runs against the device object in Microsoft Entra ID at sign-in time. Microsoft’s supported property list is fifteen named attributes plus extensionAttribute1 through extensionAttribute15, and the reference table splits them into properties that are system defined and properties that are not. That column is the one worth reading twice, because it tells you which values the device supplied about itself.

The rule builder covers all of those properties, and the rule syntax box takes the same set with the operators -eq, -ne, -startsWith, -notStartsWith, -endsWith, -notEndsWith, -contains, -notContains, -in and -notIn. Which operators each property accepts is not uniform: deviceOwnership, isCompliant, profileType and trustType take only Equals and NotEquals, and physicalIds and systemLabels take only Contains and NotContains. The per property table is in Microsoft’s filter for devices as a condition in Conditional Access policy reference, last revised 24 March 2026.

The setting itself is at Microsoft Entra admin centre, Entra ID, Conditional Access, Policies, New policy, Conditions, Filter for devices. Set Configure to Yes, then choose whether devices matching the rule are included in the policy or excluded from it. That include or exclude choice does more work than the rule does, for the reason in the next section.

The unregistered device rule that breaks most filters

One sentence in the documentation decides whether your Conditional Access device filter behaves the way you drew it on the whiteboard, and it is easy to read past.

For a device that is unregistered with Microsoft Entra ID, all device properties are considered as null values and the device attributes cannot be determined since the device does not exist in the directory.

Null is not false. A rule of device.model -ne "Surface Laptop" is satisfied by a null model, and a rule of device.model -eq "Surface Laptop" can never be satisfied by one. So a positive operator confines the filter to devices that already exist in the directory, and a negative operator sweeps in everything that does not. Microsoft states the consequence directly: the best way to target policies at unregistered devices is the negative operator, because a positive rule only applies when the device exists and the attribute matches.

Combine that with the include or exclude toggle and a small number of safe shapes fall out for any Conditional Access device filter. They are worth committing to memory, because getting them backwards produces a policy that looks correct in the blade and protects nobody.

The third row is the one that gets built by accident, usually because the exclusion was written as “everything that is not our corporate build” rather than “our corporate build”. Both sentences describe the same set of managed machines. Only one of them also describes a laptop that has never spoken to your tenant.

extensionAttributes only exist where the device is already managed

The fifteen extension attributes are the property most people reach for, because they are the only ones an administrator writes rather than reads. They come with a constraint that removes most of the reason to reach for them in a Conditional Access device filter.

Devices must be Microsoft Intune managed, compliant, or Microsoft Entra hybrid joined for a value to be available in extensionAttributes1-15 at the time of the Conditional Access policy evaluation.

Read that as a dependency rather than a footnote. An extension attribute is readable at policy evaluation only on a device that is already Intune managed, already compliant, or already hybrid joined. If a device is in one of those three states you can express the same idea with isCompliant, trustType or mdmAppId and skip the tagging pipeline entirely. Extension attributes earn their keep when you need a distinction Entra does not model, such as which of two Autopilot profiles a machine came from, or which devices belong to a privileged access tier.

Writing one is a PATCH against the directory device object, not the Intune device. The two have different identifiers and mixing them up returns a 404 that reads like a permissions problem.

1# Write extensionAttribute1 on an Entra ID device object.
2# The GUID is the DIRECTORY object id, not the Intune managed device id.
3# Application permission Device.ReadWrite.All, or delegated Directory.AccessAsUser.All.
4# Intune Administrator is the least privileged directory role Microsoft lists for this.
5
6PATCH https://graph.microsoft.com/v1.0/devices/7c06cd31-7c30-4f3b-a5c3-444cd8dd63ac
7Content-type: application/json
8
9{
10    "extensionAttributes": {
11        "extensionAttribute1": "SAW"
12    }
13}
14
15# Success is 204 No Content. There is no response body, so a script that
16# checks for JSON in the reply will report a failure that did not happen.

The request shape, the permission set and the least privileged role are documented on the Microsoft Graph update device reference. In application only scenarios against non-Windows devices, that same page notes the app can update the extensionAttributes property and nothing else on the object.

The matching filter rule is one line, and it belongs in exclude mode with a positive operator for the reason established above.

1# Entered in the rule syntax box on the Filter for devices condition.
2# Exclude mode plus a positive operator: an unregistered device does not
3# match, so it is not excluded, so the policy still applies to it.
4device.extensionAttribute1 -eq "SAW"

Device state is deprecated and the Conditional Access device filter replaced it

If you are maintaining policies written before 2022 you will still find the device state condition in them. Microsoft’s position is now unambiguous.

This condition is deprecated. Customers should use the Filter for devices condition in the Conditional Access policy to satisfy scenarios previously achieved using the device state condition.

The two cannot be combined. Device state and filters for devices cannot be used together in the same Conditional Access policy, and the filter covers the old ground through trustType and isCompliant. Migrating is a rewrite of the condition, not a toggle, and it is worth doing before the deprecation stops being advisory. Both statements are on Microsoft’s Conditional Access conditions reference, last revised 3 June 2026.

A Conditional Access device filter is targeting, not a security boundary

Three of the filterable properties are marked in Microsoft’s own table as not system defined: displayName, manufacturer and model. They describe what the device said about itself when it registered. The adjacent device platform condition is weaker still, and the documentation does not hide it.

Conditional Access identifies the device platform using information provided by the device, such as user agent strings. Because user agent strings can be modified, this information isn’t verified. Use device platform with Microsoft Intune device compliance policies or as part of a block statement.

That guidance generalises. A filter narrows who a policy applies to; it does not attest to anything. Every exclusion you write on a self reported property is an exclusion an attacker can aim at, and the cost of getting it wrong is not a smaller blast radius but no policy at all for whoever matches. The properties that survive that test are the ones Entra derives itself: trustType, isCompliant, profileType, mdmAppId, deviceOwnership and enrollmentProfileName.

The practical consequence is that the baseline should hold without the filter. Require multifactor authentication for everyone first, then use filters to carve out the cases that genuinely cannot satisfy it, rather than building the requirement out of conditions in the first place. That ordering is the same one behind granular Conditional Access and session controls, and it is the difference between a device signal that strengthens a decision and one that is load bearing on its own. The wider identity design that sits above it is covered in architecting a Zero Trust future with Microsoft Entra ID.

The failure modes

Each of these has been read as a broken Conditional Access device filter at some point. None of them is.

• The filter matches nothing and the policy silently applies to everybody. An include mode filter with a positive operator against a fleet that is registered but not yet populated with the attribute you are testing produces an empty match set. In include mode the policy then applies to nobody, which reads as success in the sign-in logs because there are no failures to see.
• The exclusion lets unregistered devices through. Exclude mode with a negative operator. The whiteboard said “not our build”, the tenant heard “and also every device I have never met”. Check every existing exclusion for this shape before you add another.
• The extension attribute is blank on exactly the devices you cared about. Personal and unenrolled machines never expose extensionAttributes at evaluation time. The rule is not broken, the value is not there.
• 404 when writing the attribute. The Graph PATCH takes the Entra device object id. The Intune managed device id is a different GUID for the same physical machine, and passing it returns a not found rather than a helpful error.
• Repeating certificate prompts on Mac, iOS and Android. Microsoft documents that policies requiring compliant devices may prompt users on those platforms to select a device certificate during evaluation even when compliance is not being enforced, and that the prompts can repeat until the device is made compliant. It looks like a filter bug and is not one.
• Device state and a filter in the same policy. They cannot be used together. If an old policy still carries the deprecated condition, the filter you add to it is not the change you think you made.
• Report only mode read as a pass. Report only tells you the policy would have applied. It does not tell you the user would have satisfied the grant control, and on a filter change that distinction is the whole test.

What I would do differently

I would write every Conditional Access device filter as the positive statement of what I trust, and let the mode toggle carry the negation. “Exclude devices where trustType -eq our join type” is inspectable a year later. “Include devices where trustType -ne our join type” is the same set today and a different set the moment someone adds a second join type, and nobody rereads a working policy.

Prefer the properties Entra derives over the ones it is told. enrollmentProfileName and trustType answer most of the questions extension attributes get used for, without a tagging pipeline to keep current. Reach for extension attributes when you need a distinction the directory genuinely does not model, and accept that you now own a synchronisation job.

Test the failure direction rather than the success direction. Anyone can confirm that a compliant corporate laptop still signs in. The question worth an afternoon is what a device with no directory object does against the same policy, and the only honest way to answer it is to try one. Licensing for the surrounding policy set is a separate decision, and the tiering is set out in Entra ID P1 vs P2 and the licence maths.

Last verified: 19 August 2026.