Lowering the bar: forging a compliant device past Conditional Access

Conditional Access grants device-based trust to devices Intune reports as compliant, so compliant is a security decision, not just a label. The attack is to make the policy lie.

How the attack works

An attacker with Intune policy-edit rights loosens a device compliance policy, removing requirements such as encryption and a minimum OS version, so a wider set of devices counts as compliant. The relaxed policy is assigned and the fleet re-evaluates, flipping previously non-compliant devices to compliant. An attacker-controlled enrolled device now reports compliant against the loosened bar, and Entra Conditional Access grants it access to corporate resources using the require-compliant-device grant. This maps to T1484, Domain or Tenant Policy Modification, and T1562, Impair Defenses.

Why it works

The device did not get better, the bar got lower. Conditional Access trusts the compliance signal, so once the policy lies, every device the loosened policy falsely clears is trusted along with the rogue one.

How to fix it

Do not chase the single device. Revert the compliance policy to its known-good baseline and force a fleet-wide compliance re-evaluation so every device is judged against the real bar again, dropping the falsely cleared devices back to non-compliant. For the lasting fix, restrict who can edit compliance policies and baselines, require change approval, and alert on every compliance-policy edit, the same way you would guard a firewall rule. Scope impact from the Intune audit log edit joined to the Entra sign-in logs for compliant-device grants during the loosened window.

Practice it

We built this as a GraphLattice Range scenario so administrators learn that the policy, not the device, is the vulnerability to contain.