Sign In
In this module

AD3.6 Security Baselines vs Custom Profiles

5-6 hours · Module 3 · Free
Operational Objective
Intune offers two ways to configure device security: security baselines (pre-built configuration sets from Microsoft) and custom configuration profiles (individual settings you select). Security baselines apply hundreds of settings at once — MDL security baseline, Microsoft Edge baseline, Microsoft Defender for Endpoint baseline — but you don't control which settings are included and conflicts between baselines are common. Custom profiles give you granular control but require you to know exactly which settings matter. Most IT administrators deploying security for the first time face this choice without enough context to make it well. This subsection explains when to use baselines, when to use custom profiles, how to avoid the conflicts that break both, and the practical recommendation for an M365 E3 environment.
Deliverable: A clear decision on baselines vs custom profiles for your environment, with the rationale documented and the chosen approach deployed.
Estimated completion: 25 minutes
SECURITY BASELINES vs CUSTOM PROFILES SECURITY BASELINES ✓ Pre-configured by Microsoft ✓ Covers hundreds of settings at once ✓ Updated when Microsoft releases new baselines ✗ Conflicts with other baselines/GPO ✗ Can't see what changes without deep review ✗ Overrides settings you configured deliberately Best for: new environments with no existing config CUSTOM PROFILES ✓ You choose exactly which settings to configure ✓ No conflicts with existing GPO/baseline settings ✓ Full control over every value ⚠ Requires knowing which settings matter ⚠ More setup work than baselines ⚠ You maintain updates, not Microsoft Best for: environments with existing GPO or config

Figure AD3.6 — Security baselines provide breadth (hundreds of settings at once) but risk conflicts. Custom profiles provide precision (only the settings you choose) but require more knowledge. For an IT administrator adding security to an existing managed environment, custom profiles are usually the safer choice.

The practical recommendation

For NE's environment — and for most organizations where an IT administrator is adding security to an existing Intune-managed environment — custom configuration profiles are the better choice. Here's why.

NE already has Intune deployed for device management. There are existing configuration profiles for WiFi, VPN, application deployment, and Windows Update rings. A security baseline applies hundreds of settings, many of which may conflict with these existing profiles. Conflicts between baseline settings and custom profile settings produce unpredictable results — the device may get the baseline setting, the custom setting, or neither.

The specific settings that matter for security — BitLocker encryption, firewall configuration, Defender Antivirus settings, Windows Update compliance — are better deployed as individual custom profiles where you control exactly what's configured. This avoids the conflict problem entirely and makes troubleshooting straightforward: if a setting isn't applied, you check one profile, not a matrix of overlapping baselines.

If you're building a new environment from scratch with no existing Intune profiles and no GPO inheritance, security baselines are a reasonable starting point — they provide a solid default configuration quickly. But review every setting in the baseline before deploying. Microsoft's recommended settings are a good starting point but not universally appropriate — some settings break specific applications, and others are more restrictive than necessary for your environment.

Creating the security configuration profiles

Instead of applying a full security baseline, create targeted configuration profiles for the settings that matter most. Navigate to intune.microsoft.com → Devices → Configuration → Create profile.

Profile 1 — BitLocker encryption. Platform: Windows 10 and later → Profile type: Endpoint protection → Windows Encryption. Configure: require device encryption, encrypt all drives, compatible TPM startup (allow TPM). Deploy to all Windows devices. This profile enables BitLocker silently on all enrolled devices and stores recovery keys in Entra ID.

Profile 2 — Windows Firewall. Platform: Windows 10 and later → Profile type: Endpoint protection → Microsoft Defender Firewall. Configure: enable firewall for domain, private, and public profiles, block all inbound connections by default, allow outbound. Deploy to all Windows devices.

Profile 3 — Defender Antivirus. Platform: Windows 10 and later → Profile type: Endpoint protection → Microsoft Defender Antivirus. Configure: enable real-time protection, enable cloud-delivered protection (high), enable automatic sample submission, schedule quick scan daily. Deploy to all Windows devices.

Profile 4 — Windows Update. Platform: Windows 10 and later → Profile type: Update rings for Windows 10 and later. Configure: quality update deferral 7 days, feature update deferral 30 days, deadline for quality updates 5 days, deadline for feature updates 14 days. Deploy to all Windows devices.

Each profile targets one security domain. No overlaps. No conflicts. Clear troubleshooting path. If a device has an issue with BitLocker, you check Profile 1. If antivirus isn't configured correctly, you check Profile 3. This is far simpler than debugging a security baseline that touches hundreds of settings.

Attack Surface Reduction rules — the highest-value custom settings

Beyond the four core profiles above, Attack Surface Reduction (ASR) rules provide significant protection against common attack techniques. These are Intune configuration settings that block specific malware delivery mechanisms without requiring Defender for Endpoint licensing.

