Intune Compliance Policies for Conditional Access

Conditional Access can check who the user is and whether they passed MFA, but on its own it has no idea whether the device in their hands is patched, encrypted, or jailbroken. That signal comes from somewhere else. Intune compliance policies are what produce it: they evaluate each enrolled device against a set of rules, stamp it compliant or not, and feed that verdict back to Entra ID so Conditional Access can act on it. This post covers building that pipeline so only healthy devices reach Microsoft 365.

Key Takeaways

• Intune compliance policies evaluate device health and write a compliant or non-compliant state onto the Entra ID device record.
• Conditional Access consumes that state through the Require device to be marked as compliant grant control — the two features are designed to work as a pair.
• A device must be enrolled in Intune and registered in Entra ID for compliance to mean anything; an unmanaged device has no compliance state to check.
• The tenant setting that marks devices with no policy as compliant or non-compliant decides your default posture, and the secure default is non-compliant.
• Non-compliance actions let you warn users and give a grace period before access is actually blocked, which keeps a tightening rollout from locking people out overnight.

Environment

• Microsoft Intune (Plan 1) with Windows, iOS/iPadOS, Android, or macOS devices enrolled.
• Entra ID P1 or higher for Conditional Access.
• Devices that are Entra joined, hybrid joined, or registered, with the Company Portal where the platform requires it.
• Optional: Microsoft Defender for Endpoint for the machine-risk compliance signal.

The Problem

A Conditional Access policy that only requires MFA treats a fully patched, BitLocker-encrypted corporate laptop exactly the same as a five-year-old personal machine with no encryption and a disabled antivirus. Both pass MFA, both get a token. From a device-hygiene perspective that is a gap, and it is the gap compliance policies exist to close.

The mistake I see most often is people writing the compliance rules and then assuming Conditional Access enforces them automatically. It does not. Compliance evaluation and access enforcement are two separate engines. Intune decides whether a device is compliant; Conditional Access decides whether to care. If you never build the matching Conditional Access policy, you end up with a tidy compliance dashboard that blocks precisely nobody.

The Solution

Step 1 — Set the default compliance posture for unassigned devices

Before writing any policy, decide what a device with no compliance policy assigned should be treated as. In the Intune admin center, go to Devices → Compliance → Compliance policy settings and look at Mark devices with no compliance policy assigned as. The secure choice is Not compliant. That way a device only becomes compliant by actively passing a policy, rather than being assumed healthy until proven otherwise.

Flip this carefully on an existing tenant. If you switch it to "Not compliant" while a Conditional Access policy already requires compliance, every device that has not yet been assigned a policy will be blocked at once. Stage the compliance policies first, confirm devices are evaluating, then tighten the default.

Step 2 — Build a compliance policy per platform

Compliance rules are platform-specific, so create one policy per operating system under Devices → Compliance → Create policy. For Windows, the rules worth turning on first:

• Require BitLocker and Require Secure Boot — basic device-integrity signals that are cheap to enforce on modern hardware.
• Minimum OS version — keeps end-of-life builds out. Set it to a real, current build number rather than something symbolic.
• Microsoft Defender Antimalware and a minimum signature version — confirms protection is actually running and current.
• Require a password to unlock with a minimum length and complexity.
• Machine risk score from Defender for Endpoint, if you have it — this is where compliance stops being static and starts reflecting live threat signals.

Set the platform's minimum OS version against the genuinely supported builds — the same discipline applies to Windows servicing that I touched on when managing rotating secrets with Conditional Access policies for Microsoft 365, where stale clients are a recurring source of false blocks.

Step 3 — Configure the non-compliance actions

Every compliance policy has an Actions for noncompliance section, and the default is a single immediate "mark non-compliant" action. That is harsher than it needs to be for a rollout. Add a staged sequence instead:

• Send an email to the end user on day zero, explaining what failed and how to fix it. Customise the notification so it does not read like a phishing test.
• Mark the device non-compliant after a grace period of, say, three to seven days, so users have a window to remediate before they lose access.
• Optionally remotely lock or retire for the platforms and risk levels where that is warranted.

