Microsoft’s security baselines exist for a good reason. The intent behind them is solid – consolidate recommended settings, reduce decision fatigue, give teams a defensible starting point. On paper, that’s exactly what a baseline should do.
Where I’ve found consistent tension is not in the content of the settings, but in how they’re grouped. Microsoft baselines are large by design. They cover a lot of ground in a single policy object, and that breadth is both their appeal and their problem.
In real environments, controls rarely need to move together. Defender configuration evolves on a different schedule than encryption policy. Attack surface reduction rules often require staged enforcement – you test them in audit mode before switching to block. Browser configuration may need to differ across device classes or user populations. When all of those areas are bundled into one artifact, adjusting any single area means touching all of them. That’s more exposure than the change warrants.
Intune does not provide a clean override model. When two profiles define the same setting, the outcome is not resolved through precedence the way Group Policy once was.
That means configuration ownership needs to be deliberate from the start. Large, all-in-one baselines make that ownership harder to see – and harder to defend when something behaves unexpectedly.
I’ve also seen situations where different Microsoft-provided baselines influence related settings without making that overlap obvious. The Windows security baseline and the Defender baseline are logically separate, but their boundaries aren’t always clean. When something misbehaves, it’s not always clear which policy is responsible. That ambiguity compounds over time. Exceptions get added. Supplemental policies appear to work around constraints. The environment grows, but not in a structured way.
For that reason, I separate security configuration into modular sections aligned to control surfaces. Encryption stands on its own. Defender stands on its own. Attack surface reduction is isolated. Browser controls are isolated. Updates are structured independently. Each area has defined responsibility and a clear owner.
This makes targeting more precise. It allows enforcement to be staged without disturbing unrelated settings. It keeps configuration authority visible rather than buried inside a single artifact that nobody wants to touch six months later.
The goal is not to reject Microsoft’s guidance. The goal is to structure it in a way that aligns with how Intune actually evaluates policy.
Smaller, clearly scoped policies age better than large consolidated ones. They require more thought up front – clearer naming, more deliberate assignment discipline. But they remain manageable as the environment grows, and they make troubleshooting straightforward rather than archaeological.
That tradeoff has proven worthwhile every time. The next article gets into how naming and scope make that modular structure durable. Phase 5 is where this philosophy becomes concrete – covering the specific tools, policy surfaces, and frameworks that implement it in practice, including how OpenIntuneBaseline translates the modular approach into a deployable configuration for Windows devices.
Intune Deployment Guide · Phase 1: Foundations
‹ Previous: [1.1.1] How Intune Evaluates Configuration Profiles
Next: [1.1.3] Naming, Scope, and Assignment Discipline ›
