Microsoft Security Without a Rulebook: The Problem with “Require Compliant Device”

Microsoft is increasingly making security‑critical decisions on behalf of organizations and not through policy, but through defaults. The “Require compliant device or hybrid-joined device” Conditional Access template is one of the clearest examples of security without a rulebook.

The no-brainer policy that gets complicated fast

Microsoft’s Require compliant or hybrid-joined device Conditional Access (CA) template seems like a no brainer that everyone can agree upon. If the device is not known, managed, and healthy, it should not be reaching corporate data. In practice, this is exactly the kind of policy that reminds me why enterprise IT is still more art than science, because the moment you try to apply it broadly, you’ll discover just how hard the pushback is.

The friction starts with virtual desktops, BYOD user privacy concerns, onboarding flows, licensing, and more. This is where the real judgement calls begin.

The promise of the template

Microsoft positions device-based Conditional Access as a way to require a compliant or hybrid-joined device before access is granted, and the published templates make that easier to deploy for broad user populations or for privileged roles. The underlying logic is sound: stolen credentials are less useful if the attacker is not signing in from a device your organization trusts.

The catch is that this template assumes a lot. It assumes you have:

• device management in place
• compliance policies that reflect reality
• stable registration and onboarding flows
• enough licensing to put every intended user in scope

In many tenants, those assumptions are not false so much as incomplete.

Virtual desktops are often the first collision

Decision checkpoint: Can your trusted desktop model actually register as trusted?

Decision checkpoint: If your virtual desktop platform is business-critical but cannot reliably satisfy device compliance signals, you need to decide whether to redesign the workspace, carve out a narrow exception, or accept that your strongest-looking policy may exclude one of your most important environments.

One of the most common reasons organizations cannot apply this policy broadly is that their virtual desktop environment does not present to Entra and Intune the way a modern managed endpoint does. A multi-session or pooled Windows host may be absolutely central to the business and still fail the practical test of being “compliant” in a way Conditional Access can use consistently.

That is how teams end up in a strange place: the most corporate device in the environment is the very device blocked by the policy. One admin on Reddit described it bluntly: “We have CA set to require MFA and compliant device, but our hybrid-joined multi-session VMs don’t show as compliant so users can’t log in.” Device filters come to the rescue here but it’s often not the first thought that comes into an admins mind.

BYOD changes the political equation

Decision checkpoint: Are you enforcing device trust or negotiating user consent?

Decision checkpoint: If personal devices are part of the operating model, then requiring compliance is no longer just a security control. It becomes a question of what level of corporate management users will tolerate, and how much risk you are willing to retain when they will not.

The second collision is cultural. If users depend on personal phones and tablets, a pure compliant-device posture often means asking them to accept corporate management on devices they consider private.

An admin in plain language also on Reddit said: “We have a lot of users on personal iOS/Android, they’re not going to enroll just to read mail.”

The usual compromise is some variation of MFA-or-compliant-device rather than compliant-device-only. That is not a perfect Zero Trust story, but it is a recognizable one where one policy turns into two or three.

Onboarding exposes the policy’s blind spot

Decision checkpoint: Can a new user reach the tools needed to become compliant?

Decision checkpoint: Before you enforce a compliant-device requirement, make sure first-use enrollment, MFA registration, and recovery flows can still function. Otherwise, the control will block the very steps users need to satisfy it.

Then there is the day-one problem. Conditional Access can demand a compliant device or MFA before access is granted, but users often need access first in order to become compliant, enroll, and set up their authentication methods.

As one admin put it, “New users can’t enroll because CA wants MFA, but they can’t get MFA set up until they enroll. It’s a chicken and egg.”  Microsoft seems to have done some magic behind the scenes to work around this plague.

Licensing is a strategy problem, not just a procurement one

Decision checkpoint: Which users are strategic enough to justify full device governance?

Decision checkpoint: If licensing costs prevent universal coverage, then this is not just a procurement issue. It is a governance choice about which identities receive stronger protection, which do not, and whether leadership is comfortable with the security tiers that creates.

Device-based Conditional Access also exposes a licensing reality that many teams would prefer not to examine too closely. It becomes painful when you try to apply the policy to seasonal staff, frontline workers, or guest populations. I’ve heard this complaint more than once: “We can’t justify P1+Intune for every part-timer who checks email twice a week.”

The compromise is usually a tiered model. Knowledge workers, managers, and admins get the compliant-device requirement, while other populations stay on MFA-only access or lighter controls.

When I think about this template, I picture the conversations administrators have on lunch break.

“Require compliant device is driving me insane.”

Template promise	Real-world blocker	Typical compromise pattern	Risk if it becomes permanent
All users must sign in from compliant or hybrid-joined devices for all cloud apps	VDI and multi-session hosts are hybrid/domain-joined but not enrolled in Intune or marked compliant; changing that often requires redesigning the virtual workspace.	Create a separate MFA-only Conditional Access policy for VDI and exclude those hosts from the compliant-device policy.	Critical workloads remain accessible from less-governed hosts, while leadership may wrongly assume the tenant is uniformly protected.
All users on all devices must be compliant to access corporate data	BYOD culture and user resistance to full MDM on personal phones, especially among field staff and executives.	Implement MFA-or-compliant rules so unmanaged devices can still connect, often with browser-only access or extra session controls for sensitive apps.	Unmanaged personal devices become a durable access path into core services, and the softer path is hard to retire once users normalize it.
New hires and reimaged devices should be compliant from day one	Enrollment deadlock: users need access to enrollment portals and MFA setup before they can satisfy the policy.	Create an onboarding policy or temporary exception group that relaxes requirements for registration and enrollment flows.	The onboarding bubble becomes a standing exception that is rarely reviewed and may offer an attractive path for abuse. Time to modernize this policy to reflect the improved workflow Microsoft has created.
Every user governed by Conditional Access is properly licensed	Cost and SKU complexity for frontline, seasonal, guest, and low-use accounts make universal scoping unattractive.	Scope the compliant-device policy to office workers, managers, and admins, while other populations remain on MFA-only or lighter controls.	A two-tier security posture develops inside the same tenant, with weaker controls on large populations that may still touch important data.
Exceptions stay narrow and tightly governed	Business exceptions do not scale neatly; modeling every combination of app, user, and device quickly becomes unmanageable.	Build coarse “exception groups” for users or devices that bypass multiple controls at once because it is operationally simpler.	Exception groups evolve into a shadow perimeter with broad unplanned access that is difficult to explain in an audit or an incident review.
Administrative and emergency access should also come only from compliant devices	Break-glass accounts and some admin workflows and service accounts, need to function during outages, including scenarios where normal compliance checks or MFA dependencies are unavailable.	Exclude break-glass accounts and sometimes specific admin workflows from the compliant-device policy, compensating with monitoring and very strict operational controls.	Powerful identities operate outside the primary Zero Trust control plane, and convenience can slowly widen the scope of who is allowed to use them.

A destination, not a switch

I don’t think this template is too aggressive. I think it is clarifying. It forces organizations to answer a question many would prefer to postpone: do we actually trust unmanaged, weakly governed, or operationally mysterious devices to reach the systems that matter most?

What I would not do is treat this template as a binary switch that is either fully on or fully off. In a mature environment, requiring a compliant device is a destination, not a starting point. The real work is deciding which exceptions are temporary, which are politically convenient, and which are simply design debt with a more respectable name.

That is why ‘Report-only’ mode remains so valuable. It gives IT a chance to see where Microsoft’s default logic matches reality, where it collides with it, and where the organization still needs an actual rulebook. Security without judgment is just enforcement, and enforcement without explanation is where trust starts to break down.