A compliance policy is a checklist evaluated on the device and reported back to
Intune, which writes the result into Microsoft Entra ID. Conditional Access then
reads that result. Three systems, in that order — and each one adds delay.
Read the per-setting detail
"Not compliant" is not a diagnosis. Every compliance report breaks down to
individual settings with a pass or fail against each. Find the one that failed;
that is the actual ticket.
The usual culprits:
| Setting | Common cause |
|---|---|
| Require BitLocker | Encryption never started, or the user dismissed the prompt |
| Minimum OS version | Updates deferred or paused |
| Require Secure Boot | Firmware setting, or a device imaged outside the standard build |
| Antimalware active | Third-party AV installed alongside Defender |
| Require firewall | A VPN or security product disabled the profile |
| Device not evaluated | The device has not checked in at all — see below |
"Not evaluated" is different from "not compliant"
A device that has never checked in has no compliance state, and the tenant may be
configured to treat that as non-compliant. That is an enrolment or connectivity
problem, not a settings problem. Check the last check-in time before you go looking
for a failing setting.
Fix, then sync, then refresh the token
Three separate waits, and skipping any of them makes a correct fix look like a
failure:
- Remediate on the device — start BitLocker, install the update, re-enable the
firewall. Some of this the user must do; encryption in particular can take
twenty minutes or more on a large drive.
- Force a device check-in so Intune re-evaluates and writes the new state to
Entra ID. Without a check-in the tenant still holds the old result.
- Have the user sign out and back in. Tokens issued while the device was
non-compliant carry that state until refreshed.
Allow up to an hour end to end, and tell the user that number rather than letting
them discover it.
Confirm from the user's side
Verify by having the user open a blocked app, not by looking at the console. The
console tells you what the service believes; only the user tells you whether they
can work.
What not to do
- Do not exclude the device or the user from the Conditional Access policy. The
device is non-compliant for a reason, and that reason is usually "the disk is not
encrypted".
- Do not retire or wipe a device to clear a compliance flag. That is a
data-destroying action taken to avoid reading a report.
- Do not weaken the compliance policy itself to make one device pass.
Related
- Conditional Access basics
- Reading sign-in failure codes (AADSTS)