Most people I speak to think the work of locking down devices in Microsoft 365 is creating the Intune compliance policy. They tick the boxes — BitLocker on, minimum OS, no jailbreaks — hit Save, and walk away feeling secure.
They aren’t.
A compliance policy on its own does precisely nothing to a sign-in. It’s a label. Intune looks at a device, decides “compliant” or “not compliant”, and writes that state back to Entra ID. That’s it. Nothing is blocked. Nothing is challenged. The policy is information, not enforcement.
The enforcement lives somewhere else entirely. It lives in Conditional Access.
If you’re not wiring those two things together, you’ve done half a job. And the half you skipped is the half that actually protects the tenant.
What is an Intune compliance policy, really?
Think of a compliance policy as a health check that runs on the device and ships the verdict back to your tenant. Encrypted? Patched? Joined to your tenant? Defender running? Out comes a true/false, and Entra ID writes it onto the device record.
That verdict is now available as a signal. Anything that can read Entra signals — and Conditional Access is the big one — can use it to make access decisions.
So the compliance policy is the sensor. Conditional Access is the gate. You need both, or you have neither.
Step-by-Step: wiring compliance to Conditional Access
Portal only. No PowerShell. This is what I do on every Business Premium tenant I touch.
Fix the tenant default first
Open the Intune admin center, go to Devices > Compliance > Compliance policy settings.
Find the setting Mark devices with no compliance policy assigned as. It ships set to Compliant.
Change it to Not compliant. Save.
That one setting is the difference between “any device in my tenant counts as good” and “a device has to earn it”. You’d be amazed how many tenants I audit where this is still on the default.
Build the compliance policy
Same portal. Devices > Compliance > Policies > Create policy. Pick Windows 10 and later (start there — do iOS and Android next).
Use the settings catalog options to set sensible rules — require BitLocker, a minimum Windows build, Defender real-time protection on, Defender signatures up to date. Don’t try to be heroic on day one. Set what you can defend with a straight face. Microsoft’s own walkthrough is the canonical reference.
In Actions for noncompliance, do not leave the default of “Mark device noncompliant: 0 days”. Give yourself a grace window — 1 to 3 days — and add a Send email to end user action a day earlier. People deserve a heads-up before they’re locked out of email.
Assign to a pilot user group. Not all users. A pilot group.
Build the Conditional Access policy
Now flip over to the Entra admin center: Entra ID > Conditional Access > Policies > New policy.
Users: include your pilot group. Exclude your break-glass account. Always.
Target resources: All resources.
Grant: Require device to be marked as compliant. Save.
And here’s the critical bit — set Enable policy to Report-only. Not On. Report-only.
Users: Pilot group
Exclude: Break-glass account
Resources: All resources
Grant: Require device to be marked as compliant
Enable: Report-onlyNotice what’s missing? MFA. That belongs in a separate policy. One policy, one job. Stack them, don’t fuse them.
Watch report-only for a week
Sign-in logs > Report-only tab. You’re looking for users who would have been blocked and shouldn’t have been — usually a missing enrollment, a personal device that needs the App Protection path instead, or a service account.
When the report-only data is clean, flip the toggle to On. Microsoft’s compliant-device CA template walks the same path.
Why this actually changes behaviour
“But MFA is already on. Isn’t that enough?”
It isn’t. MFA proves the user. Compliance + CA proves the device. Token theft doesn’t care about your MFA prompt — it cares whether the device the token landed on is one you trust. This is the bit MFA-only tenants are missing.
It also collapses three messy conversations down to one. “Is this laptop ours? Is it patched? Is it encrypted?” All of it rolls into one signal — compliant, or not. Conditional Access reads that one signal and decides. No more inventory spreadsheets. No more guessing.
And if you’re an MSP, this is the most defensible artefact you can show a client during an incident. The device was non-compliant. Access was blocked. That’s a finished sentence.
A compliance policy isn’t there to make a list of bad devices. It’s there to make sure they never sign in.
CIAOPS 