Require compliant devices for Microsoft 365 with Conditional Access

To restrict Microsoft 365 to managed devices, create Intune compliance policies for each platform, set the tenant-wide Mark devices with no compliance policy assigned as option to Not compliant, and then create a Conditional Access policy for all users and all resources with the grant control Require device to be marked as compliant. Run that policy in report-only mode until the sign-in logs show your real devices reporting compliant, exclude your break-glass accounts and directory synchronization accounts, and only then switch it on.

Who this is for and what you will have at the end

This guide is for Microsoft 365 and Intune administrators who want email, files and Teams available only on devices the organization manages and trusts. It assumes devices are, or will be, enrolled in Intune.

At the end you will have:

• Tenant-wide compliance settings that don't treat unmanaged or unassigned devices as compliant.
• Compliance policies for Windows and iOS/iPadOS with sensible starter settings and a grace period.
• A Conditional Access policy that requires a compliant device, validated in report-only mode.
• Browser configuration that lets Edge, Chrome and Safari pass the device check.
• A troubleshooting table for the errors users actually hit.

Device compliance is one control in a broader Zero Trust design. For the architecture around it, see Zero Trust enterprise remote access architecture.

How compliance reaches Conditional Access

The chain has three links, and each one can break independently:

1. Registration. When a device enrolls in Intune, it registers in Microsoft Entra ID. A device must be registered before it can be marked compliant.
2. Compliance evaluation. Intune evaluates the device against its assigned compliance policies at check-in and reports the result to Microsoft Entra ID, where it appears as the device's isCompliant property.
3. Policy enforcement. At sign-in, Conditional Access reads the device identity presented by the client and grants or blocks access based on that compliance state.

The Require device to be marked as compliant control supports Windows 10 and later, iOS, Android, macOS and Linux Ubuntu devices that are registered with Microsoft Entra ID and enrolled in Intune. Non-Microsoft MDM systems can mark Windows devices compliant through the compliance partner integration. Microsoft Edge in InPrivate mode on Windows is always treated as noncompliant.

If your Windows estate is domain joined, hybrid join is how those devices get a Microsoft Entra identity in the first place; troubleshooting hybrid join with dsregcmd covers devices that fail that step.

Prerequisites

• Licensing: a Microsoft Intune subscription, and Microsoft Entra ID P1 or P2 for Conditional Access.
• Roles: an Intune administrator role to create compliance policies, and at least Conditional Access Administrator for the policy.
• Enrollment: devices enrolled in Intune, either to one user or without a primary user. Enrollment is required to see compliance status.
• Emergency access accounts: at least one cloud-only break-glass account you will exclude from the policy.
• Legacy authentication: blocked, or handled separately. Legacy clients don't pass device state, so a compliant device requirement blocks them.

Step 1: Set the tenant-wide compliance policy settings

These settings act like a built-in policy that every device receives.

1. Sign in to the Microsoft Intune admin center.
2. Go to Endpoint security > Device compliance > Compliance policy settings.
3. Set Mark devices with no compliance policy assigned as to Not compliant. The default is Compliant, which means a device that never receives a policy is considered compliant and would pass your Conditional Access check.
4. Review Compliance status validity period (days). A device that doesn't report compliance for all its policies within this period is treated as noncompliant. The default is 30 days and the allowed range is 1 to 120.

Change step 3 before you enforce Conditional Access, and make sure every enrolled device has at least one compliance policy assigned. Users who aren't assigned a policy see "No compliance policies have been assigned" in the Company Portal app and are treated as noncompliant.

Step 2: Create compliance policies per platform

Each platform needs its own policy.

1. In the Intune admin center, go to Devices, then under Manage devices select Compliance > Create policy.
2. Select the Platform, for example Windows 10 and later or iOS/iPadOS, and select Create.
3. On Basics, give the policy a descriptive name.
4. On Compliance settings, configure the rules.
5. On Actions for noncompliance, review the schedule.
6. On Assignments, assign the policy to user or device groups, then Review + create.

Windows starter settings

iOS/iPadOS starter settings

Start with settings users can fix themselves. Requirements like encryption on Windows are "quarantined" rather than remediated, meaning the operating system doesn't fix the setting for the user; if a Conditional Access policy applies, the device is blocked and the Company Portal tells the user what's wrong.

Actions for noncompliance and the grace period

Every policy includes the default action Mark device noncompliant. You can schedule it to run after a number of days, which gives users a grace period, and add actions such as emailing the user. While the scheduled date is in the future the device reports InGracePeriod instead of NonCompliant. If a device has several policies, the most severe status wins, in this order from least to most severe: Unknown, NotApplicable, Compliant, InGracePeriod, NonCompliant, Error.

Step 3: Confirm devices report compliant

Before you touch Conditional Access, make sure real devices show Compliant in Intune. Compliance is evaluated when a device checks in; a user can force a check-in by syncing from the Company Portal app. Supported Windows devices also request re-evaluation when monitored settings such as firewall, antivirus, BitLocker, Defender status, OS build, real-time protection or Secure Boot change.

