Difference between "Devices > Configuration Profiles" and "Endpoint Security > Manage"

Frequent Contributor

Our organization is digging deeper into Intune and one thing that confuses us are the multiple places where you can configure the same thing and how that leads to conflicts, e.g. Folder Protection.


Folder Protection can be enabled through a configuration profile under Devices > Configuration profiles > Create profile > Endpoint Protection:




The same thing can be accomplished by using "Endpoint Security> Attack Surface Reduction":



Which of both approaches should be used? Why do conflicts appear when one option is set to Audit Only and Option is set to Enable - should the more the secure option be considered?

6 Replies

A conflict arises when more than 1 policy is available and applicable of the same setting. Intune is just a delivery service. It doesn't decide which setting is best and enforce on its own. With that said, if your sole purpose is to target the security settings, then use endpoint security profiles as they are tailored specifically keeping device security in mind. For everything else, you can use device configuration profiles.

Thank you, understood. One follow-up question: the profiles in "Security Baseline" do not seem to follow the logic of the "Endpoint Security" configuration, but of the "Device Configuration". Isn't Microsoft indirectly telling you to use "Device Configuration" when they are distributing the Security Baselines in this manner?
best response confirmed by Kiril (Frequent Contributor)
Good point. Security baselines were added before Endpoint security profiles were really introduced. While security profiles are more direct, security baselines follow the same logic to that of baseline templates that are available in GPO. It is meant to be a baseline of security policies which you can deploy and then build over it. Device configuration, endpoint security profiles, security baselines have their own individual purposes and at the end of the day it will come down to organization's requirements.
So basically anything that can be configured in "Endpoint security" should be configured using "Endpoint security" policies, and policies which are only availble in "Device configuration" should be configured in "Device configuration".

@KirilThat's completely correct.


I'll make it even more precise for you... there's a specific order to this madness and it all comes down to Settings Catalogs. You see, almost everything under Endpoint Security (including baselines) boils down to a Settings Catalog template with a fancy GUI. It looks like this is where Intune is moving, as more and more stuff gets added in this form.


Microsoft actually has an order of preference for you configurations:


  • Endpoint Security > Security baselines
  • Endpoint Security > Other templates
  • Devices > Configuration profiles > Settings Catalog
  • Devices > Configuration profiles > Other templates
  • Devices > Scripts

This opens up a whole new can of worms when it comes to conflict resolution. All these things can cause conflicts with each other and to make things worse Settings Catalogs (or derivatives) tend to use different names for settings than other configuration profiles. 


Luckily though, MEM is getting better and better at telling you when and where a conflict arises. 


For more information about Settings Catalogs and the options they give you:

Create a policy using settings catalog in Microsoft Intune | Microsoft Docs

Configuration service provider reference - Windows Client Management | Microsoft Docs

Thank you for your clarification.

I actually noticed another feature of the order of preference: I had a policy in Endpoint Security > Attack surface reduction about Attack surface reduction rules. I set them to block, but it was not working. There were no conflicts, but no rules were applied to any of the configured devices.

Then I noticed that I had another Endpoint protection profile in Devices > Configuration profiles, which set all ASR rules to "Audit mode". So this profile was preferred, which is fine, but I expected at least to get a conflict when I enabled the policy in Endpoint security. After setting the Device configuration profile to "Not configured", the Endpoint Security policy worked as expected.