When most people talk about security baselines in Intune, they mean one of two things: the Microsoft-provided baseline templates, or a vague idea that devices should have “security settings” applied. Neither framing is useful for building something that actually holds up.
Microsoft’s security baselines exist and they’re worth understanding – not because you should deploy them wholesale, but because understanding why they fall short clarifies what you’re actually trying to build. They’re large, monolithic policy objects that bundle a wide range of settings together. Apply one and you get broad coverage quickly. Try to adapt it and you immediately hit the problem: Intune has no surgical override mechanism. You can’t adjust one setting inside a Microsoft baseline without excluding the entire baseline from the device. The package is the unit. That’s fine until a setting causes a problem, and then it’s a significant problem.
The overlap issue compounds this. Microsoft ships separate baselines for Windows, Defender for Endpoint, and Edge – and these baselines configure related settings in ways that don’t always align cleanly. When a device behaves unexpectedly, the troubleshooting path involves checking multiple baselines for conflicting values, which is genuinely difficult when each baseline is itself a black box of bundled settings.
The fundamental problem with Microsoft’s baselines isn’t the settings – it’s the structure. Bundling unrelated controls together means you can’t adjust one without accepting risk across all of them.
The approach I use is built around separation of concerns. Security configuration for Windows devices in Intune lives across two distinct policy surfaces that serve different purposes, and keeping them separate is what makes the environment manageable over time.
The first surface is Configuration Profiles – specifically the Settings Catalog. This is where the majority of Windows security configuration lives: browser hardening, device security settings, Windows Hello for Business, OneDrive configuration, Microsoft Office security, script file associations, and more. These are Settings Catalog-backed policies that show up in the Configuration Profiles blade. They configure the device’s behavior and posture across a wide range of control surfaces.
The second surface is the Endpoint Security blade. This is purpose-built for a specific set of dedicated security workloads – BitLocker disk encryption, Windows LAPS, Firewall, Attack Surface Reduction rules, Antivirus, and Endpoint Detection and Response. These policies have their own conflict resolution behavior and are separate from Configuration Profiles by design. An important note: since a UI change in late 2024, Endpoint Security policies also appear in the Configuration blade, which creates visual confusion. The naming convention you use needs to make the distinction obvious – more on that in the next article.
Treating Configuration Profiles and Endpoint Security as interchangeable is one of the most reliable ways to create policy conflicts that are hard to diagnose.
The framework I use for the Settings Catalog layer is OpenIntuneBaseline, maintained by James Robinson at SkipToTheEndpoint on GitHub. OIB is a community-driven, modular baseline that separates configuration by control surface – Defender Antivirus, Device Security, Edge, Office, Windows Hello, OneDrive, and more – each as its own policy with its own naming, scope, and version. It exists because the monolithic baseline experience does not survive contact with real operations: James built it as a known-good starting posture, drawing on NCSC, CIS, and ACSC guidance alongside Microsoft’s own, restructured into discrete policies an administrator can actually own, version, and adjust. It is built for cloud-native, Entra-joined devices; hybrid-joined estates are explicitly out of scope. It’s currently at v3.8 and is my starting point for every new cloud-native Windows deployment.
OIB is not a magic button. It’s a starting point that reflects a large amount of accumulated real-world experience. It deviates from CIS and Microsoft recommendations deliberately and documents why – which is exactly the kind of opinionated, defensible approach that works well in practice. You still need to understand what you’re deploying and adjust it for your environment.
One hard constraint worth stating clearly: OIB is designed for cloud-native, Entra-joined devices running Windows 11. It is not designed for hybrid scenarios. Applying it over Group Policy on domain-joined devices produces unpredictable results, and GPO registry remnants can cause settings to appear misconfigured even when Intune reports success. If your environment still has hybrid devices, maintain GPO for those machines and reserve OIB for your cloud-native fleet.
The articles that follow in this phase cover how to deploy this structure in practice – what OIB covers and how to import and manage it, how to layer the Endpoint Security policies on top, how Defender for Endpoint connects into the broader compliance and access model, and how to handle updates through Autopatch. Each is a separate layer doing a distinct job. Understanding that separation is what makes troubleshooting tractable and what keeps the environment manageable as it grows.
Intune Deployment Guide · Phase 5: Windows Security Configuration
Next: [5.1.1] The Modular Baseline Playbook: Deploying OIB in Practice ›
