How to Build Effective Device Compliance Policies in Microsoft Intune

Introduction

Microsoft Intune device compliance policies are at the heart of any modern Zero Trust security strategy. In today’s hybrid workplace, where the traditional network perimeter has largely disappeared, knowing how to build effective device compliance policies in Microsoft Intune is no longer optional — it is a critical skill for every IT and security administrator. These policies determine whether a device is trusted enough to access corporate data, and when integrated with Microsoft Entra Conditional Access, they become the gatekeepers of your entire Microsoft 365 environment.

This guide draws on the latest guidance from Microsoft Learn, real-world audit data from 60+ SMB tenants, and hands-on practitioner knowledge to give you a complete, step-by-step walkthrough — from understanding what compliance policies are, to deploying them effectively across Windows, macOS, iOS, and Android.

1. What Are Device Compliance Policies in Microsoft Intune?

Microsoft Intune compliance policies are sets of rules and conditions used to evaluate whether managed devices meet your organisation’s security and configuration requirements. When a device satisfies all the conditions, Intune marks it as Compliant. When it falls short, it is marked Noncompliant — a status that Conditional Access can then use to block that device from accessing email, SharePoint, Teams, or any other protected corporate resource.

Intune compliance policies are divided into two key areas:

• Compliance Policy Settings — Tenant-wide configurations that act as a built-in baseline policy for every enrolled device, regardless of group membership.

• Device Compliance Policies — Platform-specific sets of rules and settings deployed to groups of users or devices (Windows, macOS, iOS/iPadOS, Android).

⚠️ Critical Insight:  A compliance policy on its own does nothing to a sign-in. It produces a label — Compliant or Noncompliant — and writes that state back to Microsoft Entra ID. The actual enforcement happens in Conditional Access. Without connecting the two, you have done half the job.

2. Why Compliance Policies Are the Foundation of Zero Trust

The Zero Trust security model operates on three core principles: Verify Explicitly, Use Least Privilege Access, and Assume Breach. Intune device compliance policies directly serve the first principle. Every access request must be evaluated against current device health, not just user identity.

The closed-loop model works as follows:

1.     Intune evaluates the device against compliance policies.

2.     The compliance state (Compliant / Noncompliant) is written to Microsoft Entra ID.

3.     Conditional Access reads that state and decides whether to grant or block access.

📊 Data Point:  According to a baseline audit across 60+ SMB Intune tenants, 72% of organisations left the default ‘Mark devices with no compliance policy as Compliant’ setting unchanged — a critical security gap that effectively hands access to every unmanaged device.

3. Tenant-Wide Compliance Policy Settings: The First Configuration Step

Before creating any platform-specific policies, you must configure the tenant-wide compliance settings. Navigate to: Microsoft Intune Admin Center → Endpoint Security → Device Compliance → Compliance Policy Settings.

3.1 Mark Devices With No Policy Assigned

The most important tenant-wide setting is how Intune treats devices that have not been assigned any compliance policy. The default is Compliant, which means unmanaged or unassigned devices are trusted. The correct and recommended setting for any Zero Trust environment is Not Compliant.

✅ Recommendation:  Change ‘Mark devices with no compliance policy assigned’ to ‘Not compliant’. This ensures only devices with an explicit, passing compliance policy can access resources via Conditional Access.

3.2 Compliance Status Validity Period

You can specify a period within which devices must successfully report their compliance status. If a device fails to check in before this period expires, Intune treats it as noncompliant. The default validity period is 30 days. For high-security environments, consider shortening this window.

4. Creating Platform-Specific Compliance Policies

Compliance policies in Intune are platform-specific by design. You must create separate policies for each platform in your fleet: Windows, macOS, iOS/iPadOS, and Android. Attempting to use a single global policy across platforms is a known anti-pattern — 38% of audited tenants make this mistake.

