Intune device compliance policy: the control that never blocks anything

01 / 11

What is an Intune device compliance policy?

A compliance policy is a set of platform-specific rules that Intune evaluates against an enrolled device and reduces to a single status: compliant, or not compliant. It measures. It does not block. Everything that actually denies a user access sits downstream of it.

That separation is the design. A device configuration profile writes settings to a device. A security baseline is a configuration profile with Microsoft's recommended values pre-set — the documentation is explicit that baseline settings are device configuration settings like those found in other Intune policies. A compliance policy reads the resulting state and reports it. Conditional Access is the layer that turns that report into a decision.

There is one honest caveat, and Microsoft states it plainly rather than hiding it. Some compliance settings do reach the device: password and PIN requirements are the named example, described as resulting in enforcement on the device even where the configuration profile is more lenient, and there is a per-setting Remediated state in which the operating system enforces the requirement directly. So the boundary is clean in intent and slightly porous in practice — which is exactly why compliance settings take precedence over configuration profiles when both manage the same thing.

02 / 11

So what actually blocks access?

Conditional Access does, and only for devices it can see. Intune writes the result of its evaluation to the device object in Microsoft Entra ID as isCompliant — a read-only boolean that only Intune can set, or on Windows alone an approved third-party MDM. A Conditional Access policy using the Require device to be marked as compliant grant control reads that one boolean. It does not inspect which policy passed, how recently it was evaluated, or whether any policy was assigned at all.

The second enforcement path is the scheduled action inside the compliance policy itself: mark noncompliant, email the user, remotely lock, send a push notification, or add the device to a retire list. That last one is widely mis-described in circulating write-ups. Adding a device to the retire list does not retire it — the current documentation is explicit that an administrator must initiate the retirement separately.

Draw the sequence once and the failure modes become obvious. Every step is a different product surface, and in most organisations a different person owns each one.

03 / 11

The tenant default that quietly disables the whole thing

This is the highest-value setting in the entire subject, and it is one radio button. Under the tenant-wide compliance policy settings, Mark devices with no compliance policy assigned as ships set to Compliant.

Read that against the paragraph above. An enrolled device with no compliance policy targeted at it reports compliant, writes a true value to Entra ID, and satisfies a Require device to be marked as compliant grant control. The Conditional Access policy is enabled, the dashboard is green, and nothing has been evaluated.

• Flip it to Not compliant, then handle the fallout deliberately. The setting is tenant-wide, so every enrolled device without a targeted policy becomes noncompliant at once. Stage it behind a report-only Conditional Access policy, not on a Friday.
• **Newly enrolled devices report Not evaluated, which is not the same as unknown.** The documented status set is Compliant, Not compliant, In-grace period and Not evaluated. Devices with no user affinity — userless Apple automated device enrolment, Android Enterprise dedicated — sit in that state by design.
• Conditional Access without an Intune compliance policy is a no-op. Microsoft's own how-to states the policy will not function as intended until at least one compliance policy exists and at least one device is compliant.

04 / 11

How does compliance evaluation work in an enterprise, and how slow is it?

Compliance has no clock of its own. It rides the device check-in cycle, and that cycle is slower than most Conditional Access designs assume.

Two further delays sit beyond the check-in, and both are routinely missed. Microsoft publishes no latency figure at all for the write from Intune to Entra ID — if you have seen a specific number quoted for it, that number is not from Microsoft's documentation. And a device turning noncompliant is not among the critical events that continuous access evaluation acts on, so a token already in the user's hands stays valid regardless.

05 / 11

What happens when two policies disagree

Conflict resolution in Intune happens at the level of the individual setting, not the policy. There is no winning policy — there is a winning value for each setting, and three different rules decide it. A fourth case has no rule at all, which is the one worth knowing.

06 / 11

Enrolment is the prerequisite most projects under-plan

None of the above exists until a device is enrolled and holds an identity in Entra ID. Compliance can never be evaluated for a device Intune does not manage, and a device unregistered in Entra ID has every device property evaluated as null — which is why a Conditional Access filter written as isCompliant equals False silently fails to catch precisely the devices you were worried about. Write device filters with negative operators, and keep the grant control as the actual boundary.