Navigate to intune.microsoft.com → Endpoint security → Attack surface reduction → Create policy → Windows 10 and later → Attack Surface Reduction Rules.

The highest-impact ASR rules to enable first:

  • Block executable content from email client and webmail: Prevents users from running executables delivered via email — a primary malware delivery vector.
  • Block all Office applications from creating child processes: Prevents Office macros from launching PowerShell, cmd, or other processes — blocks the most common macro malware technique.
  • Block JavaScript or VBScript from launching downloaded executable content: Prevents script-based payload downloaders.
  • Block Office applications from injecting code into other processes: Prevents Office-based process injection attacks.

Set each rule to Audit mode first (not Block). Audit mode logs what would have been blocked without affecting users. Run in audit mode for 2 weeks and review the audit log (Defender → Reports → Attack surface reduction or Event Viewer → Applications and Services Logs → Microsoft → Windows → Windows Defender → Operational). If legitimate processes appear in the audit log, create exclusions before switching to Block mode.

# Verify ASR rules are applied
Get-MpPreference | Select-Object -ExpandProperty AttackSurfaceReductionRules_Ids
Get-MpPreference | Select-Object -ExpandProperty AttackSurfaceReductionRules_Actions

ASR rules are available on E3 — they don't require E5 or Defender for Endpoint. They're one of the most effective security controls included in your existing license that most administrators never enable. Deploying them as a custom profile (not via a security baseline) gives you control over which rules are active and which are in audit mode.

When you DO have Defender for Endpoint (E5)

If your organization upgrades to E5 or adds Defender for Endpoint as an add-on, the device compliance landscape changes significantly. MDE provides a device risk score that you can integrate with Intune compliance: a device with "High" risk (active malware detected, vulnerable configuration) is marked non-compliant regardless of other compliance checks.

This integration is configured in intune.microsoft.com → Endpoint security → Microsoft Defender for Endpoint → Connection settings. Enable the connection, then add a "Device threat level" check to your compliance policy: set it to "Medium" or "Low and above" to require devices to have an acceptable risk score.

This is future-proofing: you don't need it now on E3, but knowing the integration exists means you can plan for it if E5 becomes available.

Troubleshooting configuration profile conflicts

When a device setting isn't applying correctly, the cause is usually a profile conflict. Intune shows conflicts in two places:

Device page → Device configuration. Navigate to intune.microsoft.com → Devices → select the device → Device configuration. This shows every profile assigned to the device with its deployment status. "Succeeded" means the profile applied. "Conflict" means a setting in this profile conflicts with a setting in another profile. Click the conflicting profile to see which specific settings are in conflict.

Reports → Device assignment status. Navigate to intune.microsoft.com → Reports → Device configuration → Assignment status. This shows across all devices which profiles are succeeding, failing, or conflicting. A profile with a high conflict rate needs investigation — it's probably overlapping with another profile or a GPO.

The most common conflict pattern: an Intune security baseline and a custom configuration profile both configure the same Windows Firewall setting. The baseline sets "Block all inbound" and the custom profile sets "Allow RDP inbound." Both are valid settings but they can't coexist. Resolution: remove the firewall settings from one source. Since the custom profile was built deliberately for your environment and the baseline is generic, remove the firewall settings from the baseline (or don't use the baseline at all — which is the recommendation from this subsection).

For environments migrating from GPO to Intune, GPO settings may conflict with Intune profiles. Check whether the device is receiving both GPO and Intune settings for the same configuration. The general precedence is: Intune configuration profile > GPO for Intune-managed settings, but this varies by setting type. The cleanest approach is to remove GPO settings for any configuration managed through Intune — don't manage the same setting from two sources.

Verifying that configuration profiles are applying correctly

After deploying your four custom security profiles, verify each one is applying to the target devices:

Connect-MgGraph -Scopes "DeviceManagementConfiguration.Read.All"

# List all configuration profiles and their assignment status
Get-MgDeviceManagementDeviceConfiguration -All |
    Select-Object DisplayName, @{N="Platform";E={$_.AdditionalProperties.'@odata.type'}},
        LastModifiedDateTime |
    Format-Table -AutoSize

For a specific profile, check the per-device deployment status in the portal. Navigate to intune.microsoft.com → Devices → Configuration → select the profile → Device status. This shows every device the profile targets with the deployment result: Succeeded, Pending, Error, or Conflict.

Succeeded: The profile settings are applied on the device. No action needed.

Pending: The device hasn't checked in since the profile was assigned. Trigger a sync from the device page or wait for the next scheduled check-in (every 8 hours).

