Require a compliant device to access Microsoft 365

Requiring MFA proves who is signing in, but not from what device. A password and an MFA code can pass through an unencrypted machine with no antivirus, or even one already compromised by malware. The identity is verified, but the endpoint handling your data remains an unknown. Requiring a compliant device closes exactly that gap: only healthy, enrolled and managed devices reach your Microsoft 365 data.

It is a foundational building block of Zero Trust: never trust the device by default, but verify its health at every access attempt. This requirement naturally complements MFA, which protects the identity but completely ignores the endpoint being used. Together they answer two distinct questions: 'who is signing in?' and 'from which trusted device?'.

In this article you will see how the 'require compliant device' grant control works, what an Intune compliance policy actually checks, the enrollment prerequisite, the real user experience, and the method to roll out the rule without accidentally locking out your whole organization.

Compliant or hybrid Entra-joined: two options

Within the Conditional Access grant controls, Microsoft offers two device-related requirements. You can combine them with the 'require one of the selected controls' option to cover heterogeneous fleets, or enforce just one if your estate is homogeneous.

• Compliant device: the device is enrolled in Intune and meets the compliance policy you have defined.
• Hybrid Entra-joined device: the device is joined to both your on-prem Active Directory and Entra ID, typically through existing synchronization.
• The compliant option covers Windows, macOS, iOS and Android; the hybrid option mainly fits domain-joined Windows PCs.
• For most modern SMBs, requiring a compliant device via Intune is the simplest, broadest and most future-proof choice.

When to prefer the compliant device

If your organization already manages its PCs and mobiles with Intune, requiring a compliant device is the obvious choice. It applies to every operating system, does not depend on a local Active Directory domain, and relies on health criteria you control precisely. It is also the recommended path for cloud-first environments without an AD server.

When hybrid join still makes sense

Hybrid Entra join still makes sense for businesses that keep a local Active Directory and domain-joined Windows PCs while migrating toward the cloud. Nothing stops you from combining both requirements during the transition, then switching to compliant-device-only once the fleet is fully enrolled in Intune.

What an Intune compliance policy checks

A device is only declared 'compliant' if it meets the criteria you have defined in an Intune compliance policy. That policy is what gives the requirement meaning: without it, the grant control would have no criteria to evaluate and would consider the device compliant by default. The policy and the access control are therefore an inseparable pair.

• Disk encryption enabled: BitLocker on Windows, FileVault on macOS, native encryption required on mobile.
• Minimum operating system version, ensuring recent security patches are applied.
• Active antivirus with real-time protection: Microsoft Defender or a recognized third-party solution.
• Lock code or password required, with a minimum length and complexity.
• Jailbreak detection (iOS) or root detection (Android): a tampered device is immediately marked non-compliant.
• No active threat reported by Microsoft Defender for Endpoint, if you connect threat protection.

Each unmet criterion can be configured to mark the device non-compliant, either immediately or after a grace period. It is this status, reported continuously to Entra ID, that Conditional Access evaluates at every sign-in.

The often-forgotten prerequisite: enrollment

Before a device can be 'compliant', it must first be enrolled in Intune and registered in Entra ID. This is the most underestimated prerequisite. A device unknown to Intune has no compliance status at all: it will therefore be blocked by the rule, even if it is perfectly encrypted and up to date. Enrollment is not a formality, it is the gateway of the whole mechanism.

Common enrollment paths

• Windows Autopilot to provision new Windows PCs from their very first boot.
• Automatic enrollment through the Company Portal app on mobile and macOS.
• Apple Business Manager and Android Enterprise for large-scale, hands-off enrollment.
• Manual user enrollment, guided by a clear internal procedure for existing devices.

Anticipate the user experience

This rule changes your users' daily routine: a non-compliant or unenrolled device will simply be blocked at sign-in. The user sees an Entra ID message prompting them to enroll or bring their device into compliance, often with a link to the Company Portal. Without preparation, that message generates confusion and a flood of support tickets.

The grace period is your best ally. A compliance policy can mark a device non-compliant immediately or give it a defined number of days to fix itself. This reprieve avoids abruptly blocking an employee whose device needs, for example, to install an operating system update or turn on encryption.

Common mistakes to avoid

• Turning the rule on in enforced mode before enrolling and evaluating the fleet: mass lockout guaranteed.
• Forgetting to exclude service accounts or devices that cannot be enrolled.
• Not planning a grace period, which turns the smallest update into a blocking incident.
• Not communicating ahead of time: the user discovers the block without knowing what to do.
• Confusing 'registered device' with 'compliant device': only the latter satisfies the grant control.

Roll out without locking out your teams

Like any sensitive Conditional Access rule, this one must be tested before being enforced. Report-only mode applies the rule's logic without actually blocking anyone: the sign-in logs show you who would have been allowed, blocked, or subject to an extra control. This lets you measure the real impact before switching to enforced mode.

1. 1Create and assign an Intune compliance policy tailored to each platform in your fleet.
2. 2Enroll the devices and let Intune evaluate their compliance for a few days.
3. 3Create the Conditional Access policy requiring a compliant device, in report-only mode.
4. 4Always exclude a break-glass emergency account from the policy.
5. 5Analyze the report-only logs to spot the users who would be blocked.
6. 6Communicate the enrollment procedure and set a reasonable grace period.
7. 7Switch the policy to enforced mode once the impact is under control, then keep monitoring sign-ins.

A poorly scoped Conditional Access rule can lock an administrator out of their own tenant. The break-glass account is your indispensable safety net.

The break-glass account deserves special attention. It is an emergency account with a long password stored offline in a safe place, excluded from your strictest Conditional Access policies. If a misconfigured rule blocks everyone, this account remains your only way to regain control of the tenant. Never leave it out of your exclusions.

A pillar of your regulatory compliance

Requiring a compliant device ties data access directly to the security state of the endpoint. That is exactly what frameworks like ISO 27001 or the NIS2 directive expect: documented endpoint management, with encryption, patches and antivirus verified continuously rather than declared once and forgotten.

• You ensure only encrypted devices reach personal data, a strong argument under GDPR.
• You demonstrate a continuous, automated evaluation of endpoint health.
• You bind identity and device, two complementary pillars of the Zero Trust model.
• You have usable audit logs to prove the control is effective.

FAQ

Do I absolutely need Intune to require a compliant device?

Yes, for the 'compliant device' requirement. Intune is what evaluates the health criteria and reports the compliance status to Entra ID. The 'hybrid Entra-joined device' requirement does not depend on Intune but requires a local Active Directory synchronized with Entra ID.

What happens to an unenrolled personal device?

An unenrolled personal device has no compliance status and will be blocked by the rule. To allow remote work from personal devices, you can either invite the user to enroll them, or favor app protection policies (APP) over the compliant device requirement, depending on your BYOD policy.

Does report-only mode really block no one?

No. Report-only mode evaluates the rule and records it in the sign-in logs, but applies no block. It is the ideal tool to measure a policy's impact before actually turning it on, with no risk to production.

AuPoint pairs the compliance policy with Conditional Access in a guided flow, in plain language and with no PowerShell. The platform previews who would be affected, automatically applies report-only mode and the break-glass exclusion, then walks you through to enforcement. You lock access to healthy devices in a few clicks, with no consultant and no nasty surprises. See how AuPoint secures your Microsoft 365 at aupoint.io.