Conditional Access: device compliance as an access condition

“Only compliant devices get access” is a sentence that appears in every Zero Trust deck. As a policy it takes about five minutes to click together. The work sits somewhere other than most people expect.

The policy is only half the statement

The grant control “Require device to be marked as compliant” checks exactly one yes/no flag on the device object in Entra ID. That flag is set by Intune, on the basis of the compliance policies defined there.

Which leads straight to the point where it comes apart in practice: the Conditional Access policy is exactly as strict as the compliance definition behind it. If nothing substantial is defined there, every enrolled device is compliant, and the policy effectively only checks whether the device is managed at all. That is not worthless, but it is something other than what it says on the tin.

This is exactly why I do not regard identity and endpoint management as two topics. The access decision is made in the identity layer, but the fact it rests on is produced on the device.

The chain that has to hold

For a device to reach the token as compliant, a whole series of things has to line up:

1. 1.The device is registered, joined or hybrid joined in Entra ID
2. 2.It is enrolled in Intune and checks back in regularly
3. 3.A compliance policy is assigned to it, not merely one that exists somewhere
4. 4.It has passed the evaluation
5. 5.The client actually reports the device identity at sign-in

The last point is the one that produces the surprising failures. Not every client transmits its device identity. If the chain breaks there, nothing reports “non-compliant”. No information arrives at all, and the policy blocks.

Report-only is not an intermediate step

Every access policy I build goes into report-only mode first. It is then fully evaluated and logged, but does not yet take effect.

After a few days the sign-in logs show, per sign-in, how the policy would have decided. What is interesting there is less who would have passed than who would have failed and why: the contractor with the unmanaged laptop, the Linux client in development, the conference room device nobody has thought about in a while.

That list is the actual value of the exercise. It is usually longer than expected, and every entry on it is a decision that has to be made before the policy goes live: exception, migration, or a deliberate block.

Break-glass first, not last

A Conditional Access policy can lock out every administrator at once, including the person who wrote it. This is not theoretical: all it takes is a policy requiring a device the administrator does not happen to have to hand.

That is what break-glass accounts are for. They are pure emergency accounts, tied to no person, with very long random passwords and phishing-resistant authentication. Three things matter most: there are two of them, not one. They are excluded from the policies that could lock them out. And their sign-ins raise an alert, because a sign-in with such an account is either an emergency or an incident.

An emergency access route that has never been tested is not an emergency access route. It is worth trying it once a quarter, before you need it for real for the first time.