You can also check the state Conditional Access will see in Microsoft Entra ID:

Connect-MgGraph -Scopes "Device.Read.All"
 
Get-MgDevice -All -Property "displayName,operatingSystem,trustType,isManaged,isCompliant" |
    Group-Object OperatingSystem, IsCompliant |
    Select-Object Name, Count

isCompliant and isManaged can only be set by Intune, or by an approved MDM app for Windows. Devices registered in Microsoft Entra ID but never enrolled show up here without a compliance value and will fail the policy.

Step 4: Create the Conditional Access policy

1. Sign in to the Microsoft Entra admin center as at least a Conditional Access Administrator.
2. Browse to Entra ID > Conditional Access > Policies and select New policy.
3. Give the policy a name that follows your naming standard.
4. Under Assignments > Users or workload identities:
   • Include: All users.
   • Exclude: Users and groups, then your emergency access accounts. If you use Microsoft Entra Connect or Cloud Sync, also select Directory roles > Directory Synchronization Accounts.
5. Under Target resources > Resources (formerly cloud apps) > Include, select All resources (formerly 'All cloud apps').
6. Under Access controls > Grant, select Require device to be marked as compliant, then Select.
7. Set Enable policy to Report-only and select Create.

After reviewing results with policy impact or report-only mode, change Enable policy to On.

Two documented exceptions are worth knowing before you enforce:

• If you use Windows Subscription Activation to step devices up from one Windows edition to another, consider excluding the Windows Store for Business app (AppID 45a330b1-b1ec-4cc1-9161-9f03992aa49f) from this policy.
• The device-code OAuth flow can't carry device state, so device-based grant controls aren't supported with it. Use Require multifactor authentication for those scenarios.

Companion policies

Device platform detection uses information such as the user agent, which can be spoofed. Microsoft recommends pairing compliance with a policy that blocks unknown or unsupported device platforms: include any device, exclude the supported platforms, and grant Block access. If you aren't ready to require compliance for everyone, Microsoft documents alternative baselines such as requiring a compliant or hybrid joined device for administrators, or a compliant device, hybrid joined device or MFA for all users.

Step 5: Make browsers pass the device check

Users on compliant devices still fail if the browser can't present the device identity. Supported combinations include:

The device check fails in private browsing or with cookies disabled. Browser-specific requirements:

• Microsoft Edge: the user must be signed in to the browser profile. This sign-in might not happen automatically on hybrid joined devices.
• Chrome on Windows: install the Microsoft Single Sign On extension or enable the CloudAPAuthEnabled policy (Chrome 111 and later).
• Firefox on Windows: enable "Allow Windows single sign-on for Microsoft, work, and school accounts".
• iOS and macOS: devices are identified by a client certificate provisioned at registration, so users see a certificate prompt the first time. As device identity keys move to Apple Secure Enclave, apps that don't use MSAL, including Safari, need the Microsoft Enterprise SSO plug-in enabled.

To enable CloudAPAuthEnabled for Chrome on Windows through the registry:

Path:  HKEY_LOCAL_MACHINE\Software\Policies\Google\Chrome
Name:  CloudAPAuthEnabled
Type:  DWORD
Value: 0x00000001

Verify the policy

• In Entra ID > Monitoring & health > Sign-in logs, open a sign-in and check the Report-only or Conditional Access tab for your policy and its result.
• Test from one enrolled, compliant device and one unenrolled device per platform before switching to On.
• Watch the Intune device compliance dashboard for devices that stay in grace period or report an unknown or error status before the grace period ends.

Troubleshooting

Checklist

• Mark devices with no compliance policy assigned as set to Not compliant; validity period reviewed.
• One compliance policy per platform, assigned to every enrolled user or device, with a grace period on Mark device noncompliant.
• Devices showing Compliant in Intune and isCompliant true in Microsoft Entra ID.
• Conditional Access policy for all users and all resources with Require device to be marked as compliant, excluding break-glass and directory synchronization accounts.
• Policy validated in report-only mode, then turned on.
• A block policy for unknown or unsupported platforms.
• Browsers configured: Edge profile sign-in, Chrome extension or CloudAPAuthEnabled, Enterprise SSO plug-in on Apple devices.

Compliance stops access from unmanaged devices, but a token stolen from a compliant device can still be replayed elsewhere. Conditional Access token protection closes that gap for supported apps.

References

• Require device compliance with Conditional Access
• Configure grant controls in Conditional Access
• Conditions in Conditional Access policies (supported browsers)
• Device compliance policies in Microsoft Intune
• Create device compliance policies in Microsoft Intune
• Windows compliance settings in Microsoft Intune
• iOS/iPadOS device compliance settings in Microsoft Intune
• Microsoft Entra authentication and authorization error codes
• device resource type