Intune security baseline conflicts are rarely caused by the thing the administrator was working on. A baseline is not a setting you chose, it is several hundred settings you accepted in one click, and the moment a second policy touches any one of them Intune stops applying both values. The second policy is usually not a configuration profile. It is another security baseline, and more often than not it is one the tenant created on its own behalf during a version update. What follows is where that second profile comes from, why the two Windows baselines Microsoft ships overlap by design, and what the admin centre will and will not tell you when you go looking for the pair.
The precedence rules that decide the outcome of any collision in Intune are a separate subject, and they are not uniform. Compliance settings beat configuration profile settings, two compliance policies resolve to the most restrictive value, and two configuration profiles resolve to nothing at all. Those four rules and the reporting behind them are set out in the Intune policy conflict walkthrough. This post assumes them and deals with the case baselines make special.
One disclosure before the detail. My tenant is a lab with no enrolled devices, so nothing below is a measured result. Every factual claim here is taken from Microsoft’s current documentation and verified on 17 September 2026, and the closing section is labelled as judgement rather than experience.
Why Intune security baseline conflicts behave differently
A configuration profile contains the settings you deliberately added. You can read the whole thing in a minute and you know what is in it. A baseline profile contains Microsoft’s entire recommended configuration for a product, and almost nobody reviews all of it before assigning. Microsoft’s own security baselines overview states the position directly: baselines often manage the same settings you might set with device configuration profiles or other policy types, and organisations should stay aware of those other policies in order to avoid or resolve conflicts.
Read that as an admission rather than a caution. Overlap is not a mistake an administrator makes. It is the default state of any tenant that has both a baseline and a settings catalog policy, because the baseline was authored to be complete and the settings catalog policy was authored to be specific. The two were never going to be disjoint.
The outcome when they disagree is the part that surprises people. Microsoft’s guidance on avoiding policy conflicts puts it in one sentence: devices and users targeted with the same setting from different policies cause conflicts, and when conflicts occur Intune generates an error and does not apply either setting. There is no tie break. A security baseline carries no elevated precedence because of the word security in its name. The setting that loses is the setting itself, which is left unconfigured on the device while both policies report a problem.
The scale is what makes baselines distinctive. A conflict between two settings catalog policies is one setting. A conflict between two baselines is a block of them, arriving together, in a report that gives you a device count rather than a cause.
The two baselines that overlap by design
As of 17 September 2026 the Intune admin centre offers, under Endpoint security and then Security baselines, a Security Baseline for Windows 10 and later, a Microsoft Defender for Endpoint baseline, a Microsoft 365 Apps for Enterprise baseline, a Microsoft Edge baseline, two HoloLens 2 baselines and two Windows 365 baselines. The current Windows baseline version is 25H2 and the current Defender for Endpoint baseline version is 24H1.
The first two are the ones that collide, and the reason is visible in their published settings lists. The Defender for Endpoint baseline does not confine itself to Defender. Its top level setting groups include BitLocker, Firewall, Microsoft Edge, Device Guard, Windows Hello for Business, Administrative Templates and Attack Surface Reduction Rules, alongside the Defender antivirus and endpoint detection and response settings you would expect. Every one of those groups also appears in the Windows baseline.
| Setting group | In the Windows 10 and later baseline | In the Defender for Endpoint baseline |
|---|---|---|
| Microsoft Defender antivirus | Yes | Yes |
| Attack Surface Reduction rules | Yes | Yes |
| BitLocker | Yes | Yes |
| Firewall | Yes | Yes |
| Microsoft Edge | Yes | Yes |
| Windows Hello for Business | Yes | Yes |
| Endpoint detection and response | No | Yes |
Assigning both baselines to the same device group is therefore not a belt and braces decision. It is a decision to have two policies write the same several dozen settings, and the values do not have to differ by much for the device to end up with neither. Both baselines sit on the same blade, one under the other, with nothing in the interface to suggest that deploying both is a problem.
Update Version is how one baseline quietly becomes two
This is the mechanism behind most of the conflicts that appear without anyone editing a setting. Microsoft’s instructions for configuring security baseline policies describe the Update Version workflow, and the behaviour is easy to misread.
- You select an existing baseline profile and choose Update Version.
- You choose whether to keep your existing setting customisations or discard them.
- Intune creates a new instance of the baseline at the latest version, as a side by side copy of the original profile, and asks you to name it.
- The new instance has no scope tags and no assignments. Neither is carried over.
- The original profile is left unchanged. It keeps its settings, its name, its scope tags and, critically, its assignments.
So the update does not update anything. It creates a second profile and leaves the first one running. The administrator assigns the new profile, sees it deploy, and closes the change. The old profile is still assigned to the same group, still writing the previous version’s values, and every setting whose default moved between the two baseline versions now has two policies asserting different values at the same device. Microsoft does say to revisit the older profile’s assignments to avoid conflicts between the old and new profiles. It says it once, in a note, after the step where you configure assignments.
The missing scope tags deserve their own mention, because a tenant that uses scope tags for delegated administration has just produced a profile that the team responsible for it cannot see. What scope tags do and do not restrict is covered in Intune scope tags, and a baseline that lost its tags during a version update is a good example of the gap being invisible until someone goes looking for a policy that is definitely there.
There is a second trap in the version story. Once a newer baseline version is released, settings in profiles built on the older version become read only. You can still change the old profile’s name, its description and its assignments, but not its settings, and you cannot create new profiles on the deprecated version. That removes the obvious remedy. You cannot de-conflict the old baseline by editing the handful of settings that clash. Your only moves are to unassign it, exclude the affected group, or delete it.
Where the conflict is actually reported
Three places, and they answer different questions.
Devices, then Monitor, then Configuration policy assignment failure gives you the devices affected. It is the right starting point and the wrong stopping point, because it tells you a device has a problem and not which two policies caused it.
The device configuration report, opened on the device itself, gives you the setting. Selecting a setting opens the settings details pane, which lists Source Profiles: every profile configuring that setting with a different value. That list is the answer. It is also the only place in the interface where both halves of a conflict appear next to each other, which is why conflict hunting that starts anywhere else takes so long.
The baseline’s own status view gives you the state. On baselines from May 2023 onwards the values are Succeeded, Error, Conflict, Pending and Not applicable, and Conflict means what it says: two settings are applied to the same device and Intune cannot sort out which should win. On profiles built from baseline versions older than that, Microsoft adds Matches default baseline, Matches custom settings and Misconfigured. Misconfigured is a roll-up of Error, Pending and Conflict, which means a device that has simply not checked in yet and a device with a genuine conflict report the same word. If a tenant is still running a pre May 2023 baseline profile, that single label is hiding the distinction that matters.
The failure modes
The patterns below each produce Intune security baseline conflicts for a different reason, and the fix differs accordingly. Identifying which one you are looking at is most of the work.
Both Microsoft baselines assigned to all devices. Dozens of Defender, Firewall and BitLocker settings report Conflict at once, on every device in scope, with no recent change to explain it. The cause is usually a deployment from two different projects that never compared notes.
Conflicts appear a day after a version update. Nothing in the settings changed, which is exactly why it is confusing. The old profile was never unassigned. Check the profiles list for two baselines of the same type with different versions and overlapping assignments before looking anywhere else.
Deleting the baseline to clear the conflict. The reporting goes green and the device stays configured. Microsoft is explicit that when a setting is no longer managed by a baseline profile, the setting does not reset on the device, it remains at its last configuration until some other process changes it, and that because the settings are backed by configuration service providers, each one handles removal differently. Deleting removes your visibility, not the configuration.
Assuming the baseline wins. It does not. Against another configuration class policy neither value applies, so a conflict between a baseline and a settings catalog policy leaves the device with whatever it had before either policy arrived.
Re-stating a baseline setting in a settings catalog policy for clarity. This is the most avoidable one. An administrator wants a firewall setting to be obvious, so it goes in a named policy as well as the baseline. If the two values match, nothing happens. If they drift apart later, the setting is lost. The same trap applies to older administrative template policies, and the question of which policy type to use for what is covered in settings catalog vs administrative templates.
Chasing a conflict that is a delivery problem. Pending and Error are not conflicts. A device that has not checked in produces a status that reads like a failure, and applying conflict logic to an enrolment or check-in issue costs an afternoon. The pattern of settings cancelling each other rather than failing to arrive also shows up in Intune update rings, which is worth reading if the affected settings are update related.
What I would do differently
This section is judgement, not measurement. I have not run a multi baseline estate in production, so treat it as reasoning from the documented behaviour rather than from a device count.
I would deploy one baseline per platform and no more. The Windows baseline is the broader of the two, so it goes first, and anything the Defender baseline adds that I actually want goes into a narrowly scoped settings catalog policy rather than the whole Defender baseline. That trades some coverage for a conflict surface small enough to reason about, and coverage you cannot keep configured is not coverage.
I would treat Update Version as a migration rather than an edit, and put the unassignment of the old profile in the same change window as the assignment of the new one. The read only rule makes deferral expensive: once the new version exists, the old profile can no longer be adjusted to sit alongside it, so the decision is binary and it is better made deliberately than discovered.
I would never delete a conflicting baseline as the first move. Unassign it, wait for devices to check in, confirm the setting state on a sample device, then delete. Deleting first destroys the record of what the profile was setting, and the settings stay on the device regardless.
And I would resist the urge to make a baseline setting explicit by repeating it elsewhere. If a value needs to be visible, customise it inside the baseline and document it outside Intune. Duplicating it in a second policy is how a setting that was configured becomes a setting that is not.
Last verified: 17 September 2026.
