Home Runbooks Why Intune Compliance Policies Aren't Applying — and How to Fix It
Intune / Endpoint FREE

Why Intune Compliance Policies Aren't Applying — and How to Fix It

The policy exists, it's assigned, but the device shows Not Evaluated or the status never updates. Four root causes, none obvious from the portal error messages — here's how to find and fix each one.

⌛ 8 min read· Updated 2026

How Intune Compliance Actually Works

Before diagnosing, understand the flow. When a device checks in with Intune, it evaluates all compliance policies assigned to it and reports a status — Compliant, Not Compliant, Not Evaluated, or In Grace Period. If a policy shows "Not applying", it almost always means one of four things: the policy isn't assigned to the right group, the device hasn't synced recently, the grace period is masking the real status, or the device's enrollment state is broken.

None of these produce an obvious error message in the portal. You have to check each one systematically.

Check the Device Sync Status

The first thing to verify: when did the device last check in? A device that hasn't synced in hours won't reflect recent policy changes.

# In Intune portal:
# Devices -> [device] -> Overview
# Look at "Last check-in" timestamp

# Force a sync from the device (Windows)
# Settings -> Accounts -> Access work or school -> [account] -> Info -> Sync

# Force a sync via PowerShell on the device
Invoke-Command -ScriptBlock {
  Get-ScheduledTask -TaskPath "\Microsoft\Windows\EnterpriseMgmt\*" |
    Start-ScheduledTask
}
TipYou can also trigger a sync from Intune: Devices → [device] → Sync. The device must be online and reachable. Allow 10–15 minutes after sync before checking compliance status again.

Verify Policy Assignment

The most common root cause — the policy is assigned to a group, but the device or user isn't in that group.

# In Intune portal:
# Devices -> Compliance policies -> [policy] -> Device status
# Look for the specific device — if it's not listed, it wasn't targeted

Check the assignment carefully:

  • Is the policy assigned to a device group or a user group? Device compliance policies can be assigned to either, but the behavior differs — device groups target based on the device record, user groups target based on the primary user.
  • Is the device in the assigned group? Check in Azure AD: Groups → [group] → Members.
  • Is there an exclude group that's accidentally capturing the device?
# Check what groups the device belongs to in Azure AD
Connect-MgGraph -Scopes "Device.Read.All","GroupMember.Read.All"
$device = Get-MgDevice -Filter "displayName eq 'WORKSTATION01'"
Get-MgDeviceMemberOf -DeviceId $device.Id | Select DisplayName

Check the Grace Period

Intune compliance policies have a configurable grace period — the window after a device becomes non-compliant before it's actually marked non-compliant and Conditional Access can act on it. During the grace period, the device shows as "In Grace Period" which can look like "not applying".

# In Intune portal:
# Devices -> Compliance policies -> [policy] -> Properties
# Look at "Actions for noncompliance"
# The first action "Mark device noncompliant" has a schedule — default is often 0 days (immediate) but may be set higher

If the grace period is set to 30 days, a device that became non-compliant yesterday shows "In Grace Period" and Conditional Access won't block it yet. This is by design — it's not a bug. Reduce the grace period if you want faster enforcement.

Check the Device Compliance Report

# In Intune portal:
# Devices -> [device] -> Device compliance
# This shows EVERY compliance policy assigned to the device and its per-policy status

Look at each policy in the list. If a policy shows "Not applicable", one of these is true:

  • The OS platform doesn't match (Windows policy assigned to a device showing as iOS)
  • The device isn't enrolled in the right enrollment type (personal vs corporate)
  • The policy has a filter that excludes this device

If a specific setting within a policy shows Not Compliant, expand it — it will show the current device value vs the required value, which tells you exactly what's failing.

Check Device Enrollment State

A device that's Azure AD joined but not MDM enrolled won't have compliance policies applied — it'll show as Not Evaluated.

# On the device — verify MDM enrollment state
dsregcmd /status | findstr /i "MDM AzureAd EnterpriseJoined"

# Expected output for a properly MDM-enrolled device:
# AzureAdJoined     : YES
# MDMUrl            : https://enrollment.manage.microsoft.com/...

# Check MDM enrollment details
Get-Item HKLM:\SOFTWARE\Microsoft\Enrollments\* |
  Get-ItemProperty | Where-Object {$_.ProviderID -eq "MS DM Server"} |
  Select EnrollmentState, UPN

EnrollmentState values: 1 = enrolled, 5 = pending, 6 = failed. If state is 6, the device needs to be re-enrolled.

Common trapA device can be Azure AD joined (shows in Azure AD) without being MDM enrolled (no Intune management). These are separate things. Both are required for compliance policies to apply.

Check the IME Log for Setting Evaluation Errors

When a specific compliance setting is failing to evaluate (rather than failing the check), the IME log has details:

# On the device
Get-Content "C:\ProgramData\Microsoft\IntuneManagementExtension\Logs\IntuneManagementExtension.log" |
  Select-String -Pattern "compliance|error|fail" | Select-Object -Last 50

Also check the DeviceManagement-Enterprise-Diagnostics-Provider log in Event Viewer:

Get-WinEvent -LogName "Microsoft-Windows-DeviceManagement-Enterprise-Diagnostics-Provider/Admin" |
  Where-Object {$_.LevelDisplayName -eq "Error"} |
  Select TimeCreated, Message | Format-List
TipAfter resolving the issue, trigger a sync from Intune and wait 15 minutes. Then check Devices → [device] → Device compliance again. The status should update within one sync cycle.