• Set the MDM authority first. It must be set before any device can enrol, and it cannot be changed back to Unknown afterwards.
• Assign the licences. Intune Plan 1 is the floor for device management; automatic enrolment through Entra ID additionally requires Entra ID P1 or P2.
• Set the MDM user scope to Some or All. Left at None, users must enrol manually — the single most common reason a device never appears in Intune at all.
• Put the Apple certificates in a calendar with named owners. The Apple MDM push certificate is valid for 365 days with a 30-day grace period after expiry, and must be renewed using the same Apple account that created it. The automated device enrolment token renews yearly. Neither is recoverable by escalation once the original account has left the company.

07 / 11

Enrolment restrictions do not apply where you most expect them

Platform and device-limit restrictions look like a perimeter. They are not applied to enrolments that are not user-driven; the default restriction policy is used instead. This is documented, easy to miss, and the gap sits exactly where corporate provisioning lives.

• Outside platform restrictions entirely: Autopilot self-deploying mode, Autopilot pre-provisioned deployment, bulk provisioning packages, co-managed enrolments, userless Apple automated device enrolment, Azure Virtual Desktop, Windows 365, and Android Enterprise dedicated devices.
• Device limits cannot be applied at all to co-managed, Group Policy, Entra-joined, Autopilot or device enrolment manager enrolments. The documented alternative is the per-user device limit in Entra ID, and where both exist the more restrictive one wins.
• The Intune limit tops out at 15 devices per user. A device enrolment manager account, by contrast, can enrol up to 1,000 devices — a genuinely useful capability and an obvious blast radius. Treat those accounts as privileged.

08 / 11

What security and governance controls does this actually need?

Three, and they are cheap. Exclude break-glass accounts from any Conditional Access policy that requires a compliant device — Microsoft's own guidance notes that such an account can otherwise be unusable in the exact emergency it exists for, and now recommends giving those accounts phishing-resistant credentials rather than relying on the exclusion alone.

Second, do not use the Conditional Access device platform condition as a security boundary. It is derived from the user agent string and is documented as unverified. Platform conditions are for scoping; the compliance grant control is for enforcing.

Third, decide in advance who owns each step in the chain. In most tenants the enrolment configuration, the configuration profiles, the compliance policies and the Conditional Access policies are owned by three or four different people, and the failure mode is not a bad policy but an unmade decision between two of them.

09 / 11

Where Microsoft's own documentation disagrees with itself

Naming the contradictions is more useful than quietly picking a winner, because these are the places a well-prepared architect gets caught out in a design review. Every row below was checked on 27 August 2026.

10 / 11

A first compliance baseline worth actually deploying

What follows is author-proposed rather than Microsoft guidance, and it is deliberately small. Most compliance programmes fail because version one was too ambitious and got rolled back after the first lockout.

• Set the no-policy default to Not compliant. This is the change that makes everything else real. Nothing else on this list matters if you skip it.
• One compliance policy per platform, not per department. Encryption on, secure boot or the platform equivalent, a minimum operating system version you are willing to maintain, and a password or PIN requirement. Nothing else in version one.
• Set a deliberate grace period rather than accepting zero. The schedule field takes 0.25-day increments, so 0.5 is twelve hours if you want it tight. Zero is the default and it is unforgiving on the morning a laptop reboots into a BitLocker state it has not yet reported.
• Run the Conditional Access policy in report-only for two full weeks. Two weeks clears more than one 8-hour check-in cycle for every device that happened to be switched off during the first.
• Do not layer a security baseline over configuration profiles that touch the same settings. The clearest rule in this area is to use one or the other for a given setting, never both, because nothing arbitrates between them.
• Write your device filters with negative operators so unregistered devices, whose properties all evaluate as null, do not fall through them.

11 / 11

When should a business bring in outside help?

Not for a single compliance policy. A test tenant, a spare laptop and an afternoon will produce a working one, and you will understand it better for having built it yourself.

It is worth outside help at three specific points. The first is the cutover: flipping the no-policy default and enabling a compliance grant control across a live tenant is a change with a real lockout mode, and it is easier to sequence with someone who has done it before. The second is a mixed estate — Windows plus Apple plus Android, each with its own enrolment prerequisites, certificate expiries and platform ceilings, is where these projects stall for months rather than weeks. The third is regulatory, where a device compliance state has to be evidenced to an examiner rather than merely working on the day.

Disclosure: Avalon Web Services sells Microsoft endpoint work, including the Intune endpoint rollout package linked below, so read this section as an interested opinion. The three tests above are the honest ones. If none of them describes your situation, do it yourself.