How Intune compliance reaches Conditional Access
From enrolment to a sign-in decision: how a device's compliance state is worked out, stored and checked, and why compliant devices still get blocked.
The device enrols
A Windows laptop joins Entra ID and enrols in Intune, for example through Autopilot. Intune assigns the compliance policies that target the device or its user.
All the steps
A Windows laptop joins Entra ID and enrols in Intune, for example through Autopilot. Intune assigns the compliance policies that target the device or its user.
At each check-in the device reports the settings the policies ask about: encryption, OS version, firewall, antivirus and so on. On supported Windows versions, a change can also trigger a re-evaluation straight away.
If every setting passes, the device is compliant. If not, the actions for non-compliance apply: mark non-compliant immediately or after a grace period, and optionally notify the user.
Intune writes the compliance flag to the device's object in Entra ID. That flag, not Intune itself, is what Conditional Access reads.
The browser or app needs to prove which device it's on. Edge signed in with the work account does this, as do Office apps through the Primary Refresh Token. Chrome needs the Microsoft Single Sign On extension.
A policy requiring a compliant device looks up the device ID sent with the sign-in and reads its compliance flag. If no device ID arrives, the device can't be identified, even if it's compliant.
With a compliant, identified device, the sign-in succeeds and the device details appear on the sign-in log's Device info tab.
Otherwise the sign-in fails with AADSTS53000. The user can check what's wrong in Company Portal, fix it and sync. If a device stops checking in, it becomes non-compliant after the compliance status validity period, 30 days by default.