To create a compliance policy, go to: Microsoft Intune Admin Center → Devices → Compliance → Create Policy. Select your platform, then name the policy clearly — for example, ‘Windows – Security Baseline’ or ‘iOS – Corporate Devices’.

4.1 Windows Compliance Settings (Recommended Baseline)

•        BitLocker: Required — ensures full-disk encryption on Windows devices.

•        Minimum OS Version: Set to a supported, patched Windows build (e.g., Windows 11 22H2 or later).

•        Password / PIN: Require a minimum password complexity and length.

•        Firewall: Required to be enabled.

•        Antivirus and Antispyware: Required and must be active and up-to-date.

•       Microsoft Defender for Endpoint Integration: Set a maximum allowed threat level (e.g., Low or Medium) to block devices with active threats.

•        Secure Boot: Required to ensure the device boots to a trusted state.

4.2 macOS Compliance Settings

•        Minimum OS Version: Require a recent, patched macOS release.

•        FileVault: Required for disk encryption (macOS equivalent of BitLocker).

•        System Integrity Protection (SIP): Required — prevents unauthorised code from modifying protected system files.

•        Gatekeeper: Set to Mac App Store and Identified Developers to restrict app installation sources.

•        Password: Require a complex passcode.

ℹ️ Note:  Device compliance evaluation is not supported for userless macOS devices. Ensure all macOS devices have an assigned user before targeting them with compliance policies.

4.3 iOS / iPadOS Compliance Settings

• Minimum OS Version: Require iOS 17 or later (adjust based on your fleet).

•  Jailbreak Detection: Enable — jailbroken devices have a fundamentally compromised security model and should be marked noncompliant immediately, with no grace period.

• Passcode: Required with complexity rules.

• Microsoft Defender for Endpoint or Mobile Threat Defence (MTD): Integrate and set a maximum threat level.

4.4 Android Compliance Settings

•        Minimum OS Version: Set a baseline; be aware that non-Samsung Android vendors may lag 3–6 months on security patches.

•        Security Patch Level: Use 90 days as a practical baseline; flag anything beyond 120 days for hardware review.

•        Rooted Devices: Mark as noncompliant immediately — no grace period. A rooted Android device has a compromised security model.

•        Device Encryption: Required.

•        MTD Integration: Use Microsoft Defender for Endpoint or a supported third-party MTD to catch devices with known vulnerabilities or suspicious apps.

⚡ Field Note:  Android compliance is where most multi-platform Intune projects lose time. Samsung devices receive monthly security patches; other vendors may be 3–6 months behind. Setting a 30-day security patch requirement will make a significant portion of your non-Samsung fleet noncompliant permanently. A 90-day baseline is more operationally sustainable.

5. Actions for Noncompliance: Beyond the Binary Block

Each compliance policy includes a built-in default action: Mark device noncompliant, which triggers immediately at zero days. But actions for noncompliance go far beyond a binary block. They are time-ordered sequences that give you precise control over what happens when a device falls out of compliance — and when.

Available actions include:

•        Mark device noncompliant (immediate — built-in default, cannot be removed)

•        Send email notification to the end user (with a configurable schedule in days)

•        Send push notification via the Company Portal app

•        Remotely lock the device

•        Retire the device (wipe corporate data)

Before deploying a policy with email notifications, you must first create email templates in the Intune admin centre. These templates should include clear, non-alarmist language explaining why the device is noncompliant and providing self-remediation links. For example: ‘Your laptop has not received a security update in 7 days. Please restart your device to complete the update.’

🕐 Grace Periods:  53% of audited tenants have no grace period configured, meaning a transient issue — a paused antivirus update, a temporarily disabled BitLocker — immediately blocks resource access and floods the help desk. A recommended default is 3 days for Windows and macOS, 1 day for iOS and Android. For jailbreak and rooted device detection, use 0 days (immediate).

6. Integrating Compliance Policies With Conditional Access

