Conditional Access + Intune Compliance: How Device Security Becomes an Access Decision

Ask most admins how device compliance connects to Conditional Access, and the honest answer is usually "you turn on the setting and it works." That's true, but it skips the part that actually matters: there are six distinct stages between a setting changing on a physical laptop and Microsoft 365 deciding whether that laptop gets in. Understanding those six stages is where the architecture behind Conditional Access and Intune actually clicks into place, rather than feeling like two separate products that happen to talk to each other.

Windows Device
      ↓
Intune Compliance
      ↓
Device State
      ↓
Microsoft Entra
      ↓
Conditional Access
      ↓
ALLOW / BLOCK

The Six Stages, One at a Time

Stage 1: Windows Device

Everything starts as facts sitting on the physical machine, with no interpretation attached yet. Is BitLocker turned on. What build of Windows is installed. Is a PIN configured. Is Microsoft Defender running and up to date. Is the firewall enabled. The device itself doesn't know or care whether any of this is "good enough," it just is what it is at this exact moment.

Stage 2: Intune Compliance

The Intune Management Extension on the device reports that raw state back to Intune, which checks it against the compliance policy you configured for that device's group: minimum OS version, encryption required, jailbreak/root detection, whatever rules apply. This isn't continuous. Windows devices check in on a schedule, roughly every 8 hours by default, or on-demand when a user forces a sync from the Company Portal app or Settings.

Stage 3: Device State

Intune produces a result: Compliant, Non-compliant, or occasionally In Grace Period (a configurable window that gives users time to fix a new failure, like a just-expired OS build requirement, before enforcement kicks in). This result gets written back to the device record in Intune, and this is also the exact moment the "compliance is a checklist, not a security guarantee" distinction becomes real: this stage only knows about the rules you configured, nothing else.

Stage 4: Microsoft Entra

Here's the step that's easy to miss entirely: the compliance result doesn't stay inside Intune. It gets synchronised to the device's own object in Microsoft Entra ID, the same directory that holds your user accounts, as an attribute on that device record. This only works at all if the device is actually registered as an identity in Entra first, through Microsoft Entra joined, Hybrid Microsoft Entra joined, or Microsoft Entra registered. A device with no identity in Entra has nothing for a compliance flag to attach to, no matter how well-configured Intune's policy is.

Stage 5: Conditional Access

When a sign-in happens, Conditional Access evaluates every policy that matches the request, and if one of them has Require device to be marked as compliant as a grant control, it checks exactly one thing at this stage: the compliance attribute already sitting on that device's Entra ID object from Stage 4. It isn't re-running Intune's rules, it's reading a result someone already calculated.

Stage 6: Allow or Block

If the compliance attribute says compliant and every other condition in the matching policy is satisfied, access is granted. If it says non-compliant, the user typically sees a message pointing them to enrol or fix their device, not a generic access-denied error. If the device has no compliance attribute at all (never enrolled, never registered), Conditional Access treats that the same as non-compliant: no evidence of compliance means the grant control isn't satisfied.

A Worked Example: The Laptop That Loses BitLocker

The device was insecure for hours before anything actually stopped it. That gap is the direct, mechanical consequence of Stage 2 being scheduled rather than continuous, not a bug in the design, just a real limit worth knowing rather than assuming compliance means "right now."

Where This Fits With Everything Else

This six-stage pipeline is specifically the device compliance path into Conditional Access. It's one input among several the decision engine can combine, alongside user identity, sign-in risk, location, and required authentication strength, covered in full in how Conditional Access actually decides. If you're setting up the actual policy that uses this pipeline, Require Compliant Devices is policy 7 in the field guide, and the hands-on rollout guide covers how to turn any new policy on without it turning into an outage.

Summary

Have you ever chased down why a device stayed compliant, or stayed blocked, longer than expected? Nine times out of ten it's the check-in schedule at Stage 2. Drop a comment with what you found if it was something else.