Microsoft Intune Device Compliance Policies: A 2026 Configuration Guide

Executive Snapshot

TL;DR

flowchart TD
    A[Device enrolled in Intune] --> B[Compliance policy evaluated]
    B --> C{Meets all rules?}
    C -->|Yes| D[Marked Compliant]
    C -->|No| E[Marked Non-Compliant]
    E --> F[Grace period / remediation]
    F --> B
    D --> G[Entra ID device state updated]
    E --> G
    G --> H{Conditional Access check}
    H -->|Compliant| I[Grant access to resource]
    H -->|Non-compliant| J[Block / limited access]
    classDef ok fill:#1f6f43,stroke:#3ddc84,color:#fff
    classDef bad fill:#7a1f2b,stroke:#ff5a6e,color:#fff
    class D,I ok
    class E,J bad

• Intune device compliance policies define the health rules — Conditional Access policies are the enforcers; you need both working together.
• Platform-specific policies are non-negotiable — a single "catch-all" policy misses platform settings and creates dangerous gaps.
• Mark devices without a compliance policy as "Not Compliant" in tenant settings — the single most-overlooked security control in Intune.
• Grace periods exist to help users, not bypass security — keep them at 24 hours maximum for corporate devices.
• Defender for Endpoint integration lets compliance policies consume real-time threat signal, making them dynamic rather than static.

Introduction

Every device touching your corporate environment is a potential attack vector. Stolen credentials let attackers in through the front door, but an unpatched, unencrypted, or jailbroken endpoint lets them walk in through a window you didn't know was open.

Microsoft Intune device compliance policies are the mechanism that defines what a "healthy" device looks like — minimum OS version, disk encryption, PIN complexity, firewall state, and threat level — and continuously monitors enrolled devices against those rules. Paired with Entra ID Conditional Access, a non-compliant device gets denied access to Microsoft 365, Azure resources, and any connected SaaS application automatically, without a helpdesk ticket or manual intervention.

The problem is that most organisations configure compliance policies once during an Intune rollout and never revisit them. Requirements change, threat landscapes evolve, and new Intune capabilities ship quarterly. This 2026 guide walks through building, deploying, and maintaining compliance policies that reflect the current threat environment — covering Windows, macOS, iOS, and Android from a single Intune tenant.

Prerequisites

Before following this guide, confirm you have the following in place:

• Microsoft Intune Plan 1 licence (or Microsoft 365 Business Premium / E3/E5)
• Entra ID P1 or P2 (required for Conditional Access policy enforcement)
• Intune Administrator or Global Administrator role in your tenant
• Devices already enrolled via Autopilot, ADE/DEP, Android Enterprise, or BYOD enrolment
• Microsoft Defender for Endpoint Plan 1 or 2 (optional but strongly recommended for threat-level compliance)
• Familiarity with the Intune admin centre (intune.microsoft.com) and Entra ID portal (entra.microsoft.com)
• PowerShell 7.x with the Microsoft.Graph module installed (for scripted deployment)

How Intune Device Compliance Policies Actually Work

Before writing a single policy, it is worth cementing the conceptual model. Many administrators conflate compliance policies with configuration profiles — they are fundamentally different things.

flowchart TD
    A[Device Enrolls in Intune] --> B[Configuration Profile Applied\ne.g. BitLocker, Wi-Fi, VPN]
    A --> C[Compliance Policy Evaluated]
    C --> D{All Rules Met?}
    D -- Yes --> E[Device Marked Compliant]
    D -- No --> F[Device Marked Non-Compliant]
    E --> G[Entra ID Compliance Token Issued]
    F --> H[Non-Compliance Actions Triggered\ne.g. Email, Notify, Block]
    G --> I[Conditional Access Grants Access\nto M365 / Azure / SaaS]
    H --> J[Conditional Access Denies Access\nRequire Compliant Device]
    I --> K[User Works Normally]
    J --> L[User Sees Block Page\nWith Remediation Steps]

Key insight: Intune evaluates compliance on a schedule (every 8 hours by default, or on-demand). Conditional Access checks the compliance token at the moment of authentication. This means a device that falls out of compliance mid-session will be blocked on the next token refresh — typically within 1 hour for modern authentication flows.

Step 1 — Configure Tenant-Wide Compliance Settings First

This is the most commonly skipped step and the one that creates the largest security gap.

Navigate to: Intune Admin Centre → Devices → Compliance → Compliance settings

Set Mark devices with no compliance policy assigned to Not compliant.

The default is Compliant. Left at default, every unmanaged or newly enrolled device that hasn't received a policy yet is treated as trusted — exactly the opposite of a Zero Trust posture.

