An Intune policy conflict is not one behaviour with one fix. Whether the setting applies at its most restrictive value, applies from whichever policy arrived first, or applies nothing at all depends entirely on which kind of policy the two settings came from. Microsoft documents four separate resolution rules across four policy types, and the admin centre reports every one of them with the same single word. Here is what each rule does, where the collision is visible, and why finding the second policy is harder than it should be.
Rule out delivery before you rule on precedence. A policy that never reached the device produces a status that reads like a failure and is not a conflict, and applying precedence logic to what is actually an enrolment or check-in problem costs an afternoon. Work the Intune device not syncing diagnosis order first and come back once you are certain both policies genuinely arrived.
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 17 August 2026, plus the places I would expect it to bite.
The four rules behind an Intune policy conflict
Microsoft’s own framing is that the conflict is handled differently depending on the type of policy. That sentence carries more weight than it looks like it does, because there are four distinct outcomes and one case where Intune declines to have an opinion at all.
| What collides | What Intune does | Result on the device |
|---|---|---|
| Compliance policy vs device configuration profile | Compliance takes precedence at the individual setting level | The compliance value applies |
| Compliance policy vs compliance policy | Most restrictive setting applies | The stricter value applies |
| Configuration profile vs configuration profile | Conflict is surfaced for manual resolution. Intune does not choose | Neither value is delivered |
| App protection policy vs app protection policy | Most restrictive value, except numeric fields, which fall back to the recommended settings value. If one policy is already applied, it keeps precedence and the second reports a conflict | The stricter value applies |
| Custom OMA-URI or an Apple Configuration file | Intune does not evaluate the payload. It is a delivery mechanism only | On Apple platforms the settings are applied randomly |
The precedence rules and the app protection behaviour are set out in Microsoft’s common questions with policies and profiles article, which is the closest thing to an authoritative statement of how conflict resolution works and is not where most people look for it.
Row three is the row that matters. Two configuration profiles setting the same value differently does not produce a winner, a warning and a working device. It produces a device where that setting is not configured by anyone. Microsoft’s schools deployment tutorial says it without hedging: when conflicts occur, Intune generates an error and does not apply either setting. So the security control you believed you had deployed twice is deployed zero times, and the report says Conflict rather than Not configured, which reads as a tidy-up job rather than a gap.
Compliance beating configuration is deliberate, not a bug
Compliance policy settings always have precedence over configuration profile settings. Read that as a design decision rather than an accident of implementation. Compliance is the input to Conditional Access, so a configuration profile is not permitted to quietly lower the bar that access decisions are made against. If you have ever watched a compliance setting override what a configuration profile appeared to enforce, that is the mechanism, and it is working correctly.
It also means the two policy types are not interchangeable places to put the same setting, which is a habit worth breaking. A setting that belongs to your access decision belongs in compliance. A setting that describes how the device should be built belongs in configuration. Putting it in both is how you end up debugging precedence instead of managing devices. The same ownership question comes up between management channels rather than between policies, and I worked through that in the piece on deciding which channel actually owns your antivirus settings.
Where the collision is actually reported
There are three places in the admin centre that show conflict state, and they answer different questions.
- Devices > Manage devices > Configuration > Policies, then open the policy and read the device and user check-in status. This tells you a conflict exists somewhere in this policy.
- Per setting status, reached from that same check-in status view. This is the one that matters, because it names the individual setting rather than the policy.
- Devices > All devices, open the device, then Device configuration. This gives you every policy targeting that one device and its state, which is where you start when a single machine is behaving oddly.
Microsoft’s device configuration monitoring documentation defines the Conflict state as two settings applied to the same device that Intune cannot sort out, and flags it as something an administrator should review. Note what the definition does not contain: any indication of which two policies, or which setting. That gap is the whole problem, and it is why the per setting status view is worth the extra two clicks every time.
There is a fourth view that gets missed. Devices > Monitor > Configuration policy assignment failure is the tenant wide sweep, and it is the right place to answer the question nobody asks until an audit: how many conflicts do we have across the whole estate, rather than on the one device somebody complained about.
Finding the two policies that collided
The admin centre will tell you a setting is in conflict. It will not hand you the pair. This is the sequence I would work:
- Open per setting status on the reporting policy and note the exact setting name. Not the policy name, the setting name.
- Take the device from the same report and open Devices > All devices > the device > Device configuration to list every policy targeting it.
- Search that list for the setting name. The settings catalogue uses the underlying CSP naming, so the same control can appear under two different labels if one policy is a settings catalogue policy and the other is a template or an endpoint security profile.
- Check the group memberships behind each candidate. Conflicts frequently come from a device targeted policy and a user targeted policy that were never meant to overlap and now do because someone joined a team.
- Force a check-in and re-read the per setting status rather than trusting the previous run. If you are unsure whether the device has picked up your change, the mechanics are in forcing an Intune sync.
The failure modes
These are the ways an Intune policy conflict turns into wasted time rather than a five minute fix.
The word covers five behaviours. Conflict in the report means most restrictive applied, first policy retained, nothing applied, or Apple picked one at random, depending on what collided. Nobody can act correctly on that word alone, and the report never tells you which case you are in.
Same setting, two names. A security baseline, an endpoint security profile, a settings catalogue policy and a legacy template can all write the same CSP. They are presented as four different products in the console. Searching for the friendly name you configured will not find the other policy if the other policy calls it something else.
Multiple baseline instances. Microsoft’s security baselines documentation is explicit that you can run several baselines, and several customised instances of the same baseline, at once, and that doing so may create configuration conflicts you must investigate and resolve. Baselines carry no precedence of their own. Two customised instances of the same baseline is the single most productive way to generate conflicts I know of.
Older baseline versions are read only. When a new baseline version ships, profiles on older versions become read only. You can rename them and change their assignments but not their settings. So the fix for a conflict against an old baseline instance is not to edit it, and if you go looking for the setting to change you will not find an editable one.
Custom policies are not evaluated. Intune does not read the payload of a custom OMA-URI policy or an Apple Configuration file. It ships it. Nothing is checked against your other policies, and on Apple platforms conflicting custom settings are applied randomly. That is not a conflict you can diagnose from a report, because no report knows a conflict happened.
Not applicable is not conflict. A setting the device cannot receive, because of OS version or edition, reports Not applicable. It looks like a problem and is not one. Conflicts and inapplicability sit next to each other in the same status column and get treated the same way.
What I would do differently
The reporting is the symptom. The design is the cause, and there are three positions worth holding.
One setting, one owner. Decide, per CSP, which policy type owns it, write that down, and treat any conflict as evidence the rule was broken rather than as a routine cleanup task. Conflicts are cheap to resolve individually and expensive as a habit, because every one of them is a setting whose real value nobody can state from the console.
Prefer the settings catalogue as the single channel. Where the same control is available through a template, an endpoint security profile and the settings catalogue, pick the catalogue and stay there. The value is not that it is better but that it is one namespace, which makes the search in step three above actually work.
Assign to devices or to users, and be consistent per policy family. Mixed targeting is where conflicts appear months after the policies were written, at the moment somebody’s group membership changes rather than at the moment somebody deployed something. Consistency here removes an entire class of conflict rather than resolving instances of it.
And when a configuration profile conflict is reported, treat the setting as unconfigured until proven otherwise. Not weakened. Not overridden. Absent. The equivalent discipline for compliance rules on non Windows platforms is covered in custom compliance settings for macOS, and the same broad idea of checking what actually landed rather than what was assigned applies to Intune proactive remediations.
Last verified: 17 August 2026.
Where the setting is delivered by a script or a Win32 app rather than a profile, precedence is not the mechanism at all. That work is done by the Intune management extension, which has its own check-in cycle and its own logs.
