Intune Compliance Policy Not Evaluating: End-to-End Troubleshooting Checklist

When to Use This Guide

Use this guide when a Windows device managed by Microsoft Intune shows Not evaluated, In grace period, Error, or a compliance state that does not match what you expect on the device.

Common examples:

• The device is online and syncing, but compliance stays Not evaluated.
• Sync in the Intune admin centre succeeds, but compliance does not update.
• Conditional Access blocks access because the device is noncompliant, but the portal shows a different state.
• One setting in a compliance policy shows Error while the rest look fine.
• A newly enrolled device never moves out of Not evaluated after Autopilot or manual enrolment.
• Compliance worked yesterday, but a policy change or assignment change broke evaluation.
• The device appears compliant in Intune, but Entra sign-in still fails the Require compliant device grant control.

The useful question is not "is the policy assigned?" It is "has this device checked in recently enough for Intune to evaluate the assigned policy, can each setting be measured on this device, and is the result tied to the correct device object?"

For wider context, see the Intune hub, Microsoft Entra ID hub, and Conditional Access Microsoft 365 Policy Map.

Scope and Assumptions

This guide is written for Windows 10 22H2 and Windows 11 23H2, 24H2, and 25H2 devices enrolled in Microsoft Intune. It covers Microsoft Entra joined, Microsoft Entra hybrid joined, and co-managed Windows devices where Intune compliance is expected to feed Conditional Access.

It focuses on compliance evaluation timing, assignment scope, per-setting failures, grace periods, MDM sync health, local Windows evidence, and stale Entra or Intune device records.

It does not cover iOS, Android, macOS, or Configuration Manager-only compliance except where co-management affects Intune evaluation.

Useful Microsoft references:

• Device compliance policies in Intune
• Monitor device compliance
• Create custom compliance policies
• Sync your Windows device manually

Prerequisites

Before troubleshooting one device, confirm the basics:

• You can find the device in Intune admin centre > Devices > Windows devices.
• You know the expected user, device name, serial number, and Entra device ID.
• The device is enrolled in Intune MDM, not only registered in Entra ID.
• The device has a valid Intune licence through the user, device licence, or another supported licensing model.
• The device is online with a correct system clock.
• You have local administrator rights for registry, event log, and diagnostic collection on the device.
• You have Intune permissions to read compliance status and, if needed, trigger remote sync.

Do not start by deleting the device record. If you remove the wrong object before collecting evidence, you can make assignment, Autopilot, BitLocker recovery, and Conditional Access investigations harder.

Symptoms

If the device is not checking in at all, use Intune Device Not Syncing first. If Win32 apps or remediations are stale but compliance is the only issue, stay on this guide.

The Four Root Causes

When Intune reports a device as Not evaluated or stuck in a compliance state that does not reflect reality, it is almost always one of these four things:

1. The device has not synced recently enough — Intune compliance evaluation requires a recent check-in.
2. The compliance policy is not assigned to the device or user — assignment scope mismatch or exclusion group.
3. The compliance policy has a setting that cannot be evaluated — usually a missing prerequisite or unsupported platform state.
4. The device is in a grace period or has a noncompliance action configured — the portal shows the grace state, not an evaluation failure.

Work through the checks below in order.

Check 1: Last Sync Time

On the device, open Settings > Accounts > Access work or school > [account] > Info. Scroll down to Sync status. If the last sync was more than 8 hours ago, trigger a manual sync here.

Alternatively, from Intune:

1. Navigate to Devices > [device name]
2. Check Last check-in timestamp
3. If stale, click Sync to push a sync request

After sync, wait 5–10 minutes and re-check the compliance state. Compliance evaluation is not instantaneous; it follows MDM check-in and policy processing.

If sync does not improve the state, collect MDM diagnostics before changing assignments:

$logPath = "C:\Temp\IntuneDiag"
New-Item -ItemType Directory -Path $logPath -Force | Out-Null
mdmdiagnosticstool.exe -area "DeviceEnrollment;DeviceProvisioning" -cab "$logPath\diag.cab"

Expected result shape: a .cab file under C:\Temp\IntuneDiag containing MDM event logs and enrolment state.

Check 2: Policy Assignment

1. In the Intune portal, navigate to Devices > Compliance policies > [policy name] > Device status
2. Search for the device. If it does not appear, the policy is not assigned to this device.
3. Check the assignment: Is the policy assigned to a group? Is the device or the enrolled user a member of that group?
4. Check for conflicting exclusion groups — the device may be in a group that is excluded from the policy.
5. Confirm the policy platform matches the device OS. The Windows 10 and later platform includes Windows 11; inspect individual setting applicability and minimum/maximum OS constraints.

Tenant default: no policy means compliant

A device with no assigned compliance policy defaults to compliant at the tenant level unless you changed Endpoint security > Device compliance > Compliance policy settings.

Verify the tenant default:

1. Go to Endpoint security > Device compliance > Compliance policy settings
2. Review Mark devices with no compliance policy assigned as
3. If this is set to Not compliant, devices without an assigned policy will fail Conditional Access even when individual settings look healthy

This is a common source of "why is this kiosk noncompliant when I never assigned a policy?" confusion.

Check 3: Evaluate the Specific Setting

If the policy is assigned and the device has synced but a specific setting is showing Not evaluated or Error:

1. Click the device in the Intune portal and navigate to Monitor > Device compliance
2. Open the policy and expand per-setting evaluation results
3. Note any settings showing Error, Not evaluated, or Not applicable

