The Endpoint Security blade in Intune exists for a reason. It’s not a reorganized version of Configuration Profiles – it’s a purpose-built surface for security workloads that require dedicated policy types, dedicated conflict resolution behavior, and dedicated reporting.
The policies in this blade don’t configure general device behavior. They enforce specific security controls: disk encryption, local administrator password management, firewall rules, attack surface reduction, antivirus configuration, and endpoint detection and response onboarding. Each is a distinct workload with its own policy type, its own assignment model, and its own reporting surface in the Intune console.
Understanding this separation matters because the two surfaces behave differently when policies conflict. Settings Catalog policies conflict with each other when two profiles target the same setting – the result is a conflict error on the device. Endpoint Security policies have their own precedence model for some workloads, and in some cases the most recently applied policy wins. Knowing which surface a setting lives on is relevant to how you troubleshoot when something doesn’t behave as expected.
Since late 2024, Endpoint Security policies also appear in the Configuration blade. The visual distinction between SC and ES policies is no longer obvious from the UI alone – which is exactly why naming discipline matters.
OIB reflects this separation correctly. Its Endpoint Security policies are prefixed with ES in the naming convention – Win - OIB - ES - Encryption - D - BitLocker versus Win - OIB - SC - Device Security - D - Security Hardening. When you import OIB and look at the policy list, you can tell immediately which surface each policy lives on without opening it. That’s the naming convention doing its job.
BitLocker is configured through the Disk Encryption workload in Endpoint Security. The key decisions are silent enablement – whether BitLocker encrypts automatically without user interaction – and recovery key escrow to Entra ID. Silent enablement requires TPM 2.0 and modern hardware that meets the prerequisites. For most current Windows 11 devices this is straightforward. The recovery key escrow configuration is non-negotiable: keys must be backed up to Entra ID before encryption completes, otherwise you have encrypted devices with no recovery path when users forget PINs or hardware changes.
LAPS – Local Administrator Password Solution – is managed through its own Endpoint Security workload. Windows LAPS, which replaced the older Microsoft LAPS solution, backs up local administrator passwords to Entra ID and rotates them on a defined schedule. It’s essential for any environment where local administrator access might be needed for troubleshooting, and it eliminates the risk of shared static local admin passwords across a fleet. The 24H2 release added meaningful new LAPS capabilities including automatic account management – OIB v3.6 and later reflect these additions.
Firewall policy in Endpoint Security defines baseline firewall behavior – whether Windows Firewall is enabled per network profile, default inbound and outbound rules, and whether users can modify firewall settings. This is distinct from specific application firewall rules, which are managed separately. For most Intune-managed environments the default Windows Firewall behavior is appropriate and the main decision is ensuring it’s enforced and can’t be disabled by users.
ASR rules are where most environments get cautious – and for good reason. Several rules that look straightforward in documentation have well-documented compatibility issues with common enterprise software. Staged enforcement is not optional.
Attack Surface Reduction rules are configured through the ASR workload in Endpoint Security. ASR rules reduce the attack surface of Windows by blocking specific behaviors commonly exploited by malware – Office macros creating child processes, executable content from email clients, credential theft from LSASS, and others. The rules are individually configurable as Off, Audit, or Block. Audit mode logs what would have been blocked without actually blocking it, which is how you validate rule behavior before enforcement. Running rules in Audit mode for two to four weeks before switching to Block is the minimum responsible approach. Some rules – particularly those touching Office behavior and script execution – require careful validation in environments with complex macro or automation workflows.
Antivirus configuration in Endpoint Security overlaps with the Defender Antivirus Settings Catalog policies in OIB. OIB’s SC-based Defender policies handle configuration. The ES-based Defender policies in OIB handle update ring management – separating which ring receives definition updates. Understanding this split prevents accidental duplication and keeps the policy ownership clear.
Endpoint Detection and Response onboarding connects devices to Microsoft Defender for Endpoint. This is the bridge between Intune’s device management layer and Defender’s threat detection and response capabilities. Without EDR onboarding, Defender runs in a limited mode that doesn’t feed signals into the Defender for Endpoint portal, which means no device-based threat signals flowing into compliance or Conditional Access. EDR onboarding is covered more fully in the next article, which addresses Defender’s role in the broader architecture.
Intune Deployment Guide · Phase 5: Windows Security Configuration
‹ Previous: [5.2] Configuration Profiles and the OIB Approach
Next: [5.3.1] BitLocker: Designing Encryption Policy That Works ›
