Conditional Access blocked a sign-in: use the event before changing the policy

A blocked sign-in is an evaluation result, not proof that the entire Conditional Access design is wrong. The same person can have different outcomes for another application, device state or authentication context. Start from the failed attempt and work outward from the evidence.

Match the event to the user’s report

Collect the time, target application and the request or correlation identifier shown by the error where available. Locate the corresponding Entra sign-in event and inspect its Conditional Access details. Be careful with time zones and repeated attempts; a nearby successful event may belong to a different application or authentication flow.

Check the principal, device information, client type and relevant network context. Ask for the exact failure behavior instead of requesting screenshots that expose unrelated account information. Record enough identifiers for an authorized administrator to investigate privately.

Read every relevant policy result

A policy can require MFA, a compliant device or another control that the current attempt does not satisfy. More than one policy can apply. Inspect the evaluated results and distinguish a policy that did not apply from one that applied and blocked access. The result of an individual control matters more than a broad role name.

Use the What If tool to evaluate a proposed scenario, while recognizing that a simulation is only as useful as its inputs. Compare those inputs with the recorded sign-in. If the device state or application selection differs, the simulation is not a reproduction of the failed request.

Correct the mismatch at its source

If the device should be compliant, investigate its compliance state and management path. If the user is unexpectedly in scope, check the policy’s assignments and relevant group membership. Prefer a narrow correction to the underlying condition over a broad exclusion that merely suppresses the symptom.

Test policy changes with an appropriate pilot and report-only evaluation when available for the change. Keep emergency access planning separate, and verify that designated recovery accounts retain their documented path. Avoid a tenant-wide disable operation just to get one person signed in.

After the change, capture a new sign-in event showing the expected controls satisfied. Check a negative case where access should remain blocked. Keep the policy rationale and test evidence with the change record so the next administrator can maintain the boundary without repeating the investigation.