Microsoft Intune Compliance Policy Troubleshooting: Why Devices Show Non-Compliant and How to Fix the 6 Most Common Policy Failures

The summary compliance status (Compliant / Not Compliant / In Grace Period) does not show which setting failed. To find the specific failing setting:

1. Navigate to: Intune admin center > Devices > All devices
2. Select the affected device by name
3. Go to Device compliance (in the left nav under Monitor)
4. Select the specific compliance policy assigned to the device
5. The per-setting detail shows each evaluated setting with its result: Compliant, Not Compliant, Not Evaluated, or Error

The 'Not Evaluated' state is important to understand: it means Intune could not evaluate the setting, not that it passed. Common causes of Not Evaluated:

• The setting requires a management extension that is not installed or not syncing
• The setting requires a hardware capability the device does not have (TPM required for certain health attestation checks)
• The setting is scoped to a device platform the target device does not match

For each setting showing Not Compliant or Error, the detail view shows the current value versus the required value. This is the most direct path to root cause.

BitLocker encryption compliance is the leading cause of Windows device non-compliance. The compliance setting checks whether BitLocker is enabled on the OS drive (C:). Three failure patterns:

Pattern 1: BitLocker enabled but Intune does not detect it The device has BitLocker enabled but the compliance check shows Not Compliant. This typically occurs when the BitLocker recovery key has not been escrowed to Entra ID. The Intune compliance policy specifically requires that the key is escrowed and that the protection is confirmed active.

Verify BitLocker state and key escrow:

# Check BitLocker protection status
manage-bde -status C:

# Check if key is backed up to Azure AD
(New-Object -ComObject Shell.Application).Windows() | ForEach-Object {
    $_ | Where-Object {$_.Name -eq "BitLocker Drive Encryption"}
}

# Force BitLocker key escrow to Entra ID
Get-BitLockerVolume -MountPoint C: | Select-Object -ExpandProperty KeyProtector |
Where-Object { $_.KeyProtectorType -eq "RecoveryPassword" } | ForEach-Object {
    BackupToAAD-BitLockerKeyProtector -MountPoint C: -KeyProtectorId $_.KeyProtectorId
}

Pattern 2: BitLocker suspended during Windows Update BitLocker protection suspends automatically during some Windows feature updates. After the update completes, protection should resume, but occasionally remains suspended. Check: manage-bde -status C: and look for Protection Status: Protection Off. Resume with: manage-bde -resume C:

Pattern 3: Device is in FIPS mode Devices with FIPS compliance mode enabled require a specific BitLocker configuration. Standard BitLocker implementations may not satisfy the FIPS compliance requirement even if encryption is active.

Compliance policies can require a minimum OS build version. Devices that have not installed recent Windows Updates will fail this check.

Diagnosing the version mismatch: In the per-setting detail, the OS version setting shows the required minimum version and the device's current version. Cross-reference the device's reported version against the Windows Update history:

# Get current OS build
[System.Environment]::OSVersion.Version

# Check Windows Update history for the last 10 updates
Get-HotFix | Sort-Object InstalledOn -Descending | Select-Object -First 10

# Check Windows Update for pending updates
(New-Object -ComObject Microsoft.Update.Session).CreateUpdateSearcher().Search("IsInstalled=0").Updates |
Select-Object Title, @{N='KB';E={$_.KBArticleIDs}}

Common causes of update non-compliance:

• Windows Update blocked by GPO (WSUS configured but not delivering the required updates)
• Update stuck in pending restart state
• Update incompatible with a driver or application that triggered a rollback
• Device offline during the update window and has not checked in since

Forcing Intune to re-evaluate after update: After the update installs and the device restarts, Intune compliance does not immediately re-evaluate. Force a sync from the device:

• Settings > Accounts > Access work or school > [account] > Info > Sync

Or via the Intune admin center: Devices > [device] > Sync

Allow 15-30 minutes after sync for the compliance state to update in the portal.

Intune uses the Windows Security Center API to evaluate antivirus, antispyware, and firewall state. Third-party security products that register with Windows Security Center will satisfy these compliance checks if they are active and up to date. Failures occur when:

Third-party AV not registered with Windows Security Center: Some enterprise AV products do not register with Windows Security Center in certain configurations. Check in Windows Security > Open Windows Security > Virus and threat protection -- if it shows the third-party product, it is registered. If it shows Windows Defender (when a third-party AV is deployed), the third-party product is not registered.

Firewall profile evaluation scope: The Intune compliance setting checks the Windows Firewall state for all three profiles (Domain, Private, Public). A device where the Public firewall profile is disabled (common in environments where the Public profile was deliberately disabled) will fail the firewall compliance check even if Domain and Private profiles are active.

# Check all three firewall profiles
Get-NetFirewallProfile | Select-Object Name, Enabled

If any profile shows Enabled: False and the compliance policy requires the firewall to be enabled for all profiles, enable the profile or modify the compliance policy to exempt the specific profile.

Microsoft Defender signature age: The compliance policy may require Defender signatures to be updated within a specific number of days. On devices that are offline for extended periods, signatures may become stale:

# Force Defender signature update
Update-MpSignature -UpdateSource MicrosoftUpdateServer

Tamper protection conflict: If Tamper Protection is enabled in Defender and a GPO is attempting to configure Defender settings, the GPO settings will not apply and the compliance state may be inconsistent. Disable Tamper Protection via Intune endpoint security policy rather than GPO in Intune-managed environments.

The Intune Management Extension (IME) is responsible for custom compliance scripts, Win32 app detection, and PowerShell script execution. When IME is not syncing correctly, compliance evaluations that depend on it show as Not Evaluated or Error.

Check IME health on the device:

# Check IME service status
Get-Service -Name "Microsoft Intune Management Extension"

# Check IME logs (last 50 lines)
Get-Content "C:\ProgramData\Microsoft\IntuneManagementExtension\Logs\IntuneManagementExtension.log" |
Select-Object -Last 50

Common IME log errors and resolutions:

• Error: Failed to retrieve policies from Intune: Network connectivity issue to Intune service. Check proxy bypass rules for *.manage.microsoft.com
• Error: Device not AAD joined or enrolled: The device's Entra ID join state is inconsistent. Re-run dsregcmd /debug /join or re-enroll the device
• Error: Certificate for enrollment not found: The MDM enrollment certificate expired. Re-enroll the device via Settings > Accounts > Access work or school > Disconnect and re-connect

For custom compliance scripts that show Not Evaluated:

1. Navigate to Intune > Devices > [device] > Device diagnostics (collect logs)
2. Download the diagnostic package and examine the CustomCompliance subfolder
3. Check the script output and return value -- custom compliance scripts must output a JSON object with specific format: {"SettingName": "value"}

For devices with persistently stale compliance states despite syncing:

1. Unenroll the device from Intune (Retire, not Wipe -- Retire removes management without wiping data)
2. Re-enroll via Settings > Accounts > Access work or school > Add work or school account
3. Allow 30-60 minutes for the compliance policies to fully evaluate on the fresh enrollment