Intune filters look like a cheaper way to target devices than groups, and for a narrow set of jobs they are. Groups decide who the audience is. Assignment filters then decide which of that audience’s devices actually receive the app or policy. The trouble starts when a filter is asked to do a group’s job, because the two are evaluated at different times, by different services, and they fail in different ways.
Microsoft now says plainly that filters are not a replacement for groups in every scenario, and the list of places a filter cannot go is longer than most admins expect. The ordering and exclusion problems below also feed directly into Intune policy conflict, where a policy you did not expect turns out to be the one applied. Every Microsoft fact below was checked against Microsoft Learn on 26 September 2026.
Groups pick the audience, filters pick the devices
A group is an Entra object. Its membership is computed by Entra, synchronised to Intune, and only then used for targeting. A filter is an Intune object. It is a rule over device properties, evaluated by Intune at the moment a policy is considered for a device.
That difference in where the evaluation happens is the whole story. Microsoft’s performance guidance states that the update from Entra to Intune typically happens within five minutes and is not instant. The filter overview says a filter is evaluated when the device enrols, checks in with the Intune service, or at any other time a policy evaluates. So a filter reacts to the device as it is now, and a group reacts to the device as Entra last computed it.
| Question | Group | Assignment filter |
|---|---|---|
| Who evaluates it | Entra, then synchronised to Intune | Intune, at evaluation time |
| When it changes | After membership processing and sync | At the next enrolment, check-in or policy evaluation |
| Usable outside Intune | Yes: Conditional Access, licensing, SharePoint | No |
| Tenant limits | Entra group limits | 200 filters per tenant, 3,072 characters per filter |
| Report delay | Depends on the workload | Up to 30 minutes after evaluation |
Where Intune filters cannot replace a group
Microsoft’s Choose the right targeting method article, checked on 26 September 2026, lists the places a filter cannot be used. Two matter most. Autopilot profile assignment needs the device to be a group member before enrolment begins, so no filter can stand in. Conditional Access, licensing and SharePoint all require Entra group membership, and never see an Intune filter at all.
The second point catches people because Conditional Access has its own device filter feature, which shares a name and nothing else. That is an Entra condition evaluated at sign-in, covered in Conditional Access device filter. An Intune assignment filter has no effect on a Conditional Access policy.
Then there are workloads that do not support filters at all. The supported workloads reference, updated 23 September 2026, lists the managed device features that don’t support assignment filters. The list includes feature updates for Windows, policy sets, PowerShell scripts for Windows, shell scripts for macOS, terms and conditions, and custom compliance for Windows. For managed apps, filters are not supported for device configuration profiles or endpoint security policies. If a script must reach only certain hardware, the group has to do that work.
Driver updates are a documentation gap rather than a clear answer. The supported workloads page does not mention them. Microsoft’s driver updates FAQ is the source the earlier Intune driver updates post relied on. Until the two pages agree, treat driver update policies as group-targeted.
The failure modes
These are the ways Intune filters produce a result nobody intended. Most of them work exactly as documented, which is why they are hard to spot.
| What you see | What is happening | What to do |
|---|---|---|
| An app installed on a device the filter should have excluded | The filter was evaluated before the property it depends on existed. Microsoft’s own example is device category: at enrolment no category is set, the filter evaluates a null category, and the app installs | Do not filter required apps on properties set after enrolment |
| The wrong device received a policy, then it went away | A device group exclusion was used with a user group assignment. Excluded group membership is not instant, so devices can receive the assignment before the exclusion takes effect | Exclude with a filter, not a group of the opposite type |
| Filter report shows Not evaluated | The policy has a conflicting assignment on the device | Resolve the conflicting assignment first, then re-read the report |
| The report still shows the old result | Evaluation results can take up to 30 minutes to appear, and are kept for 30 days | Wait out the reporting delay before changing the filter again |
| A device you excluded is missing from the status report | Devices in Excluded groups aren’t shown in the workload device status reports | Check the device’s own Filter evaluation view instead |
| A new filter will not save | 200 filters per tenant, or 3,072 characters per filter rule | Consolidate filters around properties, not per team |
The first row deserves its own paragraph. In the assignment filter troubleshooting article, Microsoft walks through the device category case and states that the app, once installed, won’t be automatically removed. The filter later evaluates correctly, the report goes green, and the app stays. The same timing trap applies to any property that is written after enrolment. The ordering behind that is set out in the Intune enrollment status page, which is where required apps first land on a new device.
The exclusion rule that is also a support statement
The single most useful sentence in the filter documentation is in the performance recommendations for grouping, targeting and filtering. Microsoft states that the recommendation is also a support statement. It does not recommend or support creating assignments to user groups and excluding a device group from that assignment, or the reverse.
That is not guidance for large tenants only. It describes a combination that produces incorrect assignments, because excluded group membership is not instant. If you are carrying an assignment that targets All users and excludes a device group of kiosks, you are running an unsupported configuration. The supported way to get the same result is the filter: target the users, add an exclude filter on a device property that identifies the kiosks.
Reading the filter evaluation report without being misled
The per device report sits at Devices > All devices, then the device, then Filter evaluation. It answers one question well: for this device, at the last evaluation, did the filter match. It does not tell you whether the app or policy is still on the device from an earlier evaluation, and it does not show devices that were excluded by group rather than by filter.
Two practical rules follow. Read the report after the reporting delay, not immediately after a change. And when the report and the device disagree, believe the device. A filter that matches now says nothing about what was installed an hour ago, when the property had a different value.
Property values in filter rules are case insensitive, per the properties reference, which removes one class of mistake. The deviceTrustType values still use the old names, for example Azure AD joined. Those are the literal strings the rule must match. Do not rewrite them to the Entra names, however tempting it is.
What I would do differently
I have not run assignment filters against a production estate. My tenant is a lab with no enrolled devices, so what follows is judgement built on the documentation above, not measurement.
Use Intune filters for hardware and ownership properties that exist at enrolment and do not change: manufacturer, model, ownership, enrolment profile name. Those are stable at the moment the first evaluation happens, which is the moment that matters for required apps.
Use groups for anything that describes a person, a department or a lifecycle state, and for anything that must also reach Conditional Access, licensing or Autopilot. The All users and All devices virtual groups are always current, which makes them the best base for a filter, since no membership processing sits in the way.
Never mix a user group assignment with a device group exclusion. Replace every one you find with a filter, starting with required apps, because those are the ones that install and then stay.
Finally, give each filter a name that states its rule, not its purpose. Filters are shared across assignments, and a filter called Finance laptops that actually matches a model number will be reused by someone who reads only the name. If status lags after a change, the reporting delays in Intune compliance policy status apply here too.
Last verified: 26 September 2026
