Device Not Compliant in Intune: Mapping Each Status to Its Cause

A user opens Outlook on Monday morning and gets a sign-in screen that refuses to let them through because their device has to be compliant, and Teams does the same thing a minute later. The admin who looks up the laptop in Intune finds it marked Not compliant, or Not evaluated, or In grace period, and the search that follows is usually some version of device not compliant intune.

Each of those statuses has a short list of causes, and most of them are settings an admin chose, often years ago, rather than something wrong with the laptop. The fastest fix comes from knowing which system made the decision, which status the device is actually in, and which tenant-wide setting is quietly shaping the answer.

Which system is actually blocking the user?

Two products are involved, and they do different jobs. Intune evaluates the device against compliance policies and produces a status. Microsoft Entra Conditional Access reads that status and decides whether to grant the sign-in. Microsoft describes the hand-off plainly: Intune sends compliance information to Microsoft Entra ID so Conditional Access can decide to grant or block access to resources.

The block the user sees comes from a Conditional Access policy whose grant control is Require device to be marked as compliant. That control sits alongside others such as Require multifactor authentication and Require Microsoft Entra hybrid joined device, and when several are selected, Conditional Access requires all of them by default unless the policy is set to require only one. A policy that requires compliance and MFA together will still block a compliant device whose user cannot complete MFA, so confirm which control failed before blaming Intune.

The compliance control has its own limits. Devices must be registered in Microsoft Entra ID before they can be marked compliant, and the control only supports Windows 10 and later, iOS, Android, macOS, and Linux Ubuntu devices that are registered with Entra and enrolled in Intune. Microsoft Edge in InPrivate mode on Windows is considered a noncompliant device, so a user working in a private Edge window will be blocked on an otherwise healthy laptop. The device-code OAuth flow cannot carry device state at all, so a device requirement is not supported there.

What does each compliance status mean?

The device compliance dashboard, under Devices then Compliance and the Monitor tab, counts devices in four states. Each one points to a different first question.

• Compliant: the device successfully applied one or more compliance policy settings. If the user is still blocked, the problem is elsewhere: licensing, the Conditional Access policy itself, or a stale sign-in.
• In-grace period: the device is targeted by compliance settings and is not yet compliant with all of them, but it is inside a grace period the admin defined. Microsoft notes these devices are noncompliant, just not yet marked that way.
• Not evaluated: an initial state for newly enrolled devices, and also the state for devices with no compliance policy and no trigger to check, devices that have not checked in since the policy last changed, and devices without a user, such as Android Enterprise dedicated devices or devices enrolled with a device enrollment manager account.
• Not compliant: the device failed one or more compliance settings, or the user did not comply with the policies.

Inside an individual policy's report there is also an Error state for a setting. Intune holds the device's existing compliance status for up to seven days while that setting resolves. If the setting is still in Error after seven days, the device becomes Not compliant, or In grace period if the policy has a grace period set. A device that was compliant on Monday can therefore lose access a week later with nobody having changed anything.

Which tenant-wide settings shape the answer?

Every tenant has a set of Compliance policy settings, found under Endpoint security, then Device compliance, then Compliance policy settings. Microsoft describes them as acting like a built-in compliance policy that every device receives. Two of them matter for this problem.

The first is Mark devices with no compliance policy assigned as. It has two values. Compliant is the default, and it means devices that never receive a compliance policy are considered compliant. Not compliant treats them as noncompliant. Microsoft recommends switching to Not compliant when Conditional Access uses device compliance, so that only devices confirmed as compliant reach your resources. When a user is noncompliant because nothing is assigned, the Company Portal app shows the message No compliance policies have been assigned.

The second is Compliance status validity period (days). A device must successfully report on all of its compliance policies within this period, or it is treated as noncompliant. The default is 30 days, and the range is 1 to 120 days. In the Setting compliance report this check appears with the name Is active in the Setting column, which is the clue when a laptop that sat in a drawer comes back noncompliant with no failed policy setting.

Microsoft also lists the conditions the built-in policy checks. A device is noncompliant if it has no applicable compliance policy assigned, if it has not stayed in contact with Intune, or if the enrolled user does not exist or lacks a valid Intune license.

How does the grace period work?

The grace period is not a tenant setting. It lives in each compliance policy's actions for noncompliance. Every policy includes Mark device non-compliant as a built-in action, scheduled at zero days, so a failing device is marked noncompliant immediately and Conditional Access can block it right away. That action cannot be removed, but its schedule can be changed.

