Intune hardening baseline
In short: a layered hardening baseline for Windows 11 devices managed by Intune. It combines Microsoft's security baseline, attack surface reduction rules, BitLocker, LAPS and a compliance policy, and feeds device health into Conditional Access.
The problem
Enrolling devices in Intune doesn't make them hardened. Many environments have devices enrolled and reporting as "compliant" against a policy that checks very little, with local admin rights, no attack surface reduction rules and BitLocker keys nobody has escrowed.
[One or two sentences on the specific context, with no customer names.]
Design approach
The baseline is built in layers, so each one can be deployed, tested and rolled back on its own:
| Layer | What it covers |
|---|---|
| Security baseline | Microsoft's Windows security baseline as the starting point, with documented deviations |
| Disk encryption | BitLocker with XTS-AES 256, silent enablement, recovery keys escrowed to Entra ID |
| Local admin | Windows LAPS rotating the built-in admin password, with standard users not local admins |
| Attack surface reduction | ASR rules moved from audit to block, credential theft protections |
| Defender | Tamper protection, cloud-delivered protection, network protection |
| Firewall | Enabled for all profiles, inbound blocked by default |
| Compliance | Minimum OS build, BitLocker, Secure Boot, Defender healthy, machine risk score |
Deviations are documented
Every setting that differs from Microsoft's baseline has a short reason recorded. That turns "why is this set like that?" from guesswork into a lookup, and makes the next baseline update much easier to review.
Attack surface reduction
ASR rules are the part most likely to break something, so they had their own rollout:
- All rules in audit mode for [X weeks].
- Review hits in Defender advanced hunting (
DeviceEventswhereActionTypestarts withAsr). - Add narrow exclusions only where a business app needed them, and record each one.
- Switch to block in rings.
Tying it to Conditional Access
The compliance policy is what gives the baseline weight. A device that falls out of compliance, for example because BitLocker is off or Defender reports high risk, loses access to Microsoft 365 through Conditional Access until it's fixed. See the Conditional Access baseline for that side.
Rollout
- Assignment through device groups in rings: IT, pilot, broad.
- Settings conflicts checked in Intune per-setting status before each ring.
- [Anything that went wrong and how you handled it. Reviewers like this part most.]
Verification
- Intune device configuration and compliance reports show every setting as succeeded.
- On-device checks:
manage-bde -status,Get-MpComputerStatus, and the ASR rule state. - Negative tests: a non-compliant device is blocked from M365, and a test ASR trigger is blocked and logged.
What I'd do next
[e.g. application control with App Control for Business, Endpoint Privilege Management, macOS coverage.]