Intune compliance and Conditional Access: evaluation versus enforcement
Trace device compliance from an Intune rule to an Entra access decision. Plan report-only rollout, evidence collection and recovery for a minimum-OS policy change.
TL;DR: Intune evaluates device compliance; Entra Conditional Access can use that result when deciding access. A policy assignment, a device's local condition and the status seen at a sign-in can differ in time, so diagnose all three before widening an exclusion.
Define the rule and the enforcement point
A compliance policy states conditions such as supported OS versions or required security settings. The platform evaluates and reports the relevant state. Conditional Access combines applicable conditions and access controls for a sign-in. Requiring a compliant device connects these systems, but compliance alone does not create that access rule.
Configuration delivery is another operation. Setting a desired configuration and observing compliance against a requirement should have distinct evidence. A failed requirement may need remediation on the endpoint, a corrected assignment or a reporting investigation.
Microsoft's device compliance reference describes device policies, tenant-level behavior and reporting. Review the tenant's treatment of devices with no assigned compliance policy; an absent assignment must not accidentally become your intended security assurance.
A sign-in consumes an evaluated state
The sequence is a logical dependency, not a promise of synchronous delivery. Existing sessions and token behavior require separate consideration. Do not advertise compliance changes as an instantaneous kill switch for every established application connection.
Worked rollout: increasing the minimum OS requirement
Suppose a team wants to raise its minimum supported OS version for employee laptops. Start by measuring the affected population and understanding why devices are behind: powered off, awaiting reboot, incompatible hardware, failed installation or incorrect inventory. Those categories require different remediation.
Create and assign the intended compliance policy to a pilot. Ensure compliant test devices actually exist before enabling a blocking access policy. Use Conditional Access report-only evaluation to inspect which sign-ins would be affected, with a documented recovery procedure and protected emergency access.
The example is deliberately staged. If fifty devices would fail because users have not rebooted, a communication and servicing plan may resolve most of the gap. If the devices cannot run the required version, no number of forced synchronization attempts will make the policy attainable. That is a replacement or exception decision with an owner and expiry.
Microsoft's require-compliance deployment guidance describes report-only rollout and exclusions for recovery. Apply those controls to the actual target-resource scope, rather than copying a tenant-wide policy without testing its consequences.
| Layer | Evidence to inspect | Example failure |
|---|---|---|
| Assignment | Policy and included groups | Pilot device received no requirement |
| Endpoint | Actual OS and setting state | Update installed but restart pending |
| Compliance reporting | Per-setting result and timestamps | Device has not reported the changed state |
| Access evaluation | Sign-in log and applicable policies | Another policy is responsible for denial |
| Application session | Authentication and session behavior | Existing session persists after a policy change |
Diagnose one blocked sign-in precisely
Record the user, target resource, device identity and sign-in timestamp. Inspect the access evaluation result before assuming the user's verbal description identifies the failed control. A device-compliance denial and a different authentication requirement can look similar at the application boundary.
Compare the device identity in that event with the active Intune record. A reprovisioned laptop with stale directory objects can make a screenshot from the wrong record appear contradictory. Then inspect individual compliance settings and their reporting times. “Compliant now” does not establish that the state was compliant at the earlier decision.
Prefer a scoped repair over a broad exclusion. If an exception is necessary to restore a critical workflow, record who can use it, what resources it covers, its expiration and the compensating control. Otherwise a temporary response can become the fleet's permanent bypass.
Explain the operational tradeoff
A strict requirement can protect application access while also blocking people who need remediation help. Design the support path before enforcement, including how a user reaches recovery instructions and how administrators retain controlled emergency access. Enrollment and patch rollout are prerequisites to making the required state achievable.
If Intune reports noncompliance, must every application deny access? No. Enforcement depends on applicable access policy and the application's authentication/session path.
If a fresh sign-in is blocked although the portal now says compliant, what should you compare? Match device identity, timestamps, individual requirement results and the actual policies evaluated. Do not disable the entire access policy based on two screenshots collected at different times.