The schedule is counted in days after the device is found noncompliant. Changing the mark action from 0 to, say, 3 gives the user three days to fix the problem before the status flips and access stops. The admin center accepts whole numbers and decimals in 0.25 increments, where 0.25 equals 6 hours, so a same-day grace window is possible. Other actions run on their own schedules: Send email to end user, Send push notification to end user, Remotely lock the noncompliant device on supported platforms, and Add device to retire list, which only flags the device until an admin retires it.

The email action has two details that cause silent failures. Intune uses the email address in the user's profile, not their user principal name, and sends nothing if no address is on file. The messages come from microsoft-noreply@microsoft.com, so a mail rule that blocks that sender means users never get the warning that their grace period is running out. Microsoft says compliance emails are expected within 6 hours after a device is marked noncompliant.

How do you force a re-check?

Intune reports are updated when the device checks in, so the admin center shows the last known state from the last check-in, not what the device looks like right now. A new policy can take up to 24 hours to appear in a policy's device status chart when the device is online. Waiting is rarely the best option.

On Windows, the user opens the Company Portal app, goes to Devices, selects the device, and under Device status selects Check access. The app syncs the device with current requirements, which can take a few minutes, and returns one of three answers: Can access company resources, Cannot access company resources, or Can access company resources, but action required, the last one carrying a date to fix things by. On iOS the same job is Check status under Devices. A user checking status in Company Portal is also one of the documented triggers for Intune to recalculate compliance.

If a device gets stuck in a checking-compliance state, Microsoft's troubleshooting steps are short: update Company Portal to the latest version, restart the device, and try a different network such as cellular instead of Wi-Fi.

A worked example: the policy nobody assigned

A 20-seat accounting firm turns on a Conditional Access policy for Exchange Online and Teams that requires a compliant device. A Windows compliance policy is assigned to a group called Office Laptops. Everything works for months, because the tenant still has Mark devices with no compliance policy assigned as set to its default of Compliant. Two partners read email on personal iPhones enrolled in Intune with no iOS compliance policy at all, and those phones pass simply because nothing is evaluating them.

During a security review, someone follows Microsoft's recommendation and flips the setting to Not compliant. The next morning both partners are blocked in Outlook on their phones, while every laptop keeps working. Company Portal on the phones shows No compliance policies have been assigned, and both devices appear in the Devices without compliance policy tile on the dashboard.

The setting change was correct, and it worked exactly as designed. It exposed a gap that had been there since day one: the phones were never being checked. The fix is to create an iOS compliance policy, assign it to the partners, then have each one run Check status in Company Portal. The cleaner order of operations would have been to open the Devices without compliance policy view first, assign policies to whatever it listed, and only then flip the setting.

Where this goes wrong

Most repeat tickets come from a handful of patterns.

• The device shows Compliant but the user is still blocked. Microsoft's first check is whether the user has an Intune license assigned. A device that was just enrolled may also need a few minutes for compliance information to register.
• The device is noncompliant but the user is not blocked. Check the targeting of both the compliance policy and the Conditional Access policy. A user who is not in an assigned group, or who sits in an excluded group, is not blocked.
• The per-policy report says compliant and the device is still Not compliant. A policy's report covers only that policy. Another policy targeting the same device can be the one failing, and when several compliance policies apply, Intune uses the most secure.
• A shared PC shows the wrong person's result. Compliance reports show the status for the last user on the device.
• A retired device keeps mail access for a while. Exchange caches access rights for six hours, so retirement does not cut off access immediately.
• A long-offline laptop comes back blocked. The validity period, 30 days by default, lapsed. Separately, Company Portal enters an enrollment remediation flow when a device has not checked in for 30 days or more, and if one more check-in fails, Intune issues a retire command so the user can re-enroll.

The decision rule

Read the status before touching anything. Compliant but blocked means licensing, the Conditional Access grant controls, or the browser. Not evaluated means no check-in or no policy, so look at assignment and run Check access. In grace period means the clock is running in that policy's mark-noncompliant schedule. Not compliant means open the device's per-setting results and fix the setting that failed, then re-check from Company Portal. And before setting devices with no policy to Not compliant, empty the Devices without compliance policy list first, so the change catches no one by surprise.