Conditional Access¶

Intune decides whether a device is compliant or an app is protected. Conditional Access, a Microsoft Entra ID feature, decides what to do with that at sign-in: allow, require more, or block. Without Conditional Access, compliance is just a report.

You can build policies in the Entra admin center (Entra ID > Conditional Access) or from Endpoint security > Conditional access in Intune. They're the same policies. Conditional Access needs Microsoft Entra ID P1.

How the signals flow¶

sequenceDiagram
    participant D as Device
    participant I as Intune
    participant E as Entra ID
    participant A as Microsoft 365 app
    D->>I: Check in, report settings
    I->>I: Evaluate compliance policies
    I->>E: Write isCompliant on the device object
    D->>E: User signs in (device identity in the token request)
    E->>E: Evaluate Conditional Access
    E-->>D: Token issued, or blocked with a reason
    D->>A: Access with token

The device has to prove its identity during sign-in. Native apps do this through the platform's authentication broker. Browsers need a little help (see Browsers).

A baseline policy set¶

Most enterprises end up with something like this. Build each one in report-only mode first.

Microsoft publishes these as Conditional Access templates in the Entra admin center, which is a quick way to start.

Exclusions you need¶

Every policy needs a deliberate, documented exclusion list:

• Emergency access (break-glass) accounts: excluded from everything, monitored with alerts on every sign-in.
• Directory synchronization accounts: if you use Entra Connect or Cloud Sync, exclude the Directory Synchronization Accounts role from device-based policies.
• Service accounts: better replaced with managed identities or workload identities. Policies for users don't apply to service principals anyway.
• Windows subscription activation: if you use subscription activation to step up Windows editions, exclude the Universal Store Service APIs and Web Application app (45a330b1-b1ec-4cc1-9161-9f03992aa49f) from device compliance policies.
• Android corporate enrollment: exclude the Microsoft Intune cloud app from any policy that requires compliance (or blocks) for Android and browsers. Corporate Android setup signs in through a Chrome tab. See Android devices.

Mobile app access¶

On June 30, 2026, the Require approved client app grant became read-only. You can't create new policies with it or edit existing ones that use it (you can still disable or delete them). Existing enabled policies keep being enforced.

What to do:

• Build new mobile policies with Require app protection policy only.
• For existing policies, create a replacement that uses Require app protection policy, test it in report-only mode, then switch over and retire the old one.
• Make sure your app protection policies cover every app users need. Apps that don't support app protection are blocked by this grant.
• Assign app protection policies before you turn on the Conditional Access policy, so users aren't blocked while policy reaches their apps.

On Windows, Require app protection policy works with Microsoft Edge for personal devices that aren't enrolled. Target it carefully: the grant can't be met on devices that are enrolled in Intune, so combine it with Require compliant device (require one of the selected controls) or scope it to unmanaged devices.

Browsers¶

Device-based policies need the browser to pass the device's identity:

Deploy the Chrome policy or extension with Intune (settings catalog has Chrome ADMX settings, or set HKLM\Software\Policies\Google\Chrome\CloudAPAuthEnabled to 1).

Using device filters¶

Conditional Access has its own filter for devices condition, separate from Intune assignment filters. It uses properties like device.isCompliant, device.manufacturer, device.model, device.enrollmentProfileName and extension attributes. Common uses:

• Apply stricter policies to privileged access workstations: device.extensionAttribute1 -eq "PAW".
• Exclude a specific kiosk or shared-device model from a user-interactive policy.

Rolling out safely¶

1. Report-only first. Leave new policies in report-only for at least a week. Use the Conditional Access insights and reporting workbook to see who would be blocked.
2. Use the What If tool to test specific users, devices and apps before you turn a policy on.
3. Fix noncompliance before enforcement. Check the Intune compliance reports so you aren't about to block a third of the company.
4. Pilot with a group, then expand to all users.
5. Communicate. Users who are blocked see a message; tell them in advance what to do (usually open Company Portal and select Check status).

Troubleshooting a block¶

1. In the Entra admin center, open Sign-in logs, find the failed sign-in and check the Conditional Access tab to see which policy applied and which grant failed.
2. On the Device info tab, check whether the device was identified at all. A blank device ID usually means a browser problem, not a compliance problem.
3. In Intune, check the device's compliance status and which setting fails.
4. Check the timing: a device that just became compliant can take a little while for Entra ID to reflect it.

Remember that the device code sign-in flow can't satisfy device-based grants. Use MFA for those scenarios.

Learn more¶

• Conditional Access and Intune
• Require device compliance with Conditional Access
• Migrate approved client app to app protection policy
• Conditional Access conditions, including supported browsers