Require compliant devices with Conditional Access in Microsoft Entra ID by creating a policy that only allows access from devices marked compliant by your device management platform. Use it for sensitive apps and data, but confirm that device compliance is reliably reported and that break-glass accounts are excluded so you do not lock out administrators.
What “require compliant devices” actually means in Conditional Access
In microsoft entra id, a compliant-device requirement is an access gate, not a device-hardening feature by itself. The policy checks the compliance state reported by your device management platform and then allows sign-in only when that signal is present and trusted. That makes the control useful for sensitive applications, but only if your compliance pipeline is accurate, timely, and scoped correctly.
The practical question is whether the policy is enforcing a genuine managed-device trust decision or just collecting a checkbox. If compliance reporting is stale, if unmanaged devices can still appear compliant, or if critical exceptions are left broad, the policy becomes fragile. A good implementation starts with a clear device posture model and a defined set of apps or user groups where the extra friction is worth the reduction in exposure. Device Trust and Posture Guide
For most organisations, the control works best as part of a layered access model rather than as a standalone gate. Conditional Access should reinforce managed endpoints, session controls, and strong authentication, while separate admin protections handle privileged accounts and recovery paths. That is especially important in hybrid estates where device trust, identity controls, and endpoint management do not mature at the same pace. Conditional Access Guide
Because device compliance is only one signal, the policy is most defensible when it is paired with device registration, managed versus unmanaged classification, and explicit exclusion handling. If you cannot confidently distinguish compliant from merely enrolled, or managed from unmanaged, you have a posture-quality problem before you have an access-control problem. Zero Trust Identity Guide
Why this control usually fails in practice
The most common failure mode is overconfidence in the device-management signal. A device can be enrolled, partially managed, or recently compliant for reasons that do not reflect its current trustworthiness. If policy evaluation happens before posture synchronisation has completed, or if compliance states are not refreshed reliably, users can be blocked unexpectedly or, worse, granted access on outdated posture. That is why the policy should be tested in report-only mode before full enforcement. Conditional Access Guide
Another common issue is scope creep. Teams often begin with one sensitive app and then expand the requirement without checking whether the same device population, exclusions, and exception process still make sense. At that point, the policy can become a broad availability risk rather than a narrow protection for high-value data. The control should be tightened where the business impact is highest and left flexible where shared or bring-your-own devices still need limited access paths. Device Trust and Posture Guide
Administrators also run into lockout risk when they apply the rule to every account, including emergency access. Break-glass accounts need a separate design because the purpose of those accounts is recovery when the normal control plane fails. If those accounts are caught in the same Conditional Access rule set, the organisation can turn a containment control into a self-inflicted outage. Active Directory and Entra ID Hardening Guide
How to make the policy dependable, not brittle
Start by defining which apps truly require managed-device access and which do not. High-sensitivity workloads, administrative portals, and data sets with strong confidentiality requirements are the clearest candidates. For lower-risk services, a device-compliance gate can create unnecessary friction without materially improving security. The right target is a bounded policy surface, not blanket enforcement across every login path.
Then validate the operational details of your compliance feed. Confirm that device state, ownership, and management status are reporting consistently, and that noncompliant devices do not linger in a false-approved state. If your endpoint platform cannot prove reliable posture reporting, the access policy should be treated as advisory until that gap is fixed. Microsoft 365 Security Guide
Finally, document the exclusion model with the same care you use for the control itself. Exclusions should be narrow, reviewed, and owned, because they are effectively alternate trust paths. That includes recovery accounts, test users, and service exceptions that might bypass the intended device posture requirement if left unmanaged. Tiered Administration and Enterprise Access Model Guide
Risk and Threat Considerations
Requiring compliant devices reduces exposure, but it also concentrates trust in the integrity of the compliance signal. If an attacker compromises a managed endpoint, manipulates posture reporting, or abuses an exception path, the policy can be bypassed at the exact point it is supposed to reduce risk. The control is only as strong as the device-management process and the quality of the exclusions around it.
Failure mechanism: Compliance is accepted as proof of trust even when the device is stale, misreported, unmanaged, or deliberately exempted, allowing access to sensitive apps from a weaker endpoint than intended.
Impact: Sensitive data and administrative interfaces remain reachable from devices that should have been blocked, increasing the blast radius of endpoint compromise, session theft, and policy bypass.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST Zero Trust (SP 800-207), NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST Zero Trust (SP 800-207) | GV — Governance | Conditional Access is a policy enforcement mechanism for zero trust access decisions. |
| Recommendation — Apply policy-based access decisions that continuously verify device trust before granting access. | ||
| NIST SP 800-53 Rev 5 | IA-2 — Identification and Authentication (Organizational Users) | User sign-in is still governed by authenticated access before device compliance is checked. |
| AC-2 — Account Management | Break-glass and exception accounts must be managed separately to avoid lockout and overexposure. | |
| AC-6 — Least Privilege | Compliant-device access should be limited to apps and users that genuinely need the restriction. | |
| Recommendation — Ensure organizational users authenticate strongly before Conditional Access evaluates device compliance. Inventory and segregate emergency accounts so they are excluded from ordinary Conditional Access policies. Restrict compliant-device requirements to the smallest set of apps and identities that need it. | ||
| CIS Controls v8 | CIS-6 — Access Control Management | The policy is an access-control safeguard that depends on approved device posture and exception handling. |
| Recommendation — Use access-control policy to enforce compliant-device requirements and review exceptions regularly. | ||
Practitioner Guidance
What to verify: Before enforcing the policy, confirm that report-only results match real endpoint posture, that compliance refreshes arrive on time, and that the same device is classified consistently across sign-in attempts. If the device platform and Conditional Access disagree, fix the signal chain before tightening enforcement.
Escalation / exception: Treat break-glass accounts, migration accounts, and device-management outages as explicit exception cases with separate approval and monitoring. If you cannot describe who can bypass the rule and why, the policy is not yet operationally safe to enforce.
Practitioner takeaway: The value of compliant-device access is in reducing trust in unmanaged or unhealthy endpoints, but only when the compliance signal is reliable and the emergency path is deliberately outside the rule.