Compliance policies evaluate device health and produce a state. Conditional Access policies consume that state and enforce it. Together, they form the device trust layer of Zero Trust architecture. Neither works alone.

To wire Intune compliance to Conditional Access:

4.     Create and assign your Intune compliance policies to user groups (preferred for knowledge workers) or device groups (for shared/kiosk devices).

5.     In Microsoft Entra ID, navigate to Security → Conditional Access → New Policy.

6.     Assign the policy to the same user groups targeted by your Intune compliance policies.

7.     Under Cloud Apps, include the apps you want to protect (All Cloud Apps, Exchange Online, SharePoint, Teams).

8.     Under Grant, select ‘Require device to be marked as compliant’.

9.     CRITICAL: First deploy in Report-Only mode. Test with the ‘What If’ tool before enabling enforcement to avoid unintentional lockouts.

🔑 Important:  Always exclude emergency access (break-glass) admin accounts from Conditional Access policies that require device compliance. These accounts are a last resort if your tenant becomes inaccessible, and locking them out can be catastrophic. Coordinate user group assignments between Intune and Conditional Access — mismatched groups are a common cause of gaps in coverage.

7. Handling BYOD: App Protection Policies as the Fallback

For personally owned devices (BYOD) where users prefer not to enrol in full MDM, Intune App Protection Policies (APP) offer a lighter approach. App Protection Policies enforce data protection within managed apps — preventing data leaks, enabling selective wipe, and controlling access to corporate data — without requiring full device enrolment or visibility into personal data.

•        BYOD iOS and Android: Use App Protection Policies combined with app-based Conditional Access.

•        BYOD Windows: Windows BYOD devices must be enrolled in Intune before any compliance policy can apply. There is no app-only equivalent for Windows MDM scenarios.

•        Corporate-Owned Devices: Full device compliance policies apply, with complete disk control and configuration management.

The BYOD model has evolved significantly between 2024 and 2026, with the industry shifting away from full MDM enrolment for personal mobile devices towards App Protection Policies as the primary data protection layer for BYOD iOS and Android scenarios.

8. Microsoft Defender for Endpoint Integration

One of the most powerful enhancements to Intune compliance policies is integrating Microsoft Defender for Endpoint (MDE) as a Mobile Threat Defence (MTD) solution. When integrated, Defender feeds real-time device risk scores back into Intune compliance state, with a near-real-time remediation window.

•        Supported Platforms: Windows, iOS/iPadOS, and Android.

•        Threat Level in Policy: Set a maximum allowed threat level in your compliance policy (e.g., Low). If a device’s Defender risk score exceeds this, it is marked noncompliant.

•        Real-Time Blocking: As of 2024–2026, the integration window has tightened, with Defender risk updates feeding into compliance state within approximately 60 seconds.

•        Existing Customers: Organisations already using Defender for Endpoint can enable this integration without additional licensing in most M365 plans.

For organisations not yet using Defender, any Intune-supported third-party MTD partner can be used instead — but ensure that partner supports all the platforms in your fleet.

9. Monitoring, Reporting, and Ongoing Governance

Deploying compliance policies is not a one-time task. Continuous monitoring and governance are essential to maintaining security posture and reducing help desk noise.

9.1 Compliance Dashboards

In the Intune admin centre, navigate to Devices → Monitor → Device Compliance Status to see a real-time breakdown of your fleet:

•        Compliant — devices that have passed all assigned compliance policies.

•        In Grace Period — devices that are noncompliant but within an admin-configured grace window; these are a priority for soft outreach.

•        Noncompliant — devices requiring immediate escalation.

•        Not Evaluated — potentially stale or newly enrolled devices.

9.2 Reports and Data Export

Intune’s built-in reports cover device configuration profiles, compliance trends, and Windows Update status. For deeper analysis and correlation with security events, export compliance data via the Microsoft Graph API and integrate it with your SIEM or analytics platform.