Common problematic settings:

BitLocker and Secure Boot prerequisites

If BitLocker is required, confirm encryption state locally:

manage-bde -status C:

Check both Conversion Status and Protection Status. Fully Encrypted does not establish that protectors are active or a recovery key is backed up.

If Secure Boot is required on physical hardware, confirm in firmware and OS:

Confirm-SecureBootUEFI

Expected result is True when Secure Boot is enabled on supported UEFI hardware. Supported virtual machines can also use Secure Boot; investigate their configuration before considering a scoped exception.

Check 4: Grace Period and Noncompliance Actions

If the compliance state shows a yellow status or In grace period:

1. Navigate to the compliance policy > Actions for noncompliance
2. Check the configured grace period. Default is 0 days (immediate noncompliance).
3. If a grace period is set, the device shows as noncompliant-grace during the window — this is working as intended, not an evaluation failure.

Document the grace period before escalating to the security team. A grace period delays the configured mark-noncompliant action. Inspect the aggregate device compliance state and sign-in result; another failed policy can still block access. See actions for noncompliance.

Portal Evidence Collection

Before changing policy, capture portal evidence for the incident record:

Export device compliance for bulk comparison when more than one device is affected:

1. Reports > Device compliance > Compliance policy device status
2. Filter by the affected policy
3. Export to CSV and sort by Compliance state

Graph API Checks

Use Microsoft Graph PowerShell when you need evidence at scale or the portal view is incomplete.

Connect-MgGraph -Scopes "DeviceManagementManagedDevices.Read.All","DeviceManagementConfiguration.Read.All"

$deviceName = "<device-name>"
$device = Get-MgDeviceManagementManagedDevice -ManagedDeviceId "<verified-intune-managed-device-id>" -ErrorAction Stop

$device | Select-Object deviceName, complianceState, lastSyncDateTime, managementAgent, operatingSystem, osVersion

Expected output shape:

deviceName        : <name>
complianceState   : noncompliant | compliant | inGracePeriod | unknown
lastSyncDateTime  : <timestamp>
managementAgent   : mdm | eas | configurationManagerClient

Read aggregate compliance counts for one policy when you know its ID (this is not a device list):

$policyId = "<compliance-policy-id>"
Get-MgDeviceManagementDeviceCompliancePolicyDeviceStateSummary -DeviceCompliancePolicyId $policyId

If Graph shows a different compliance state than the portal, wait 10 minutes and refresh both. Eventual consistency between reporting surfaces is normal.

Event Log and Registry Evidence

On the device, MDM policy processing is recorded under:

Applications and Services Logs > Microsoft > Windows > DeviceManagement-Enterprise-Diagnostics-Provider

Useful event patterns:

Check whether compliance-related CSP state exists:

Get-ChildItem "HKLM:\SOFTWARE\Microsoft\PolicyManager\current\device" -ErrorAction SilentlyContinue |
    Select-Object -First 10 PSChildName

If PolicyManager is empty and MDM enrolment looks incomplete, return to Intune Device Not Syncing.

Custom Compliance Scripts

Custom compliance policies depend on a detection script returning valid JSON. Common failure modes:

• Script exits non-zero even when detection succeeds
• JSON schema does not match Microsoft requirements
• Script runs in user context when it needs SYSTEM context
• Assignment targets the wrong platform or architecture

Validate locally before re-uploading:

powershell.exe -NoProfile -File "C:\Path\Detect-Compliance.ps1"
echo $LASTEXITCODE

A custom compliance discovery script returns a single compressed JSON object containing discovered values. Intune compares those values with the uploaded JSON rules. It does not use exit 1 for compliant and exit 0 for noncompliant; do not copy the Remediations exit-code contract here. Validate successful script execution and JSON keys, types and values against Microsoft’s custom discovery-script requirements. Keep diagnostic chatter out of standard output.

Safe Retry and Recovery

Use the smallest change that restores evidence-backed compliance reporting.

1. Trigger one manual sync from the portal and one from the device.
2. Wait 10 minutes and re-check per-setting evaluation.
3. If one setting is wrong, test a pilot exclusion for that setting on a lab device before changing production policy.
4. If the device object is stale after re-enrolment, compare Entra device ID with the active Intune managed device record before deleting anything.
5. If you must retire and re-enrol, document BitLocker recovery key location and Autopilot assignment impact first.

Do not widen policy exceptions tenant-wide as a first response. Fix assignment, sync, or the failing setting on a named pilot group instead.

Prevention Checks

After recovery, add these checks to change control:

• Every compliance policy has an owner, assignment description, and exception expiry where needed.
• Pilot groups exist for new BitLocker, Secure Boot, and minimum OS version requirements.
• Conditional Access policies that require compliant devices exclude break-glass accounts correctly.
• New Autopilot profiles include enough time for first compliance evaluation before user reaches production apps.
• Custom compliance scripts are version-controlled and their JSON output is validated against the policy rule schema.

Related Resources

• Intune Device Not Syncing
• Autopilot Enrollment Status Page Stuck
• Deploying Windows LAPS with Microsoft Intune
• Conditional Access Microsoft 365 Policy Map
• Rolling Out Microsoft Defender for Endpoint with Intune

Correction record

10 September 2026 — Reviewed against documentation: Corrected custom compliance JSON semantics, quoted diagnostic areas, Windows platform applicability, event 814, aggregate Graph reporting and device identity selection. Code and output remain illustrative, not execution evidence.