Error: The profile failed to apply. Click the device entry to see the error detail. Common errors: "Not applicable" (the device OS doesn't match the profile platform), "Remediation failed" (a setting can't be applied — e.g., BitLocker on a device without TPM), or "Access denied" (insufficient permissions for the Intune management extension).

Conflict: Another profile or GPO configures the same setting with a different value. Click the device entry to see which profiles are conflicting. Resolve by removing the duplicate from one source.

Run this verification for each of your four profiles (BitLocker, Firewall, Defender AV, Windows Update) within 48 hours of deployment. Any device showing Error or Conflict needs investigation before you rely on the profile for compliance enforcement.

Compliance Myth: "Security baselines are always better because Microsoft designed them"
Microsoft designed security baselines for a generic Windows environment with no existing configuration, no GPO, and no third-party software. Your environment isn't generic — it has line-of-business applications, existing GPO settings inherited from on-premises AD, Intune profiles for device management, and users with specific workflow requirements. A security baseline that overrides your VPN configuration, changes your proxy settings, or disables a feature your LOB application depends on creates more problems than it solves. Custom profiles that target specific security settings avoid these conflicts and give you full control over what's configured. Use baselines as a reference — read them to understand what Microsoft recommends — but deploy custom profiles for the settings that matter to YOUR environment.
Decision point

You deploy the MDE security baseline and discover that it conflicts with your existing VPN configuration profile — the baseline sets a Windows Firewall rule that blocks the VPN client's network traffic. Users can no longer connect to the corporate VPN. What do you do?

Option A: Modify the security baseline to remove the conflicting firewall rule — This works but creates a customized baseline that you need to maintain with every baseline update.

Option B: Remove the security baseline entirely and create a custom firewall profile that includes the security rules without the VPN conflict — Correct. This eliminates the conflict source and gives you full control. You know exactly which firewall rules are applied and can troubleshoot any future conflicts without checking a baseline that contains hundreds of settings.

Option C: Modify the VPN profile to work around the baseline firewall rule — Working around a security setting to accommodate a management setting is backwards. The firewall rule may be providing legitimate protection. Understand what the rule does before modifying either profile.

Try it: Review existing Intune profiles for conflicts

Navigate to intune.microsoft.com → Devices → Configuration → Policies. List all existing configuration profiles. For each profile, note: the profile type, the settings it configures, and the groups it's assigned to.

Now navigate to Endpoint security → Security baselines. Check if any baselines are deployed. If a security baseline is active, compare its settings against your existing custom profiles. Look for any setting that appears in both the baseline and a custom profile — these are potential conflicts.

If you find conflicts: document them. Decide which source should control each setting. Remove the duplicate from the lower-priority source. If no baselines are deployed: keep it that way and use custom profiles (as recommended in this subsection) for targeted security configuration.

Create one custom profile now: the BitLocker encryption profile. Deploy it to a pilot group of 5-10 devices. After 48 hours, verify BitLocker is enabled on those devices (Devices → All devices → select a pilot device → Hardware → look for "Encryption status: Encrypted"). If successful, expand to all devices.

You deploy the Microsoft security baseline for Windows and a custom configuration profile that sets the Windows Firewall to allow inbound RDP connections for remote support. The baseline also configures the firewall but blocks all inbound RDP. Both profiles are assigned to the same devices. What happens?
The custom profile wins because custom profiles always override baselines — Not necessarily. Intune doesn't have a deterministic precedence rule between baselines and custom profiles. The result depends on which profile processes last.
The baseline wins because baselines are more authoritative — Also not guaranteed. There's no hierarchy between baselines and custom profiles.
Both settings are applied and Intune merges them — No. Conflicting binary settings (allow vs block) can't be merged. One wins. Which one is unpredictable.
The result is unpredictable — Intune shows a conflict error on the device, and the actual setting depends on processing order, which can change between check-ins — Correct. This is the fundamental problem with overlapping baselines and custom profiles. Intune detects the conflict and reports it, but the actual device state is non-deterministic. The solution is to avoid the overlap: don't configure the same setting in both a baseline and a custom profile. Use one source of truth per setting.
Operational Artifact — Configuration Profile Register
Document each Intune configuration profile you deploy: profile name, type, key settings, assigned groups, and deployment date. Keep this register alongside your compliance policies, conditional access policies, and email protection policies. When troubleshooting a device issue, check the profile register to identify which profiles should be applied. When adding new settings, check the register first for conflicts with existing profiles. This prevents the incremental accumulation of overlapping configurations that causes unpredictable device behavior.
© 2026 Ridgeline Cyber Defence™ Ltd. Content may not be reproduced or redistributed. Worked artifacts may be adapted for use within your organization.

You're reading the free modules of M365 Security: From Admin to Defender

The full course continues with advanced topics, production detection rules, worked investigation scenarios, and deployable artifacts.

View Pricing See Full Syllabus
← Previous Next →