9.3 Quarterly Reviews

Conduct quarterly reviews of your Intune compliance configurations. Key areas to revisit:

•        OS version minimums — update as vendor support windows change.

•        Security baseline settings — align with the latest Microsoft-published security baselines for Windows and macOS.

•        Conditional Access policy coverage — identify any new apps or workloads that require protection.

•        BYOD policy applicability — review as your organisation’s device fleet evolves.

•        Audit trail review — monitor for unexpected changes to compliance policy settings, which could indicate a compromised admin account weakening your security posture.

10. Common Mistakes to Avoid

Based on analysis across real-world Intune deployments, these are the most prevalent anti-patterns:

•        Leaving ‘Mark devices with no policy as Compliant’ at default — affects 72% of tenants; fix this immediately.

•        Using a single global compliance policy across platforms — compliance policies are platform-specific; separate policies are required.

•        Skipping grace periods — 53% of tenants have no grace period, causing help desk floods from transient noncompliance events.

•        Assigning compliance policies to device groups instead of user groups — 47% of tenants do this, which causes assignment gaps for knowledge workers.

•        Deploying Conditional Access enforcement without testing in Report-Only mode first — always test with What If analysis before enforcing.

•        Not excluding break-glass admin accounts from Conditional Access — a single oversight here can lock administrators out of the entire tenant.

•        Building compliance policies without Conditional Access integration — a compliance label without enforcement is just documentation.

11. Design Principles for Effective Compliance Policies

Before opening the Intune admin centre, start from your risk and access requirements — not from the settings screen. Effective compliance policy design follows a few key principles that keep your environment both secure and operationally sustainable.

•        Start with risk, not settings: Define what you are protecting and who needs access, then work backwards to the compliance requirements that enforce that boundary.

•        Keep policies focused and understandable: Smaller, purpose-built policies make it easier for users to see exactly what failed and for admins to troubleshoot quickly. A monolithic policy that combines 30 settings across different risk tiers creates noise and confusion.

•        Don’t make compliance stricter than your operations can support: Avoid adding compliance rules for settings that need time to stabilise after provisioning or reboot. If your imaging process temporarily disables BitLocker during setup, a zero-day enforcement rule will generate false noncompliance events before the device is even in the user’s hands.

•        Align noncompliance actions with your escalation process: The response to a noncompliant device should be proportional — notify first, escalate if unresolved, block as a last resort for most controls. Reserve immediate blocking (zero-day action) for high-risk signals like jailbreak or rooted device detection.

12. Policy Structure: What to Include in Every Compliance Policy

A solid compliance policy is built around three pillars, where supported by the platform:

•        Device Health — Secure Boot status, health attestation, jailbreak/root detection. These checks validate the integrity of the device before any other settings are evaluated.

•        Device Properties — Minimum and maximum OS version requirements. This ensures devices are running supported, patched software and prevents outdated or overly new builds that haven’t been validated in your environment.

•        System Security — Encryption (BitLocker on Windows, FileVault on macOS), password/PIN complexity, firewall status, antivirus/Defender requirements, and MTD threat level. These are the core security controls that most organisations prioritise.

For platforms such as iOS/iPadOS and Android Enterprise, you can add platform-specific checks including jailbreak and root detection, supported profile types, and security patch levels. The key principle is: only include checks that your operations team can actually respond to. A compliance setting that you cannot remediate within a reasonable time window will become a source of ongoing noise.

📋 Concise Real-World Example:  Windows corporate laptops must have BitLocker enabled, Secure Boot on, a supported OS version, and compliant status before access to Exchange Online and SharePoint is allowed. That single policy combines device posture with access control — which is exactly where compliance policies become operationally meaningful.

13. Recommended Setup Flow

When building a new compliance policy from scratch, this flow keeps the process structured and minimises the risk of misconfigurations:

10.  Navigate to Devices > Compliance in the Microsoft Intune Admin Center and select Create Policy.