The grace period is the difference between a rollout people barely notice and a flood of helpdesk tickets the next morning. Use it.

Step 4 — Wire compliance into Conditional Access

This is the step that makes compliance actually do something. In Entra ID, go to Protection → Conditional Access and create a policy targeting the users and cloud apps you want to protect. Under Grant, select Require device to be marked as compliant. Now a device's Intune compliance verdict is a precondition for the token.

Assignments
  Users:         All users (exclude break-glass accounts)
  Target:        All cloud apps  (or start with Office 365)
  Conditions:    Device platforms = Windows, iOS, Android, macOS

Access controls
  Grant:         Require device to be marked as compliant
  Enable policy: Report-only  ->  On (after validation)

Always start in Report-only mode. The Conditional Access sign-in logs will show you exactly who would have been blocked, including the service accounts and unmanaged devices you forgot about, before anyone is actually denied. And always exclude your break-glass emergency access accounts from any policy that could lock out administrators. Microsoft's own guidance on this lives in the Intune device compliance Conditional Access documentation.

Step 5 — Validate with the sign-in logs

After a day or two in report-only, review Entra ID → Monitoring → Sign-in logs and open the Conditional Access tab on individual sign-ins. Each entry shows which policies applied and whether the compliance grant was satisfied. This is the same log surface I leaned on for Entra ID password spray detection, and it is where you confirm the policy behaves before flipping it on. When the report-only results look right and the expected exclusions are holding, switch the policy to On.

Frequently Asked Questions

Do I need Entra ID P1 for device compliance Conditional Access?

Yes. Compliance evaluation is an Intune feature, but the Conditional Access policy that enforces it requires Entra ID P1 or higher. Without Conditional Access, a non-compliant device is flagged but never actually blocked from anything.

What happens to a device that has no compliance policy assigned?

It takes whatever the tenant default is. If "Mark devices with no compliance policy assigned as" is set to Not compliant, that device is treated as non-compliant and a compliance-requiring Conditional Access policy will block it. This is why you stage policies before tightening the default.

Can I require compliance without Microsoft Defender for Endpoint?

Yes. The core rules — encryption, OS version, Secure Boot, password, built-in antimalware — need no extra products. Defender for Endpoint only adds the machine-risk-score rule, which is a strong signal but optional.

Why is a compliant device still being blocked?

Usually a timing or registration issue: the device has not finished its compliance check-in, the Entra device record has not received the updated state yet, or the device is registered but not the same object Conditional Access is evaluating. The sign-in log's Conditional Access detail tells you which condition failed.

Should personal (BYOD) devices be in scope?

It depends on your model. Compliance works on registered BYOD devices, but the rules and the user experience differ from corporate-owned hardware. Many environments use app protection policies for BYOD and reserve device-compliance enforcement for managed devices. Decide deliberately rather than scoping "all devices" by accident.

Conclusion

Intune compliance policies and Conditional Access are two halves of one control. Compliance produces the device-health verdict; Conditional Access enforces it. Neither does much on its own, which is exactly why the most common failure mode is building one and forgetting the other.

Get the order right and the rollout is undramatic: stage the per-platform policies, give users a grace period to remediate, validate in report-only, then enforce. The payoff is that device health becomes a real precondition for access rather than a dashboard nobody reads — and the unmanaged, unencrypted, end-of-life machines stop quietly reaching your data.

Related Posts

• Essential Conditional Access Policies for Microsoft 365 — the baseline policies this compliance grant slots into.
• Entra ID Password Spray Detection with Sign-In Logs — using the same sign-in log surface for detection.
• Migrating AzureAD and MSOnline PowerShell to Microsoft Graph — for scripting the Entra side of this with the supported module.

Editorial note: posts on this blog are drafted with AI assistance and then reviewed, edited, and tested against a real environment before publishing. Commands, output, and screenshots come from systems I actually ran the work on.