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, and the wider fault-finding order sits in the Intune troubleshooting hub. Every Microsoft fact below was checked against Microsoft Learn on 26 September 2026 and rechecked on 2 November 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 |
Intune filters vs dynamic groups
A dynamic group is still a group. Its membership is a rule evaluated by Microsoft Entra ID, and the result then has to reach Intune, which the performance guidance puts at typically within five minutes and not instant. Intune filters skip that step: the filter overview says they evaluate at check-in with no further evaluation delay. For an Intune app or policy aimed at device properties such as OS, model, manufacturer, ownership or category, that makes the filter the faster and simpler choice.
The same overview is just as clear about the other direction. Use dynamic groups when the targeting has to work across workloads, such as Conditional Access or licensing, for Autopilot profile assignment, or for user-based grouping. A filter is an Intune object and nothing outside Intune can read it. When a dynamic group is the right tool but its membership is lagging, the causes sit on the Entra side, covered in why an Entra dynamic group stops updating.
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 newsletter
Free PDF: the Intune troubleshooting field guide
Subscribe and get the free 8-page Intune troubleshooting field guide (PDF), then new fixes about twice a month. From a Microsoft MVP.
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.
Not evaluated because a conflicting assignment did not require filters
A Not evaluated result is usually a precedence decision, not a broken filter. Microsoft's troubleshooting page states that it can show when a policy has a conflicting assignment on the device, and it sets out the order Intune applies when one device falls inside several assignments of the same app or policy:
- Exclude mode applies first. It wins over no filter and over Include mode.
- No filter applies next. It wins over Include mode.
- Include mode applies last.
So a device that sits in a filtered Include assignment and also in a plain assignment with no filter receives the app or policy through the unfiltered one, and the Include filter is never consulted. When the competing assignments use the same mode, Intune joins the filters with OR logic, so matching any one of them is enough. Apps add a step in front: the winning intent, Required, Available or Uninstall, is decided before filters run, and only the filter on the winning assignment is evaluated.
The fix lives in the assignments, not the filter rule. Find the second group that reaches the device, often a broad one added later, and either remove it or give it the same filter. Then wait out the reporting delay and read the report again.
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. Enrollment restrictions accept filters too, on Windows, macOS and iOS, which is how one group can enrol personal Windows devices without opening the platform to everyone: how Intune enrollment restrictions are created and prioritised.
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: 2 November 2026
