A device shows Not compliant in the Microsoft Intune admin center, yet every compliance policy you created reports success. The usual culprit is the Default Device Compliance Policy, a built-in evaluation you never assigned. In this post I'll explain its three checks, what trips each one, and how to clear them before Conditional Access starts blocking your users.
Symptoms#
- In Devices › All devices, the device's Device compliance view lists Default Device Compliance Policy as Not compliant while your own policies are Compliant.
- Opening that entry shows one or more failing settings: Is active, Enrolled user exists or Has a compliance policy assigned.
- Users on the device are blocked by a Conditional Access policy that requires a compliant device.
- The Company Portal may report No compliance policies have been assigned.
Why it happens#
The Default Device Compliance Policy is how Intune applies its tenant-wide compliance policy settings, which every enrolled device receives. You manage them at Endpoint security › Device compliance › Compliance policy settings. Whenever Intune runs a compliance calculation, it marks the device noncompliant if any of these three conditions isn't met:
| Check | What Intune expects | Common triggers |
|---|---|---|
| Has a compliance policy assigned | At least one compliance policy assigned to the device that has a setting applicable to it. | All policies target user groups and the device has no user (kiosk, shared, self-deploying or bulk-enrolled); the device is excluded everywhere; the only policy is for another platform. |
| Is active | The device reports status for all its compliance policies within the Compliance status validity period (days): 30 by default, configurable from 1 to 120. | A laptop left powered off or offline; a broken MDM sync; an old record left behind after a reset or re-enrollment that never checks in again. |
| Enrolled user exists | The user associated with the device still exists and holds a valid Intune license. | The account was deleted when someone left, or the Intune license was removed during a licensing clean-up. |
Note: The first check depends on Mark devices with no compliance policy assigned as. Its default, Compliant, lets a device without a policy pass. Microsoft recommends Not compliant when you use Conditional Access, which is why this check often appears right after that setting changes.
Conditional Access doesn't care which policy failed. A grant control that requires a compliant device reads the overall state Intune reports to Microsoft Entra ID, so a failed built-in check blocks access exactly like a failed BitLocker or OS version rule.
How to fix it#
- Find the failing check. Open the device, select Device compliance, then Default Device Compliance Policy. For a tenant-wide view, go to Devices › Monitor › Setting compliance, where the validity period appears as Is active in the Setting column.
- Fix the cause using the matching section below.
- Trigger a fresh evaluation. Sync the device, then have the user check status in the Company Portal. Not every sync recalculates compliance, but a Company Portal status check always does, so you don't wait for the next scheduled check-in.
Has a compliance policy assigned#
- Create a compliance policy for every platform you enroll, even a minimal one.
- For userless devices, assign at least one compliance policy to a device group. A user-targeted policy follows the user to their devices, so a device without a user never receives it.
- Review exclusions and assignment filters, then open Reports › Device compliance, select the Reports tab and run Devices without compliance policy to find the gaps.
Is active#
- Bring the device online and sync it. On Windows, go to Settings › Accounts › Access work or school, select the account, then Info › Sync. On mobile devices, use Check status in the Company Portal.
- Check Last check-in on the device overview; Windows devices normally check in about every eight hours. If the record belongs to hardware that was reset and enrolled again under a new record, retire or delete the stale one instead of chasing it.
- Only lengthen the validity period if devices legitimately stay offline for weeks, such as a loan pool. It's tenant-wide, so it weakens the check for everyone.
Enrolled user exists#
- Look the account up in Microsoft Entra ID. If it was deleted by mistake, restore it from Deleted users while it's still inside the 30-day soft-delete window.
- Check licensing in Troubleshooting + support › Troubleshoot: select the user and confirm Intune license shows a green check.
- If the person has genuinely left, change the device's primary user to an active, licensed user and have them sign in and sync. If the check still fails, reset the device and enroll it again under a valid account, or as a userless device if that's its job.
Verify the fix#
- After a sync, all three settings in the Default Device Compliance Policy show Compliant and the device's overall state follows.
- In Troubleshooting + support › Troubleshoot, the device shows Intune compliant and Microsoft Entra compliant as Yes. The Microsoft Entra value is the one Conditional Access evaluates.
- The user can open the previously blocked app. Reports refresh when the device checks in, so give summary views a little time to catch up.
Tip: Newly enrolled devices can sit in Not evaluated for a while. That isn't a failure; trigger a sync and check again before you start troubleshooting.
Prevent it next time#
- Switch Mark devices with no compliance policy assigned as to Not compliant only after every platform and every userless scenario has a policy.
- Build offboarding so devices are reassigned, retired or wiped before the user account is deleted or unlicensed.
- Review Setting compliance regularly; a growing Is active count usually means stale records worth cleaning up.
- Choose a validity period that matches how long your devices can realistically be offline, and document the reason.