11.  Select the platform (Windows, macOS, iOS/iPadOS, Android Enterprise, etc.).

12.  Give it a descriptive name that includes the platform and purpose — e.g., ‘Windows – Corporate Security Baseline’ or ‘iOS – BYOD Minimum’.

13.  Configure the compliance settings that match your security baseline for that platform (encryption, OS version, device health, system security).

14.  Set noncompliance actions: add a user notification on Day 0 or Day 1, configure a grace period for non-critical settings, and schedule escalation actions (lock or retire) for unresolved serious violations.

15.  Assign the policy to the correct device or user groups.

16.  Pair the compliance policy with a Conditional Access policy that requires a compliant device before access to corporate resources is granted. Without this step, the compliance policy has no enforcement power.

17.  Test with a pilot group first, monitor compliance reports for false positives (especially after OS upgrades or hardware refreshes), and then roll out broadly.

14. Platform Strategy: One Size Does Not Fit All

Do not force a universal compliance policy across all device types unless the security requirement is truly identical across platforms. Microsoft Intune supports separate compliance policies for Windows, macOS, iOS/iPadOS, Android Enterprise variants (Fully Managed, Work Profile, Dedicated), Linux, and legacy Windows 8.1/10 scenarios.

Platform strategy matters because capabilities differ significantly:

•        Secure Boot is a meaningful Windows control; it has no direct equivalent on mobile.

•        Jailbreak and root detection are relevant to iOS and Android; not applicable to desktop platforms.

•        FileVault applies to macOS; BitLocker applies to Windows — they are different controls for the same encryption requirement.

•        Security patch levels are a practical Android Enterprise control; Windows handles patching differently through Windows Update compliance.

Tailor your compliance requirements to platform capabilities, and then further refine by department, sensitivity of the application or data being protected, and device ownership model (corporate-owned vs. BYOD). Treating every endpoint identically will result in either an overly permissive policy or an operationally unmanageable one.

15. Building a Strong Compliance Baseline

For most organisations, a practical starting baseline that balances security with operational stability looks like this:

•        Require encryption on all platforms (BitLocker on Windows, FileVault on macOS, device encryption on Android and iOS).

•        Require a supported minimum OS version — not the latest, but one within vendor active support.

•        Require Microsoft Defender for Endpoint or equivalent antivirus/MTD protection where the platform supports it.

•        Block jailbroken and rooted devices immediately, with no grace period.

•        Require a PIN or password with minimum complexity.

•        Use Conditional Access to deny access to corporate resources when compliance is missing.

Once this baseline is in place and stable, refine by department, application sensitivity, and device ownership model — rather than trying to build the perfect policy on day one. A strong baseline deployed broadly is more effective than a perfect policy that never gets past the pilot group.

Conclusion

Building effective Microsoft Intune device compliance policies is a multi-layered discipline that combines tenant configuration, platform-specific rule design, Conditional Access integration, user communication, and ongoing governance. The key takeaways from this guide are:

•        Change your tenant-wide default to ‘Not Compliant’ for unassigned devices.

•        Create separate, platform-appropriate compliance policies for Windows, macOS, iOS, and Android.

•        Always pair Intune compliance with Conditional Access — the policy is the assessment; Conditional Access is the enforcement.

•        Use grace periods to avoid unnecessary help desk load from transient issues.

•        Integrate Microsoft Defender for Endpoint for real-time device risk signals.

•        Test every Conditional Access policy in Report-Only mode before enforcement.

•        Monitor continuously and review policies quarterly.

In the Zero Trust world of 2025–2026, device compliance is not a checkbox — it is the continuous, automated gatekeeping mechanism that decides whether any device — corporate or personal — gets to touch your data. Get the foundations right, wire up Conditional Access, and your Intune environment becomes a robust, adaptive line of defense.

Frequently Asked Questions (FAQs)