Windows Security Baseline Hardening with Intune · CloudEngineerHub
Windows10 min read1 views
Windows Security Baseline Hardening with Intune: From Download to Enforcement
Import the Microsoft Security Baseline into Intune the right way: what to keep, what to override, how to resolve conflicts with settings catalog policies.
C
CloudEngineerHub Team
Published: September 1, 2026· Last Updated: September 28, 2026·10 min read
Windows Security Baseline Hardening with Intune: From Download to Enforcement
A hardening project dies quietly: the baseline zip gets downloaded, a few GPOs get imported, half the settings apply, a printer stops working, someone panics, everything gets reverted, and six months later the auditors ask why your servers still allow unauthenticated SMB. The difference between that story and a real hardening program is knowing exactly which settings you are adopting, which you are overriding, and how you will detect drift when someone "fixes" a GPO at 16:00 on a Friday.
Visual Walkthrough
From Microsoft's download to drift-free enforcement in five gates.
C
CloudEngineerHub Team
Author
The CloudEngineerHub editorial team — Microsoft endpoint management and cloud engineers writing hands-on guides on Intune, Azure, Entra ID, Autopilot, Defender and PowerShell. Every article is reviewed against current Microsoft documentation.
TimelineSecurity Baseline — Download to Enforcement5/5
phase 1
1
Download + inventory
Baseline security template grabbed; current estate baselined.
phase 2
2
Gap analysis
Compare against GPO/Intune reality; conflicts listed.
phase 3
3
Pilot ring enforced
Baseline applied to canary devices; telemetry watched.
phase 4
4
Adjust + document
Exceptions documented with owners and expiry.
phase 5
5
Fleet enforcement
Broad assignment; drift detection via compliance + scripts.
Security Baseline — Download to Enforcement. 1. Download + inventory: Baseline security template grabbed; current estate baselined. — 2. Gap analysis: Compare against GPO/Intune reality; conflicts listed. — 3. Pilot ring enforced: Baseline applied to canary devices; telemetry watched. — 4. Adjust + document: Exceptions documented with owners and expiry. — 5. Fleet enforcement: Broad assignment; drift detection via compliance + scripts.
This guide walks the full path: which baseline to use, how the Intune security baseline flow works, what to keep versus override (BitLocker, Credential Guard, SMB signing), how baseline/settings-catalog/GPO conflicts resolve, and how to detect drift before an auditor does.
Prerequisites
Intune Administrator or Endpoint Security Manager role for baseline management; Global Reader to review.
Intune Plan 1 (included in M365 E3/E5, EMS E3/E5) — security baselines are an Intune feature, not a Defender add-on.
Devices: Windows 11 24H2/25H2, enrolled and syncing (check-ins every 8 hours or on manual sync).
For GPO cleanup work: a domain admin account to export GPOs, and access to Group Policy analytics in the Intune admin center.
Microsoft Security Compliance Toolkit (for Policy Analyzer and the downloadable baselines) from Microsoft's Download Center.
Choose the Right Baseline Source
Two distinct things are called "Microsoft security baselines," and mixing them up causes most of the confusion:
Microsoft Security Compliance Toolkit (SCT) — downloadable GPO backups and documentation for Windows 11 24H2, Windows Server 2025, Microsoft 365 Apps, and Edge. These are files you import into Active Directory GPOs, inspect with Policy Analyzer, or use as a comparison reference. They do not deploy through Intune directly.
Intune security baselines — cloud-hosted baseline profiles inside the Intune admin center (Endpoint security > Security baselines): a Windows 11 24H2 baseline, Microsoft Edge baseline, Microsoft 365 Apps for enterprise baseline, and a Microsoft Defender for Endpoint baseline. These are MDM-backed profiles you assign like any configuration profile.
If your target fleet is Intune-managed Windows 11, the Intune 24H2 baseline is the correct starting point — every setting in it is deliverable via MDM, which the raw SCT GPOs cannot claim. Keep the SCT copy anyway: it documents the intent of each setting, and Policy Analyzer remains the best diff tool in the Windows ecosystem.
Field note: Baseline shopping is a trap. One baseline source of truth per device type, versioned like code. The orgs with the cleanest posture run one Windows baseline, one Edge baseline, one M365 Apps baseline — not six half-adopted variants from different audit seasons.
Import and Deploy the Intune Baseline
The flow takes fifteen minutes; the judgment calls take days:
In the Intune admin center, go to Endpoint security > Security baselines and select the Windows 11 24H2 baseline (pick the newest available version — Microsoft ships updates to the baseline periodically as new versions, not edits).
Create a profile (instance). Every setting is pre-populated with Microsoft's recommended value; you review rather than author.
Adjust the settings your environment must override — see the next section for the usual suspects.
Assign to a pilot group, not "all devices." Treat the baseline assignment like a feature update rollout: pilot, then broad.
Watch the profile's device status until pilot reports success, then widen.
The two structural rules
Two structural rules matter here. First, you cannot edit a baseline version — you can only edit your instance of it. When Microsoft publishes a new baseline version, you create a new instance from it; the "compare baselines" view diffs the two versions so you know exactly what changed before you re-approve. Second, baseline instances are configuration profiles under the hood, which is why they participate in (and lose to) the same conflict machinery as everything else — more on that below.
What to Keep, Override, and Exclude
The Windows 11 baseline is aggressively secure, which is the point, but a few settings reliably bite enterprise fleets. Review these before assignment:
BitLocker: The baseline enables silent encryption with recovery key escrow to Intune — keep it. Confirm the escrow settings and that your helpdesk can retrieve keys with the right RBAC role; a BitLocker recovery storm with locked-down key access is a self-inflicted outage.
VBS / Credential Guard: Enabled by default on Windows 11 Enterprise since 22H2, and the baseline keeps it on. Third-party agents that load unsigned kernel drivers will fail — coordinate with your EDR/AV vendor before, not after.
SMB signing: Windows 11 24H2 already requires SMB signing for outbound client connections; the baseline enforces it server-side too. Legacy NAS devices and printers that cannot negotiate signing will break — inventory them first.
UAC, screen lock, password policies: Usually keep, but reconcile with any identity-driven controls (Entra ID + Windows Hello for Business changes the conversation).
RDP and network settings: The baseline restricts anonymous enumeration and NTLM where feasible. Check your legacy file shares before these hit the pilot.
Make overrides auditable
Document every override in the instance's description field. Six months from now, "we changed it because printers" is not a control; "printer PR-*.contoso.com requires NTLM — exception ticket OPS-4312, revisit 2026-Q2" is.
Setting area
Keep baseline value
Typical override
Why
BitLocker + escrow
Yes
None
Silent encryption + escrow is the single biggest risk reducer
Credential Guard / HVCI
Yes
Vendor driver exceptions
Unsigned kernel drivers block boot of VBS
SMB signing
Yes
Legacy NAS carve-out
Devices that cannot sign lose access
Screen lock / idle timeout
Yes
Executive exceptions (rare)
User revolt risk; solve with education
Attack surface rules
Mostly
Per-app tuning
ASR false positives need staged audit mode
Baseline vs Settings Catalog vs GPO: Who Wins
Three configuration sources can fight over the same Windows setting, and the resolution order is not intuitive:
GPO vs MDM: When a setting is configurable by both and both are present, Group Policy generally wins on Windows clients. A stray "old" GPO can silently defeat your brand-new Intune baseline, and Intune will happily keep reporting success on a setting the OS is not honoring from the MDM side.
Baseline vs settings catalog: Both are MDM profiles. If two profiles set the same setting, the applied value is effectively undefined — Intune reports a conflict per-setting rather than promising a deterministic winner. The only good answer is one source of truth per setting.
Baseline vs security products: Defender for Endpoint's own baseline and your ASR rule profiles can overlap; stage them so each surface area has exactly one owner.
Hunt GPO shadowing first
Run Group Policy analytics in the Intune admin center against an exported copy of your AD GPOs to find overlaps before they find you. Export with the standard Group Policy Management console, let analytics ingest the XML, and it maps which settings are already MDM-supported, which profiles it would generate, and where GPO and Intune both claim the same ground.
Run those on a representative device during the audit phase — the HTML report shows exactly which GPOs are still winning, and it takes ninety seconds.
Field note: Half of "Intune didn't apply my setting" tickets are GPO shadowing. Before you blame the platform, check whether a domain GPO still sets the same value — gpresult settles the argument in one command.
Visual Walkthrough
Every security control on this site maps to one of these five layers.
Layered StackDefense in Depth — Five Aligned Layers6/6
Firewall rules, tunnel, private endpoints segment the path.
layer 4
5
Data
DLP, sensitivity labels, immutable storage protect the crown.
layer 5
6
Assume breach
Each layer assumes the previous one failed — detection everywhere.
posture
Each layer assumes the previous one failed — depth is the strategy.
Defense in Depth — Five Aligned Layers. 1. Identity: Phishing-resistant MFA, PIM, conditional access gate everything. — 2. Endpoint: Compliance, EDR sensors, ASR, WDAC, encryption at the device. — 3. Application: Safe Links, app control, least-privilege app consents. — 4. Network: Firewall rules, tunnel, private endpoints segment the path. — 5. Data: DLP, sensitivity labels, immutable storage protect the crown. — 6. Assume breach: Each layer assumes the previous one failed — detection everywhere.
Drift Detection and Enforcement
MDM is self-healing by design: the device re-evaluates assigned profiles on its regular check-in cycle (about every 8 hours, plus manual sync), and CSP-backed settings are re-enforced. A local admin flipping a registry value gets corrected on the next cycle. But self-healing is not monitoring — you still need to see drift:
Per-setting reports: Intune's device configuration settings report shows, per device, which baseline settings evaluated as success, error, conflict, or not applicable. A baseline instance at 99.4% success with 60 devices in error is your Monday-morning worklist.
Remediations: A proactive remediation script turns any drift check into an alert-and-fix loop. Detection script for a classic hardening setting, SMB signing on the server stack:
PowerShell
1
2
3
4
5
6
7
8
# Detection: is SMB signing enforced on LanmanServer?$p = Get-ItemProperty -Path"HKLM:\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters" -ErrorAction SilentlyContinue
if ($null -ne$p.RequireSecuritySignature -and$p.RequireSecuritySignature -eq1) {
Write-Output "Compliant - SMB signing enforced"
exit 0
}
Write-Output "Drift detected - SMB signing not enforced"
exit 1
Event channel truth: The MDM diagnostics provider logs policy failures with HRESULTs on the device — the fastest way to see why a setting errored rather than merely that it errored:
When Microsoft releases a new baseline version (for example, a refresh aligned with a Windows release), resist the urge to delete-and-recreate. The safe pattern:
Create a new instance from the new baseline version; do not assign it yet.
Use the baseline comparison view to list settings that changed between versions.
Re-apply your documented overrides to the new instance (this is where the description-field discipline pays off).
Assign the new instance to the pilot group; validate.
Swap assignments group-by-group from the old instance to the new one, then retire the old instance.
Never leave two baseline instances of different versions assigned to the same device — that is a guaranteed conflict report and a non-deterministic posture.
Key takeaways
Intune-managed Windows 11 fleets should use the Intune security baseline (24H2 version) as the single source of truth; keep the Security Compliance Toolkit for reference and diffing, not deployment.
Baseline versions are immutable: new Microsoft version means a new instance, a documented diff, re-applied overrides, and a staged assignment swap.
Review BitLocker escrow, Credential Guard/VBS driver compatibility, and SMB signing before pilot — these three cause the majority of baseline rollouts to stall.
Group Policy beats MDM for overlapping settings; run Group Policy analytics and gpresult to hunt GPO shadowing before blaming Intune.
Two Intune profiles setting the same value equals a reported conflict with no guaranteed winner — enforce one setting, one profile, one owner.
Drift detection = per-setting reports + remediation scripts + the MDM diagnostics event channel; self-healing is not the same as visibility.
Document every override with a reason and a review date inside the profile description.
Frequently asked questions
Should I import the downloadable GPO baseline into Intune instead of using the built-in one?
No. The Intune security baseline is curated for MDM deliverability — some SCT GPO settings are not achievable via CSP or are deliberately removed because they conflict with cloud management. Use the built-in baseline for deployment and the SCT for documentation and Policy Analyzer comparisons.
What is the difference between the security baseline and an endpoint security "attack surface reduction" profile?
The baseline is a broad curated set spanning BitLocker, Edge, Defender Antivirus, and local policy. ASR profiles are focused policy objects under Endpoint security > Attack surface reduction. Overlap is real — decide per area which object owns which setting to avoid conflicts.
How fast do changes to a baseline instance reach devices?
Devices evaluate policy at each check-in (roughly every 8 hours) and on manual sync from the Company Portal or remotely triggered sync. Urgent changes can be forced by a remote sync action on selected devices, but plan baseline changes as scheduled waves, not emergencies.
Comments
0No comments yet — be the first to share your thoughts.