Hardening a Windows device from scratch means deciding on hundreds of individual settings, most of which you will get slightly wrong. Intune security baselines short-circuit that: they are pre-built groups of settings the Microsoft security team recommends, delivered as a template you assign rather than a spreadsheet you transcribe. This post covers deploying them, the two behaviours that surprise people — version updates that quietly drop their assignments, and setting conflicts that fail rather than resolve — and how to treat a baseline as a starting point rather than gospel.
Key Takeaways
- Intune security baselines are preconfigured, Microsoft-recommended setting groups you deploy as a profile, built by the same team that produces the Group Policy baselines.
- Updating a baseline to a new version creates a copy without the original's group assignments, so an updated baseline deploys to nobody until you reassign it.
- When two policies set the same value differently, Intune reports a conflict and does not silently pick a winner — you have to find and resolve it.
- Attack surface reduction rules are the exception: they merge across policies into a superset rather than conflicting.
- A baseline is a starting point to customize and test, not a profile to deploy blindly to production on day one.
Environment
- Microsoft Intune (Plan 1) with Windows 10/11 devices enrolled.
- Entra ID, with devices Entra joined or Microsoft Entra hybrid joined.
- Optional: Microsoft Defender for Endpoint, which has its own dedicated baseline.
- The Endpoint Security Manager Intune role, or equivalent, to manage baselines.
The Problem
Security configuration is a place where good intentions produce inconsistent results. One administrator hardens a device one way, another does it slightly differently, and six months later the fleet is a patchwork of almost-but-not-quite-aligned settings. Group Policy baselines existed to fix this on-premises, but they do not travel to a cloud-managed, Entra-joined fleet.
Intune security baselines are the modern equivalent. Microsoft partners the Intune baselines with the same Windows security team that authors the Group Policy ones, so you get a curated, opinionated set of settings as a deployable template. The catch is that "deployable template" hides some behaviour that is not obvious from the console — particularly around versioning and conflicts — and a baseline applied without understanding those will either silently stop protecting devices or break things you did not expect. Knowing how they behave is the difference between a hardening win and a support backlog.
The Solution
Step 1 — Pick the right baseline for the job
In the Intune admin center, go to Endpoint security → Security baselines. You will see several: the Security Baseline for Windows, the Microsoft Defender for Endpoint baseline, the Microsoft Edge baseline, and others depending on your licensing. They overlap deliberately — the Windows baseline covers OS hardening, the Defender baseline covers the endpoint protection stack, and so on.
Start with one. The Windows security baseline is the natural first deployment because it is the broadest. Do not enable every baseline at once, because the more baselines you stack, the more likely two of them touch the same setting — which leads directly to the conflict behaviour in Step 4. Microsoft's overview of Intune security baselines lists what each one covers.
Step 2 — Create the profile and review before assigning
Creating a baseline profile generates a template populated with Microsoft's recommended values. Before you assign it, read through the settings. The defaults are sensible for most environments, but some are aggressive enough to break legitimate workflows — legacy authentication settings, PowerShell restrictions, and remote-management settings are common sources of "why did this stop working" after a baseline lands.
Anything that restricts PowerShell is worth particular attention, because it interacts with logging and tooling you may rely on — the same surface I wrote about in PowerShell script block logging with Event ID 4104. Note the settings you change from the recommended value and why, because you will want that record when you update to a new baseline version later.
Step 3 — Assign to a pilot ring first
Assign the baseline to a small pilot group — IT and a tolerant business unit — not the whole fleet. A baseline changes a lot of settings at once, and the failure modes are easier to diagnose on ten devices than on a thousand. Give it time to apply, then check that the pilot devices still do everything they need to: line-of-business apps, VPN, printing, remote support. Only widen the assignment once the pilot is boring.
This is the same staged-rollout discipline that applies to any broad configuration change, and it pairs naturally with the monitoring you should already have in place — the event sources in Sysmon configuration for Windows security monitoring will show you behavioural changes a baseline introduces.
Step 4 — Understand conflicts before stacking baselines
Here is the behaviour that surprises people most. When two policies — two baselines, or a baseline and a configuration profile — set the same setting to different values, Intune does not resolve it by picking the most restrictive or the most recent. It reports a conflict, and the setting is not reliably applied to the device. You have to find the conflicting policies and align them yourself.
The one notable exception is attack surface reduction rules, which Intune merges across policies into a superset rather than treating differing rules as a conflict. For everything else, the practical rule is: minimize overlap. If you run the Windows baseline and the Defender baseline together, review where they touch the same settings and decide deliberately which one owns each, rather than discovering a conflict in the monitoring report weeks later.
Step 5 — Handle version updates without dropping coverage
Baselines are versioned, and Microsoft releases new versions as recommendations evolve. You can move a profile to a newer version without creating a new baseline from scratch — but the update behaviour has a trap. When you update, Intune creates a copy of the profile that does not include the original's group assignments. The updated baseline deploys to nobody until you re-add the assignments.
In practice this means a version update is a two-step operation: update the profile, then immediately reassign it to the same groups, and remove the assignments from the old instance so the two versions are not both live and conflicting. Skip the reassignment and you have devices silently running an outdated baseline — or no baseline at all — while the console shows a shiny new version that protects nothing.
Frequently Asked Questions
How are Intune security baselines different from Group Policy baselines?
They are authored by the same Microsoft security team and represent the same hardening philosophy, but Intune baselines are delivered as cloud-managed profiles for Entra-joined devices rather than as Group Policy objects. They are the modern path for fleets that are not domain-managed.
What happens when two baselines conflict on the same setting?
Intune reports a conflict and does not apply the setting reliably; it does not automatically choose a winner. You must identify the conflicting policies and align them. Attack surface reduction rules are the exception, as they merge into a superset across policies.
Why did my devices stop receiving a baseline after I updated its version?
Updating a baseline to a new version creates a copy without the original's group assignments. Until you reassign the updated profile to its target groups, it deploys to no devices. Always reassign immediately after updating, and remove the assignment from the old version.
Can I change individual settings in a baseline?
Yes. A baseline is a starting template, and you can adjust any setting from Microsoft's recommended value to fit your environment. Record what you changed and why, since you will want that list when migrating the customizations to a future baseline version.
Should I deploy every available baseline?
No. Each additional baseline increases the chance of two baselines touching the same setting and producing a conflict. Start with the Windows security baseline, add others only where they cover distinct ground such as Defender for Endpoint, and review the overlap deliberately.
Conclusion
Security baselines are one of the fastest ways to bring a Windows fleet up to a sane hardening standard, precisely because someone competent already made the hundreds of decisions for you. Deployed thoughtfully, a baseline replaces a patchwork of inconsistent configuration with a single, curated, repeatable standard.
The two things that will bite you are not in the settings themselves but in the mechanics around them: version updates that silently drop their assignments, and conflicts that fail instead of resolving. Treat a baseline as a starting point to customize and pilot, mind those two behaviours, and you get the curated hardening without the surprises. Skip the understanding and you get a console that claims devices are protected while the reality drifts somewhere else entirely.
Related Posts
- Sysmon Configuration for Windows Security Monitoring — the monitoring that shows you what a baseline actually changed.
- PowerShell Script Block Logging with Event ID 4104 — a setting surface baselines touch and that you likely rely on.
- Essential Conditional Access Policies for Microsoft 365 — the identity-side controls that complement device hardening baselines.
Editorial note: posts on this blog are drafted with AI assistance and then reviewed, edited, and tested against a real environment before publishing. Commands, output, and screenshots come from systems I actually ran the work on.
0 comments:
Post a Comment