Require compliant or managed devices by creating a Conditional Access policy that permits access only from devices meeting your compliance or management criteria. Target the right users, apps and device platforms, then require the relevant device state before access is granted. Monitor exclusions carefully, because broad exceptions can bypass the control and leave unmanaged endpoints able to connect.
What “managed” and “compliant” need to mean in the policy
A conditional access policy only works if you are precise about the device signal you are trusting. “Managed” usually means the device is enrolled in your management plane, while “compliant” means it has passed the posture checks your organisation enforces. Those are related but not identical, and the policy should reflect whichever state you actually want to require.
The distinction matters because a device can be managed without being healthy, and a device can appear compliant while still carrying local risk if your posture rules are too weak. If the access decision depends on device trust, make sure the policy is tied to the right source of truth and that the compliance state is current enough to be meaningful.
For a practical design baseline, use the Conditional Access Guide to align the policy with device state, report-only testing and exclusion review before enforcement.
When the access pattern also depends on endpoint health or posture, the Device Trust and Posture Guide helps separate true compliant-device decisions from weaker “managed only” assumptions.
How to scope the policy so it blocks the right traffic
The control is not just “turn on require compliant device.” You need to scope the policy to the users, cloud apps and device platforms where that requirement makes sense, otherwise you create gaps or accidental lockouts. In practice, start with the applications that carry the highest data or privilege impact, then decide whether the rule applies to all users or only a defined population.
Device platform scoping is especially important when you support multiple endpoint types, because compliance signals and management options can differ by platform. If the policy is too broad, you can force unsupported devices into exceptions; if it is too narrow, users may find an unintended path around the control. That is why policy design should be explicit about where the requirement applies and where it does not.
The broader identity and access posture behind this pattern is covered in the Zero Trust Identity Guide, which treats device state as one signal in an identity-centric access decision.
The same policy also sits alongside the Microsoft 365 Security Guide when you are enforcing Entra sign-in controls across Microsoft 365 services and need the device requirement to fit the wider tenant posture.
Why exclusions and test modes decide whether the control holds up
Conditional Access often fails through exceptions rather than through the core rule. Exclusions for break-glass accounts, legacy workflows, temporary testing or unsupported platforms can quietly become standing bypasses if they are not reviewed and narrowed. Report-only mode and controlled rollout are useful because they show where the policy will break before you make it mandatory.
Teams should also watch for policy interactions. Another policy may override the intended effect, or a weaker policy may still permit access in a path you did not expect. If the device requirement is being used to protect sensitive apps, exclusions need the same level of scrutiny as the main rule, because one broad exception can reopen unmanaged access at scale.
That is why the Top 10 MFA Mistakes is relevant here as a companion control pattern: exclusions, fallback paths and partial enforcement are common ways access policies lose effectiveness.
Risk and Threat Considerations
A device-based Conditional Access rule reduces exposure, but it is only as strong as the trust in your compliance signal and the discipline of your exceptions. If attackers can land on unmanaged endpoints, or if users can reach the same apps through an excluded path, the control becomes advisory rather than preventive.
Failure mechanism: Weak device posture checks, stale compliance data, or overly broad exclusions can let unmanaged or compromised endpoints satisfy the policy path, especially when the organisation assumes management status equals device trust.
Impact: Attackers or careless users may gain access from devices that do not meet baseline security expectations, increasing the chance of credential theft, token abuse, data exposure and lateral movement through trusted apps.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 and CIS Controls v8 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-2 — Identification and Authentication (Organizational Users) | Conditional Access enforces user sign-in trust before device-based access is allowed. |
| AC-6 — Least Privilege | Scoping access to compliant devices limits access pathways and reduces standing exposure. | |
| CM-6 — Configuration Settings | Device compliance depends on enforced configuration and posture settings on managed endpoints. | |
| Recommendation — Require authenticated user access before evaluating device compliance for the app. Restrict app access to the minimum device and user combinations that need it. Define and enforce baseline device settings that determine compliance status. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | Conditional Access is an access control decision based on device trust and policy scope. |
| Recommendation — Apply access control rules that require compliant devices for protected resources. | ||
| CIS Controls v8 | CIS-6 — Access Control Management | This control covers restricting access to authorised devices and accounts through managed policy. |
| Recommendation — Limit application access to approved devices and review exceptions regularly. | ||
Practitioner Guidance
What to verify: Confirm that your policy uses the exact device state you intend, not a looser proxy. If the business requirement is “managed,” verify that management enrollment alone is sufficient; if the requirement is “compliant,” verify that the compliance policy is actually enforcing the security posture you need.
Decision rule: If a user, app or platform cannot reliably produce the required device signal, do not silently broaden the rule, either create a supported onboarding path, or keep the access denied until the device can satisfy the control.
Common mistake: Treating exclusions as temporary when they have no expiry or owner. The operational test is simple: if you cannot explain why an exception exists and when it will be removed, it is already a control gap.
Practitioner takeaway: The control is effective only when device trust is explicit, testable and narrowly bypassable; otherwise “require compliant device” becomes a policy label rather than an access barrier.
Related resources from NHI Mgmt Group
- How do you require compliant devices with Conditional Access in Microsoft Entra ID?
- How do you require app protection policies on mobile devices with Conditional Access?
- Why do risky sign-ins, legacy authentication, and non-compliant devices increase the need for Conditional Access?
- How should security teams run access reviews for non-human identities?