Intune Policy Conflict Map: Baselines, Settings Catalog and Endpoint Security

The cleanest Intune tenants are not usually the most advanced. They are the ones with fewer policy arguments per device.

That is why a conflict map is worth writing down. You are not just deciding where settings live. You are deciding who owns them, who changes them, and how you prove they reached devices.

Without that map, tenants drift into a familiar pattern: the baseline exists, the settings catalog profile exists, the endpoint security profile exists, and a script still exists because nobody wanted to touch the old deployment.

Suggested ownership map

Control area	Preferred home	Notes
Defender Antivirus	Endpoint security	Best fit for security-first management and reporting
Defender Firewall	Endpoint security	Cleaner than hiding firewall rules in general config
BitLocker	Endpoint security	Easier to review encryption posture and drift
Local users and groups	Account protection	Better than using scripts as a permanent control
Windows hardening not covered elsewhere	Settings catalog	Broadest configuration surface
Compliance rules	Compliance policies	Keep access decisions separate from configuration
Update behavior	Windows update policies	Avoid mixing servicing logic into generic profiles

The point is not purity. The point is predictability.

How to build the map in a real tenant

1. Export policies.
2. Group them by control family, not by who created them.
3. Mark duplicates and contradictory values.
4. Pick the long-term owner for each control family.
5. Move one family at a time into that owner.
6. Confirm per-setting status and assignment results.
7. Remove the old duplicate only when the new path is stable.
8. Document the finished map in language a new admin can follow.

That last step gets skipped a lot. Then six months later someone recreates the conflict because the decision only lived in a meeting.

Where baselines fit

Security baselines are useful for recommended starting positions. They become a problem when they are left unreviewed while custom policy grows around them.

If a baseline setting stays, keep it because it still deserves to stay. If a more explicit policy now owns that area, retire the overlap.

A few modern gotchas worth remembering

Microsoft has moved some older identity and account protection approaches into a newer consolidated Account protection model. That is a good reminder that policy homes evolve. Your conflict map should evolve with them.

Also, Intune already gives you useful conflict evidence through per-setting status, device reports, and assignment failures. Too many teams still troubleshoot from memory before looking at the reporting that already exists.

The operating rule that keeps the tenant calm

For every important endpoint control, answer three questions:

1. Where is it configured?
2. Who owns it?
3. How do we prove it reached devices?

If the team cannot answer those, the estate is drifting.

If you want a simple rule, here it is: do not add a new policy until you can explain why an existing one is not the right home.

References

• Use security baselines to help secure Windows devices you manage with Microsoft Intune
• Manage account protection settings with endpoint security policies in Microsoft Intune
• See device configuration policies with Microsoft Intune