Intune Compliance Policies: The Parts That Actually Matter

Compliance policy vs compliance policy settings, why 'not evaluated' isn't the same as 'compliant', and the Conditional Access gate that makes any of it worth doing.

What's new — a short, independent summary. Read Microsoft's original: Microsoft Learn →

Compliance in Intune trips people up because there are two different things wearing the same name, and the portal doesn’t do much to tell them apart. Get the distinction straight and the rest falls into place.

Two knobs, not one

Compliance policy settings are tenant-wide. They live under Devices > Compliance > Compliance policy settings, and the one that catches everyone is “Mark devices with no compliance policy assigned as.” The default is Compliant. Read that again: out of the box, a device with no policy at all is treated as compliant. If you’re relying on compliance to gate access, flip that to Not compliant on day one, or you’ve built a fence with no gate.

Device compliance policies are the actual rules — platform-specific, assigned to groups: minimum OS version, BitLocker, Secure Boot, Defender running, jailbreak/root checks, and so on.

“Not evaluated” is doing a lot of quiet damage

The state you’ll spend the most time on isn’t Compliant or Non-compliant — it’s Not evaluated. A device shows up in the dashboard, but no policy has actually landed on it yet: it hasn’t checked in since assignment, it’s in the wrong group, or the assignment filter excluded it. To a Conditional Access policy, “not evaluated” is not “compliant”, so users get blocked while you’re staring at a device that looks fine. When something’s mysteriously locked out, this is the first place to look.

The actions timeline is the useful bit

Rather than flipping a device to non-compliant the instant it drifts, use Actions for noncompliance to stage it: send the user an email on day 0, mark non-compliant after a grace period, then let Conditional Access do the blocking. It turns a hard cutoff into a nudge, which is the difference between a working rollout and a flood of tickets.

It’s pointless without Conditional Access

On its own, a compliance policy just writes a status into a dashboard nobody reads. The value only appears when a Conditional Access policy requires a compliant device to reach Exchange, SharePoint, or everything. That’s the pairing that actually enforces anything — compliance decides the state, Conditional Access acts on it.

Start with the tenant-wide default set to Not compliant, one baseline policy per platform, a sensible grace period, and a Conditional Access policy that requires compliance. That’s the whole game; everything else is refinement.

Source: Microsoft Learn. Summarised independently — check the source for the latest detail.