Also configure:

• Enhanced jailbreak detection — Enabled (iOS/iPadOS)
• Compliance status validity period — 30 days maximum (devices that haven't checked in are marked non-compliant)

Step 2 — Build the Windows 11 Compliance Policy

Navigate to: Devices → Compliance → Create policy → Windows 10 and later

Recommended Settings (Windows 11, 2026 Baseline)

Deploy via Microsoft Graph PowerShell

Rather than clicking through the UI for every policy, use the Graph API for repeatable, version-controlled deployments:

# Requires: Install-Module Microsoft.Graph -Scope CurrentUser
# Connect with required scopes
Connect-MgGraph -Scopes "DeviceManagementConfiguration.ReadWrite.All", "Group.Read.All"

$compliancePolicyBody = @{
    "@odata.type" = "#microsoft.graph.windows10CompliancePolicy"
    displayName   = "WIN-Compliance-Baseline-2026"
    description   = "Windows 11 compliance baseline — June 2026"
    osMinimumVersion        = "10.0.22631.3880"
    bitLockerEnabled        = $true
    secureBootEnabled       = $true
    codeIntegrityEnabled    = $true
    storageRequireEncryption = $true
    activeFirewallRequired  = $true
    defenderEnabled         = $true
    defenderVersion         = ""
    signatureOutOfDate      = $false
    rtpEnabled              = $true
    antivirusRequired       = $true
    antiSpywareRequired     = $true
    deviceThreatProtectionEnabled           = $true
    deviceThreatProtectionRequiredSecurityLevel = "medium"
    passwordRequired        = $true
    passwordMinimumLength   = 8
    passwordRequiredType    = "deviceDefault"
    passwordMinutesOfInactivityBeforeLock   = 5
} | ConvertTo-Json -Depth 10

$policy = Invoke-MgGraphRequest `
    -Method POST `
    -Uri "https://graph.microsoft.com/v1.0/deviceManagement/deviceCompliancePolicies" `
    -Body $compliancePolicyBody `
    -ContentType "application/json"

Write-Host "Created policy: $($policy.id)" -ForegroundColor Green

Step 3 — Build the macOS Compliance Policy

Navigate to: Devices → Compliance → Create policy → macOS

# macOS Compliance Policy via Graph
$macosPolicyBody = @{
    "@odata.type"              = "#microsoft.graph.macOSCompliancePolicy"
    displayName                = "MAC-Compliance-Baseline-2026"
    description                = "macOS 14 Sonoma compliance baseline — June 2026"
    osMinimumVersion           = "14.5"
    systemIntegrityProtectionEnabled = $true
    deviceThreatProtectionEnabled    = $true
    deviceThreatProtectionRequiredSecurityLevel = "medium"
    storageRequireEncryption   = $true   # FileVault
    firewallEnabled            = $true
    firewallBlockAllIncoming   = $false
    gatekeeperAllowedAppSource = "macAppStoreAndIdentifiedDevelopers"
    passwordRequired           = $true
    passwordMinimumLength      = 8
    passwordMinutesOfInactivityBeforeLock = 5
    passwordExpirationDays     = 365
    passwordPreviousPasswordBlockCount = 5
} | ConvertTo-Json -Depth 10

Invoke-MgGraphRequest `
    -Method POST `
    -Uri "https://graph.microsoft.com/v1.0/deviceManagement/deviceCompliancePolicies" `
    -Body $macosPolicyBody `
    -ContentType "application/json"

Step 4 — Build iOS and Android Compliance Policies

iOS / iPadOS Key Settings

Android Enterprise (Corporate-Owned / Work Profile)

Step 5 — Configure Non-Compliance Actions

Non-compliance actions are the response playbook when a device fails evaluation. Navigate to the Actions for noncompliance tab within each policy.

Recommended action sequence for corporate devices:

Note on the 3-day grace period: For BYOD scenarios this is reasonable. For corporate-owned devices, consider reducing the block trigger to 1 day. High-security environments (finance, healthcare) should set it to 0 — block immediately.

Step 6 — Assign Policies to Entra ID Groups

Never assign compliance policies directly to individual devices. Use dynamic Entra ID groups based on device attributes for automatic scoping.

Create a Dynamic Device Group via Graph (PowerShell)

# Create a dynamic group for all Windows 11 corporate devices
$groupBody = @{
    displayName     = "DYN-Devices-Windows11-Corporate"
    description     = "Dynamic group — all corporate Windows 11 Intune-enrolled devices"
    groupTypes      = @("DynamicMembership")
    mailEnabled     = $false
    mailNickname    = "dyn-devices-win11-corp"
    securityEnabled = $true
    membershipRule  = '(device.deviceOSType -eq "Windows") and (device.deviceOSVersion -startsWith "10.0.2") and (device.managementType -eq "MDM")'
    membershipRuleProcessingState = "On"
} | ConvertTo-Json -Depth 5

$group = Invoke-MgGraphRequest `
    -Method POST `
    -Uri "https://graph.microsoft.com/v1.0/groups" `
    -Body $groupBody `
    -ContentType "application/json"

Write-Host "Group created: $($group.id)"

# Now assign the compliance policy to this group
$assignmentBody = @{
    assignments = @(
        @{
            target = @{
                "@odata.type" = "#microsoft.graph.groupAssignmentTarget"
                groupId       = $group.id
            }
        }
    )
} | ConvertTo-Json -Depth 5

Invoke-MgGraphRequest `
    -Method POST `
    -Uri "https://graph.microsoft.com/v1.0/deviceManagement/deviceCompliancePolicies/$($policy.id)/assign" `
    -Body $assignmentBody `
    -ContentType "application/json"

Write-Host "Policy assigned to group." -ForegroundColor Green

Step 7 — Wire Up Conditional Access

Compliance policies mean nothing without enforcement. Create a Conditional Access policy that requires device compliance.

Navigate to: Entra ID → Protection → Conditional Access → New policy

Always start in Report-only mode. Use the Conditional Access Insights workbook in Entra to identify which users and devices would be blocked before flipping to enforcement.

Integrating Microsoft Defender for Endpoint

When MDE is connected to Intune, compliance policies can consume the device's real-time risk score — making your compliance posture dynamic rather than a static checklist evaluated every 8 hours.

flowchart LR
    A[Endpoint Activity\ne.g. suspicious process, vuln exploit] --> B[Microsoft Defender for Endpoint\nThreat Analytics Engine]
    B --> C{Machine Risk Score}
    C -- Clear --> D[Intune: Compliant]
    C -- Low --> D
    C -- Medium --> E{Policy Threshold}
    E -- Threshold = Medium --> D
    E -- Threshold = Low --> F[Intune: Non-Compliant]
    C -- High --> F
    C -- Critical --> F
    F --> G[Conditional Access Block\nTriggered within 60 min]
    D --> H[Access Maintained]

To enable this integration:

1. Intune Admin Centre → Endpoint Security → Microsoft Defender for Endpoint
2. Toggle Connect Windows devices to Microsoft Defender for Endpoint to On
3. Set MDM Compliance Policy Evaluation to Require
4. In each compliance policy, enable Require the device to be at or under the machine risk score and select Medium

Once connected, a device that triggers a High or Critical alert in Defender is automatically marked non-compliant in Intune within approximately 60 minutes — no manual intervention required.

Pitfalls to Avoid

1. Leaving "No compliance policy = Compliant" at default
This is the single most dangerous misconfiguration. Change it to Not Compliant immediately in tenant settings.

2. Using one policy for all platforms
Windows, macOS, iOS, and Android each have distinct settings that don't overlap. A single "all platforms" policy gives you the lowest common denominator — which is almost nothing.

3. Setting grace periods too long
A 7-day grace period means a compromised, unencrypted device has 7 days of access to your corporate data. For corporate devices, 24 hours is the maximum acceptable grace.

4. Forgetting exclusion groups for break-glass accounts
Always exclude your emergency access accounts from Conditional Access policies that require device compliance. A break-glass account locked out because its device isn't enrolled defeats its entire purpose.

5. Not testing in Report-only mode
Skipping the Report-only validation phase for Conditional Access is how you accidentally lock out the entire executive team on a Monday morning.

6. Ignoring stale devices
Devices that haven't checked in for 30+ days should be flagged. Use the compliance validity period setting to auto-mark them non-compliant, then run a monthly Intune report to retire genuinely abandoned devices.

7. Treating compliance as a one-time task
New OS versions ship every year. Minimum OS version settings that were current in 2024 are security liabilities in 2026. Schedule a quarterly policy review on your calendar.

Troubleshooting

Device Shows "Not Compliant" After Meeting All Requirements

Symptom: Device appears fully configured but remains non-compliant.

Causes and fixes:

# On Windows — force an Intune sync to re-evaluate compliance immediately
# Run in an elevated PowerShell session on the device:
Start-Process "ms-device-enrollment://sync"

# Or via scheduled task trigger:
Get-ScheduledTask -TaskName "Schedule #3 created by enrollment client" | Start-ScheduledTask

• Stale compliance evaluation: Trigger a manual sync from Company Portal or via the above command.
• MDE not reporting: Check that the device appears in the Defender portal under Devices. If absent, re-run the MDE onboarding package.
• Policy not yet assigned: Confirm dynamic group membership has propagated. Dynamic groups can take up to 24 hours to populate after enrollment.

User Blocked by Conditional Access Despite Compliant Device

Symptom: User receives "You can't get there from here" error even though Intune shows the device as compliant.

Diagnosis steps:

# Pull the Entra ID sign-in logs for the affected user to identify which CA policy blocked them
Connect-MgGraph -Scopes "AuditLog.Read.All", "Policy.Read.All"

$userId = "user@contoso.com"
$signInLogs = Invoke-MgGraphRequest `
    -Method GET `
    -Uri "https://graph.microsoft.com/v1.0/auditLogs/signIns?`$filter=userPrincipalName eq '$userId' and status/errorCode ne 0&`$top=10&`$orderby=createdDateTime desc"

$signInLogs.value | Select-Object createdDateTime, appDisplayName, `
    @{N="ResultCode";E={$_.status.errorCode}}, `
    @{N="FailureReason";E={$_.status.failureReason}}, `
    @{N="CAResult";E={$_.appliedConditionalAccessPolicies | ConvertTo-Json -Compress}} | 
    Format-List

• Compliance token not yet refreshed: The Entra ID token caches compliance state. Have the user sign out of all apps and sign back in, or wait up to 1 hour for token refresh.
• Device registered under a different UPN: The compliant device in Intune belongs to a different Entra ID object than the signing-in user.
• CA policy targets "All cloud apps" including the Intune service itself: Add the Intune Enrolment app as an exclusion in the CA policy to avoid enrolment chicken-and-egg scenarios.

BitLocker Compliance Failing Despite Encryption Being Active

Symptom: Windows device shows BitLocker enabled in manage-bde -status but compliance policy reports it as non-compliant.

# Check BitLocker status on the device
manage-bde -status C:

# Verify the protection status specifically — compliance checks "Protection On" not just "Encrypted"
# Output should show: Protection Status: Protection On
# If it shows "Protection Off" (common after a BIOS update or TPM change), re-enable:
manage-bde -protectors -enable C:

BitLocker must show Protection Status: Protection On. A drive that is encrypted but has protection suspended (common after firmware updates) will fail the compliance check. Re-enabling protectors resolves this in the next compliance cycle.

Key Takeaways

• Compliance policies define the rules; Conditional Access enforces them — deploying one without the other provides no real protection.
• The single most impactful setting is changing "No policy assigned = Compliant" to Not Compliant in tenant settings — do this before anything else.
• Build per-platform policies for Windows, macOS, iOS, and Android — platform-specific settings cannot be captured in a generic policy.
• Microsoft Defender for Endpoint integration transforms compliance from a static 8-hour check into a near-real-time dynamic security signal.
• Grace periods and non-compliance action sequencing matter as much as the policy settings themselves — model them to your organisational risk tolerance.
• Use dynamic Entra ID groups and Graph API scripting to keep deployments consistent, auditable, and repeatable across tenants or policy refresh cycles.
• Quarterly policy reviews are not optional — OS minimum versions, MDE integration settings, and Intune platform capabilities change frequently enough to make set-and-forget a liability.

Next Steps

1. Enable Endpoint Analytics in Intune to correlate compliance data with device health and startup performance trends.
2. Configure Compliance Reporting in Microsoft Sentinel — pipe Intune compliance events into your SIEM via the Intune Diagnostics → Event Hubs integration for long-term audit trails.
3. Extend to non-Microsoft platforms — review the Intune partner compliance integration for Jamf Pro (macOS) and Workspace ONE (Android/iOS) if you run a mixed MDM environment.
4. Build a Compliance Drift Dashboard using the Microsoft Graph API and Power BI to give security leadership a real-time view of fleet compliance posture.
5. Run a tabletop exercise simulating a compromised endpoint — trace the detection path from MDE alert → Intune non-compliance → CA block → user notification → remediation to validate your end-to-end response time.

Related Articles

• [Placeholder] Microsoft Intune Endpoint Security Policies vs. Compliance Policies: When to Use Each — /microsoft-365/intune-endpoint-security-vs-compliance-policies/
• [Placeholder] Entra ID Conditional Access: Building a Zero Trust Policy Stack for Microsoft 365 — /microsoft-365/entra-id-conditional-access-zero-trust/
• [Placeholder] Microsoft Defender for Endpoint and Intune Integration: Complete Setup Guide — /security/defender-for-endpoint-intune-integration-guide/