The short answer
A compliance label describes a device assessment. It does not, by itself, explain whether a particular sign-in should succeed. Intune can supply compliance status to Microsoft Entra Conditional Access; the sign-in decision also depends on the policies and circumstances evaluated for that attempt. First compare the evidence, not the green labels.
Illustrative comparison · Not a client result
Two observations. One unanswered question.
10:05 · Access blocked
A browser app did not open. The matching sign-in event and device context have not been reviewed.
10:20 · Device says compliant
A later device screen shows a compliance state. It does not establish what the earlier sign-in evaluated.
Were these observations about the same identity, device, resource and attempt?
Example times use the same time zone. The difference is not proof of a synchronization issue, a policy error or a safe remedy.
Four checks before choosing a fix
- Capture one failed attempt. Note the app, browser or client, exact time and time zone, and the error shown. Use a redacted description for a public inquiry. Keep detailed error identifiers in your organization’s approved support channel.
- Match the right event. Ask an authorized support person to locate the corresponding Entra sign-in. Match identity, app and target resource, time and device context. A correlation ID can help, but is not a guaranteed unique or accurate match by itself.
- Compare the two observations. Record where and when the device was shown as compliant. Compare that with Device info and the access-policy result in the matched sign-in. A newer compliance screen does not establish what the earlier attempt saw. Missing information stays unknown.
- Separate the block from the remedy. Review the applied policies and the event’s failure details. If Conditional Access did not cause the failure, do not force that explanation. If the event or policy evidence is unavailable, the cause remains unknown. Have the appropriate support owner identify the next authorized check. Do not disable a policy, change exclusions, re-enroll or reset a device just to test a guess.
You do not need administrator access to prepare a useful account of what happened. If you cannot view the required logs, hand the note to your existing support team; this guide does not grant access or establish licensing.
Keep a useful next step
Access-block comparison note
- Use this when
- A compliance observation and an access outcome seem inconsistent.
- Leave with
- One failed attempt, the evidence still needed and an authorized owner for the next check.
A focused question for support
“Can you match this failed attempt to its device and policy evidence, then identify what remains unverified?”
Complete this original template privately in your approved support workspace. Do not paste filled identity/device details or raw logs into a public website or initial inquiry.
Read or select the template here
ACCESS-BLOCK COMPARISON NOTE Purpose: compare observations, not approve a change. Attempt time + time zone: App/client used and target resource, if known: Expected result / observed error (redacted): DEVICE ASSESSMENT Where the compliance status was observed: Observation time / available assessment time: Reported state: Same intended device confirmed by authorized reviewer? Yes / No / Unknown MATCHED SIGN-IN (authorized support fills this section) Event located? Yes / No / Unknown Identity / client / resource / time / device match confirmed? [record each or Unknown] Approved internal evidence reference (no token or secret): Device information reported for that event: Conditional Access outcome and relevant policy result: Failure detail / unresolved difference: NEXT HANDOFF Known facts: Unknowns: Next read-only evidence check and authorized owner: Approved channel for any sensitive details: No policy, account or device change is authorized by this note.
Need help untangling an access problem?
Describe the app, what you expected and what happened. Keep the first message general; detailed evidence belongs in an agreed support channel.
Talk through the endpoint problemWhat this does not prove
This guide does not diagnose the cause, confirm permissions or authorize a policy, account or device change. A compliant label, a matching symptom or missing log information is not a verdict.
Sources for this guide
How Intune compliance relates to accesshttps://learn.microsoft.com/en-us/intune/device-security/compliance/overview (external, new tab)
Understand device assessment and its relationship to Conditional Access.
Find the Conditional Access sign-in evidencehttps://learn.microsoft.com/en-us/entra/identity/conditional-access/troubleshoot-conditional-access (external, new tab)
Review the matched failure event and applied policy details with an authorized support person.
Understand sign-in fieldshttps://learn.microsoft.com/en-us/entra/identity/monitoring-health/concept-sign-in-log-activity-details (external, new tab)
Compare identity, client, resource, time and device context, including the limits of correlation IDs.
Checked November 8, 2026. The comparison workflow is Winhoven’s synthesis, not a Microsoft diagnostic. The linked troubleshooting article also discusses policy changes; this guide stops at investigation.