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.
Security baseline vs. configuration profile
The other pairing administrators routinely conflate is the security baseline and the ordinary device configuration profile. Mechanically they are close relatives — both push settings to enrolled devices, and both can be assigned to the same groups — but they differ in origin and in who maintains them.
| Concept | Where the settings come from | Who maintains it |
|---|---|---|
| Security baseline | A Microsoft-authored template of pre-selected, security-focused settings, versioned by Microsoft | Microsoft publishes new template versions; the organization chooses when to move to them and records any deviations |
| Configuration profile | Settings the organization selects itself, security-related or not — Wi-Fi and VPN, certificates, kiosk mode, update rings, branding | The organization authors and maintains it end to end |
The practical consequence is conflict. Because both write device configuration, a baseline and a configuration profile targeting the same setting with different values produce a policy conflict, and the affected setting typically applies to neither value — it lands in a conflict state and is reported as such rather than silently resolving in favour of one. Assigning both to overlapping groups without checking for overlapping settings is a common way to end up with devices that are neither hardened nor configured as intended.
A workable division: use the baseline for the security hardening Microsoft already researched, and configuration profiles for the organization-specific settings a baseline was never meant to carry — keeping the two sets of settings as disjoint as the environment allows, and treating any deliberate overlap as a documented deviation.
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.
What is the difference between an Intune security baseline and a configuration profile? A security baseline is a Microsoft-authored, versioned template of security settings; a configuration profile is a set of settings the organization selects itself, security-related or otherwise. Both push configuration to enrolled devices, which is why targeting the same setting from both produces a policy conflict rather than a predictable winner — see Security baseline vs. configuration profile above.
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.