How to require compliant devices with Conditional Access

Requiring a compliant device with Conditional Access is the policy that turns Intune from an inventory into a control: sign-ins from devices that are not enrolled, not healthy, or not encrypted are blocked (or, more usefully, limited) regardless of how good the password and MFA were. Build the Intune compliance policy first, fix the "no policy = compliant" default, then add the Conditional Access grant in report-only and read the results before enforcing.

How compliance policies, Intune, and Conditional Access fit — and the difference between compliant, hybrid joined, and app-protected — is explained in Intune compliance policies and Conditional Access. The zero-trust framing that this policy sits in is in Zero trust in Microsoft 365.

Prerequisites

Entra ID P1 and Intune Plan 1 (Business Premium, E3, E5, F-plans have both).
Conditional Access Administrator for the policy; Intune Administrator for compliance policies.
Corporate devices enrolled in Intune — via Autopilot for Windows, ABM/ADE for macOS and iOS, Android Enterprise for Android. Devices that are not enrolled will be blocked; that is the point, but count them first (Entra → Devices → All devices, filter on MDM: None).
Break-glass accounts excluded, and a decision on BYOD (enrol, app protection, or block).
An app protection policy for iOS and Android if BYOD mobile is allowed.

Steps

Progress 0/5

1.Create a compliance policy per platform↓
2.Fix the default for unassigned devices↓
3.Build the Conditional Access policy in report-only↓
4.Read the report-only results↓
5.Enforce↓

Progress is saved in this browser only.

1. Create a compliance policy per platform

Intune → Devices → Compliance → Create policy. Minimum sensible Windows policy: Require BitLocker, Require Secure Boot, Require code integrity, Minimum OS version (current minus one), Microsoft Defender Antimalware on and up to date, Real-time protection, Firewall, and — if you use Defender for Endpoint — Require the device to be at or under the machine risk score: Medium. Under Actions for noncompliance, keep Mark device noncompliant: Immediately and add Send email to end user after 1 day so people get a warning before they get blocked. Assign to All devices with a Windows-Corporate filter, per bulk-assigning Intune policies.

Repeat for macOS (FileVault, Gatekeeper, OS version), iOS/iPadOS (passcode, no jailbreak, OS version), and Android Enterprise (work profile or fully managed, encryption, Play Protect).

2. Fix the default for unassigned devices

Devices → Compliance → Compliance policy settings: Mark devices with no compliance policy assigned as: Not compliant. Leave the compliance status validity period at the default 30 days.

3. Build the Conditional Access policy in report-only

Entra → Protection → Conditional Access → New policy:

Name: CA-GRANT-CompliantDevice-AllUsers-AllApps.
Users: All users; exclude break-glass and, initially, a CA-Pilot-CompliantDevice inverse group if you want to pilot by including a group instead — pilots are easier as include.
Target resources: All cloud apps. If you must carve out an app that has no device story (an old kiosk web app), exclude it explicitly and record why.
Conditions → Device platforms: Any device is fine; if you want a phased approach, include Windows and macOS first and add mobile once the BYOD answer is settled.
Grant: Require device to be marked as compliant. Add Require Microsoft Entra hybrid joined device only if you have hybrid-joined devices that are not (yet) Intune-managed. For mobile BYOD, add Require app protection policy. Select Require one of the selected controls between the device options — and keep MFA in a separate policy so the two are ANDed.
Enable policy: Report-only.

4. Read the report-only results

A week, minimum. Sign-in logs → Conditional Access → Report-only → Failure: each row is a device that would have been blocked. Sort by user and device: unenrolled corporate laptops (enrol them), Linux (needs a decision — Intune supports Ubuntu compliance, or exclude the platform), old phones on personal Outlook without app protection (deploy the app protection policy and communicate), and service accounts signing in from servers (move to certificate-based app auth). The testing guide covers the What If tool for individual cases.

5. Enforce

Switch to On. Helpdesk needs the one-liner for the block screen: "your device isn't managed or isn't compliant — open Company Portal, check the reason, fix it or call us".

Verify

From an enrolled, compliant device: sign-in succeeds; Sign-in logs → the entry → Conditional Access shows the policy as Success, and Device info shows Compliant: True.
From an unenrolled browser session (a personal laptop, InPrivate): the block page appears with the device isn't compliant reason.
Intune → Reports → Device compliance shows the non-compliant count falling rather than a fixed population that has learned to live with it.

Roll back

Set the policy to Report-only. Users on blocked devices get in on the next sign-in. Do not loosen the compliance policies themselves as a rollback — that changes the definition of "compliant" tenant-wide and hides real problems. If one platform is the issue, exclude that platform under Device platforms while you sort it, and put a date on it.

Frequently asked questions

What happens to devices with no compliance policy assigned?

By default Intune marks devices with no compliance policy as Compliant, which silently defeats this Conditional Access control. Set 'Mark devices with no compliance policy assigned as: Not compliant' under Intune → Devices → Compliance → Compliance policy settings before you enforce, and make sure every platform you allow has a policy.

Will this block personal phones from reading email?

Yes, unless you give them another route. Personal mobile devices either enrol in Intune (MDM) to become compliant, or you add a second grant option — 'Require app protection policy' — so that Outlook mobile under an app protection policy satisfies the policy without enrolment. Most organisations do the latter for BYOD and require compliance for corporate devices.

Does requiring a compliant device replace MFA?

No. Set both, with 'Require all the selected controls'. A compliant device proves the endpoint is managed and healthy; MFA proves the person. Attackers who steal a session token from a compliant device get past device checks; attackers who phish a password get past MFA on an unmanaged device. Together they cover each other.