Microsoft 365 Security Baseline recommends requiring a compliant device for sensitive access — Intune is the tool that defines what "compliant" actually means and enforces it. This article covers Intune's security baseline templates specifically: pre-built, Microsoft-maintained configuration profiles that translate recommended device hardening into deployable policy.
What a security baseline actually is
An Intune security baseline is a pre-configured group of device settings — hundreds of individual options bundled into a single deployable profile — based on Microsoft's own security research and, for the Windows baseline specifically, closely aligned with the Windows security configuration guidance published for enterprise environments. Rather than researching and configuring each setting individually, an administrator starts from the baseline template and adjusts specific settings to fit organizational needs.
| Baseline | Covers |
|---|---|
| Windows security baseline | OS-level hardening — BitLocker, Windows Defender settings, network security, local security policy |
| Microsoft Edge baseline | Browser security settings — SmartScreen, extension controls, download behavior |
| Microsoft 365 Apps baseline | Office application security settings — macro controls, protected view, add-in restrictions |
Baselines are a starting point, not a final configuration
Microsoft updates baseline templates periodically as new versions ship and new threats emerge — treat a deployed baseline as a living configuration to be revisited, not a one-time deployment, mirroring the same "not a one-time push" framing that applies to Secure Score.
Device compliance policy vs. security baseline
These are related but distinct Intune concepts, and conflating them is a common source of confusion:
| Concept | Purpose |
|---|---|
| Compliance policy | Defines pass/fail criteria (encryption enabled, OS version, jailbreak/root detection) that Conditional Access checks before granting access |
| Security baseline | Actively configures device settings to a hardened state — pushes configuration, doesn't just evaluate it |
A device can be "compliant" (passing the defined criteria) without having every security baseline setting applied, and a baseline can be applied without every setting being part of the formal compliance check Conditional Access evaluates. Both matter, and they're configured separately.
Rolling out a baseline without breaking productivity
- Deploy to a pilot group first, exactly like the Report-only discipline recommended for Conditional Access — baselines contain hundreds of settings, and even Microsoft's own recommended defaults can conflict with specific line-of-business software.
- Review baseline drift reports periodically. Devices can drift from an applied baseline over time due to local changes or conflicting policy from another source (a legacy Group Policy Object in a hybrid environment).
- Version and document any deviations from the Microsoft default, so the reasoning behind a specific override survives staff turnover and periodic review.
- Pair baseline deployment with the compliance policy that actually gates Conditional Access access — a baseline that configures device security without an associated compliance policy doesn't directly strengthen access decisions.
Common mistakes
- Deploying a baseline tenant-wide without a pilot phase, risking disruption to line-of-business software with specific configuration dependencies.
- Confusing "baseline applied" with "device compliant" — these are separate mechanisms serving related but distinct purposes.
- Never reviewing baseline drift, leaving devices to silently diverge from the intended hardened configuration over time.
- Setting a device compliance policy without a corresponding Conditional Access requirement actually enforcing it — the compliance evaluation exists, but nothing acts on a non-compliant result.
FAQ
Does using a security baseline require a specific Intune license tier? Intune itself requires licensing (commonly included in Microsoft 365 Business Premium or E3/E5 bundles) — confirm current bundling directly with Microsoft, since it has changed over time.
Can we customize a Microsoft-provided baseline, or must we use it as-is? Baselines are fully customizable — Microsoft's defaults are a starting point, and individual settings can be adjusted to fit organizational requirements, with the adjusted version tracked separately from Microsoft's original template as it's periodically updated.
How does this relate to Conditional Access device compliance requirements? Conditional Access's "require compliant device" grant control (see Conditional Access Best Practices) checks the device compliance policy result specifically — a security baseline supports achieving that compliant state but is a separate configuration layer.