The Problem With One-Size-Fits-All Compliance
Most Intune compliance policies I inherit fall into two categories: either they check almost nothing (firewall, encryption, done), or they’ve been copied from a Microsoft security baseline and immediately lock out half the fleet because someone forgot that BitLocker needs a reboot to report compliant.
Neither approach works at scale, especially if you’re an MSP managing clients with wildly different device maturity, risk appetite, and tolerance for support tickets.
The fix is a tiered model. Three compliance policies — Minimal, Standard, Hardened — that you deploy based on where the client actually is, not where you wish they were. Start at Minimal, prove it works, and promote upward as the environment matures.
This is the framework I use. Settings, grace periods, and the gotchas that will generate support tickets if you don’t plan for them.
The Three Tiers
Minimal
Deploy anywhere with near-zero support overhead. Targets settings that are almost impossible to fail on any modern Windows device. Use this for clients with unmanaged fleets, BYOD environments, or where there’s no appetite for compliance-related support calls.
Standard
Reasonable security for Intune-managed devices. Adds OS version requirements, password policies, and Defender validation. Suitable for clients with a managed services agreement and corporate-owned devices.
Hardened
Aggressive security posture for compliance-driven clients. Adds health attestation, Defender for Endpoint risk scoring, and tight OS version controls. Only deploy where the client has a mature device fleet, proactive support, and understands the trade-offs.
The golden rule: start with Minimal and promote upward as the client’s device management maturity increases. Never start at Hardened.
Which Tier for Which Client?
If a client spans multiple tiers on the criteria below, default to the lower tier and promote later. Getting locked out of email because a laptop missed a Windows update is not a proportionate consequence.
| Criteria | Minimal | Standard | Hardened |
|---|---|---|---|
| Device management | BYOD / unmanaged or lightly managed | Intune-enrolled, corporate-owned or BYOD with MAM | Fully managed, corporate-owned, Autopilot-deployed |
| Support agreement | Break/fix or limited hours | Managed services with reactive support | Proactive managed services with dedicated hours |
| Industry | General SMB, retail, hospitality | Professional services, education, general corporate | Finance, healthcare, legal, government |
| Risk appetite | High (security-light) | Moderate | Low (security-first) |
| User base | Non-technical, high friction sensitivity | Mixed technical ability | Technical or compliance-aware users |
| Existing fleet state | Unknown, inconsistent, or legacy hardware | Mostly modern, some older devices | Standardised modern hardware |
Compliance Policy Settings
Every setting below references the Intune compliance policy categories: Device Health, Device Properties, System Security, and Defender.
Device Health
These settings use Windows Health Attestation and are evaluated at boot time. A reboot may be required after remediation before the device reports as compliant.
| Setting | Minimal | Standard | Hardened | Notes |
|---|---|---|---|---|
| Require BitLocker | Not configured | Require | Require | Needs reboot to detect. TPM required. |
| Require Secure Boot | Not configured | Not configured | Require | Some TPM 1.2 devices will fail. |
| Require Code Integrity | Not configured | Not configured | Require | Blocks unsigned kernel drivers. |
Device Properties (OS Version)
OS version enforcement is one of the highest-risk compliance settings. Devices that fall behind on updates will be blocked. Use grace periods generously.
| Setting | Minimal | Standard | Hardened | Notes |
|---|---|---|---|---|
| Minimum OS version | Not configured | 10.0.19045.0 (Win10 22H2) | 10.0.22631.0 (Win11 23H2) | Adjust per fleet. Use ver command to check. |
| Maximum OS version | Not configured | Not configured | Not configured | Rarely needed. Only for testing rings. |
| Valid OS builds | Not configured | Not configured | Configure per patch cycle | For orgs with strict patching windows. |
Note on OS version baselines: The build numbers above are examples. Windows 11 23H2 Home and Pro editions have already reached end of updates, and 24H2 and 25H2 are now available. Always target a currently supported version for your edition (Enterprise, Education, etc.) and review the Windows release health dashboard before setting your minimum.
If you enforce a minimum OS version, make sure Windows Update for Business (WUfB) or WSUS is configured to deliver updates before the grace period expires. Otherwise you’re creating a compliance gap that users cannot self-remediate.
System Security — Password
Password compliance checks whether a password/PIN exists and meets complexity requirements. These settings apply to the device lock screen, not Entra ID passwords.
| Setting | Minimal | Standard | Hardened | Notes |
|---|---|---|---|---|
| Require a password | Require | Require | Require | Baseline for all tiers. |
| Simple passwords | Block | Block | Block | Blocks 1234, 1111 etc. |
| Password type | Device default | Alphanumeric | Alphanumeric | Device default = PIN or password. |
| Password complexity | Not configured | Digits + lowercase | Digits + lower + upper + special | Only applies when Alphanumeric. |
| Minimum password length | Not configured | 8 | 12 | |
| Max inactivity (mins) | Not configured | 15 | 5 | Lock screen timeout. |
| Password expiration | Not configured | Not configured | Not configured | NIST no longer recommends expiry. |
| Previous passwords | Not configured | Not configured | 5 | Prevent reuse. |
System Security — Encryption
| Setting | Minimal | Standard | Hardened | Notes |
|---|---|---|---|---|
| Encryption of data storage | Require | Require | Require | Generic check. BitLocker in Device Health is more robust. |
System Security — Device Security
| Setting | Minimal | Standard | Hardened | Notes |
|---|---|---|---|---|
| Firewall | Require | Require | Require | Check for GPO conflicts. See notes below. |
| TPM | Not configured | Require | Require | Checks TPM version > 0. Nearly all modern PCs have TPM. |
| Antivirus | Not configured | Require | Require | Checks Windows Security Centre registration. |
| Antispyware | Not configured | Require | Require | Usually same as AV on modern Windows. |
Firewall compliance will report Not Compliant if a Group Policy is overriding the Windows Firewall settings (e.g. allowing all inbound traffic). If migrating from GPO-managed firewalls, resolve GPO conflicts before enabling this setting.
Microsoft Defender
These settings specifically target Defender Antimalware. If the client uses a third-party AV (e.g. Sophos, CrowdStrike), these settings may report non-compliant because Defender will be in passive mode. Adjust accordingly.
| Setting | Minimal | Standard | Hardened | Notes |
|---|---|---|---|---|
| Defender Antimalware | Not configured | Require | Require | Only if Defender is primary AV. |
| Defender minimum version | Not configured | Not configured | Not configured | Rarely needed. Auto-updates handle this. |
| Security intelligence up-to-date | Not configured | Not configured | Require | High drift risk. See common issues below. |
| Real-time protection | Not configured | Require | Require | Only if Defender is primary AV. |
Microsoft Defender for Endpoint
Requires Defender for Endpoint (Plan 2 or Business) to be onboarded and integrated with Intune. Without the integration, this setting cannot be evaluated.
| Setting | Minimal | Standard | Hardened | Notes |
|---|---|---|---|---|
| Device risk score | Not configured | Not configured | Medium or lower | Requires MDE integration. Powerful but complex. |
Grace Periods and Non-Compliance Actions
Grace periods are your single biggest lever for reducing support overhead. They give users and devices time to self-remediate before access is blocked. Configure these in the compliance policy under “Actions for noncompliance”.
| Action | Minimal | Standard | Hardened |
|---|---|---|---|
| Mark noncompliant | 7 days | 3 days | 1 day |
| Send email to user | 7 days | 3 days | 1 day |
| Send push notification | Not configured | 5 days | 2 days |
| Block access (via CA) | 14 days | 7 days | 3 days |
Key principle: the grace period should always be longer than your remediation capability. If it takes 5 days to roll a patch out, don’t set a 3-day grace period.
Tenant-Wide Compliance Settings
Before deploying any compliance policy, configure the tenant-wide settings at Endpoint Security > Device Compliance > Compliance policy settings.
- Devices with no compliance policy assigned: Set to “Not compliant”. This ensures unmanaged devices cannot pass a CA check by simply having no policy. This is easy to miss and it matters.
- Compliance status validity period: 30 days (default). Reduce to 14 days for Hardened tier if required. Devices that don’t check in within this period become non-compliant.
- Enhanced jailbreak detection: Not applicable to Windows (iOS only).
Pairing with Conditional Access
A compliance policy alone doesn’t block access. You need a Conditional Access policy with the grant control “Require device to be marked as compliant” to enforce it.
Recommendations:
- Deploy the compliance policy first. Let it run for at least 7 days before enabling the CA policy.
- Use the CA Enablement Checklist to validate before switching from report-only to enabled.
- Check the Intune compliance report (Devices > Compliance > Device compliance) for the current state of the fleet before enabling the CA gate.
- For Minimal tier: consider pairing with a CA policy that requires compliance OR MFA (using OR logic). This allows non-compliant devices to still access resources if they complete MFA, reducing lockout risk.
- For Standard/Hardened: pair with a CA policy that requires compliance AND MFA for maximum security.
Never skip straight to CA enforcement. Always run: compliance policy > observe > CA report-only > observe > CA enforce. This four-stage approach catches issues before users are affected.
Common Causes of Compliance Drift
These are the most frequent reasons devices fall out of compliance. Understanding them will help you anticipate support tickets and set appropriate grace periods.
BitLocker
- BitLocker compliance is evaluated at boot time only. A device that just had BitLocker enabled will remain non-compliant until it reboots.
- Some devices without TPM 2.0 cannot enable BitLocker silently. Check hardware compatibility before enforcing.
Defender Definitions
- This is the highest-drift setting. Definitions can go out of date if a device is offline for 24-48 hours (weekends, leave, travel).
- If using this setting, set a generous grace period (3-7 days) or accept the support overhead.
- Verify Windows Update and Defender update channels are working before enabling.
OS Version
- Feature updates can take days to install. Users defer them.
- WUfB deferral policies may delay updates beyond the compliance grace period if misconfigured.
- Always set the minimum OS version to at least one version behind the current release to allow rollout time.
Firewall
- Group Policy objects (GPOs) that override firewall settings will cause compliance failures even if the Intune policy enables the firewall.
- Third-party firewalls (e.g. Norton, ESET) may disable Windows Firewall, triggering non-compliance.
- Resolve GPO conflicts and third-party AV/firewall interactions before enforcing this setting.
Intune Sync
- A device that hasn’t checked in within the compliance validity period (default 30 days) will be marked non-compliant regardless of its actual state.
- Devices that are powered off, offline, or on long-term leave will drift. Consider excluding these from CA policies or extending the validity period.
Recommended Implementation Order
Follow this sequence when rolling out device compliance for a new client:
Week 1: Deploy the Minimal compliance policy with no CA enforcement. Let it report on the fleet for at least 7 days.
Week 2: Review the compliance report. Identify any devices that fail even the Minimal baseline. Remediate or exclude.
Week 3: Enable the CA policy in report-only mode requiring device compliance. Run for 7 days. Use the CA Enablement Checklist.
Week 4: Enable the CA policy. Monitor for 48 hours.
Week 5+: If stable, consider promoting to the Standard tier. Repeat the same 4-week cycle.
Never skip straight to CA enforcement. Always run: compliance policy > observe > CA report-only > observe > CA enforce. This four-stage approach catches issues before users are affected.
References
- Windows compliance settings in Microsoft Intune — Microsoft Learn
- Device compliance policies in Microsoft Intune — Microsoft Learn
- Plan a Conditional Access deployment — Microsoft Learn