A finance admin passes MFA. Then Exchange Online prompts again.
A compliant device can suddenly fail. A Report-only policy can also create a lockout risk when it is promoted.
Do not disable controls before you capture sign-in evidence. That can widen the incident.
Map the incident before changing access
Capture one failed sign-in and its full evaluation result before editing Conditional Access.
Capture the sign-in evidence
Open Microsoft Entra admin center. Select Identity, then Monitoring & health, then Sign-in logs.
Filter for the affected user. Set the time range to the last 24 hours.
Open the failed event that matches the user's time, app, and client. This usually takes between 5 and 10 minutes.
Record the user principal name, application, timestamp, correlation ID, client app, IP address, device ID, operating system, and status. The correlation ID is the receipt for one request.
This prevents you from comparing a browser sign-in with a separate Outlook sign-in. It also separates mobile app traffic from browser traffic.
One correlation ID keeps the investigation tied to one request.
Open the conditional access tab
Select the Conditional Access tab in the sign-in event. Copy each policy name and outcome into your incident note.
Use these outcomes: Success, Failure, Not applied, Report-only success, or Report-only failure. The typical error is copying only failed policy names.
Read the failure reason for every policy marked Failure. A policy may be not applied because the user or app did not match.
The device platform, named location, client app, or risk condition may also prevent a match. A policy that did not apply cannot cause that sign-in failure.
A Conditional Access incident should start with one correlation ID, one sign-in event, and that event's policy outcomes. Policy names alone are not evidence. The same user can match different policies across browsers, mobile apps, legacy clients, and device states.
⚠️ Do not compare events with different correlation IDs. Outlook, browsers, and mobile apps often create separate sign-ins.
Reproduce the sign-in in what if
Run What If with the same user, app, device, and location to find matching policy assignments.
Match the real request, not a guess
Set the client app only when it appears in the sign-in event. Set user risk or sign-in risk only when the event shows those values.
A browser session on managed Windows can differ from an iOS mobile app session. The user and cloud app can be identical.
Review Policies that apply and Policies that do not apply. Open every applied policy and compare its assignments.
Compare included and excluded users, groups, cloud apps, conditions, grant controls, and session controls. The fast method is testing only the user and app.
The correct method also matches the client, platform, location, and risk values. That takes between 10 and 20 minutes.
Verify effective group membership
| Test field | Use value from | Mismatch that changes result |
|---|
| User and group scope | Affected sign-in user | Guest object or missing group membership |
| Cloud app | Resource in sign-in log | Testing Office 365 instead of the actual app |
| Platform and client | Device details and client app | Browser tested as mobile or vice versa |
| Named location | Source IP from the event | VPN egress IP differs from office IP |
Separate assignment logic from control logic
A policy can look contradictory when you read all settings as one operator. Microsoft Entra evaluates assignment lists and condition categories differently.
Multiple included users or groups are usually alternative ways to enter scope. Matching any included selection can match that assignment.
An exclusion can still remove the user from scope. The same rule often applies to selected cloud apps or named locations.
Across enabled condition categories, the request must meet the relevant conditions together. A Windows device in an untrusted named location must meet both conditions.
After a policy matches, Entra evaluates grant controls separately. Require all selected controls means every chosen control must pass.
Require one of the selected controls means one control can satisfy that policy. Compare these layers before calling overlap a conflict.
The error most teams make here is mixing scope rules with grant rules.
⚠️ What If can mislead you when the VPN egress IP, guest object, or client type differs from the real event.
Compare controls to find the conflict
Compare every matching control as one access decision, because Block wins and grant requirements stack.
To find a Conditional Access conflict, start with the sign-in log and list every policy marked Success or Failure. Any policy with Block denies access, even if another policy accepts MFA. When no Block applies, Entra combines grant demands from matching policies. MFA and device compliance can both be required. Fix the narrow assignment that matched incorrectly. Do not disable broad controls before testing a pilot.
Read block before grant controls
Find every matching policy with Block access as its grant setting. That policy is the immediate denial cause.
Document its included scope, exclusions, and matched condition before changing it. This takes between 5 and 15 minutes for a single event.
A Block policy is like a shut fire door. A valid badge at another door cannot open it.
The safest fix is usually a narrow assignment or condition correction. Do not disable the whole policy unless the scope cannot be repaired.
Add grant requirements together
List all matching grant controls in one row. Include MFA, compliant device, hybrid joined device, and authentication strength.
Then check whether each policy requires all selected controls or one selected control. This setting applies inside that one policy.
MFA plus a compliant device is not automatically a conflict. It is an intended combined requirement when the scope is correct.
Check affected users, apps, and device platforms for bad scope. Session controls can also force new token checks.
Sign-in frequency and Continuous Access Evaluation can trigger those checks. They may challenge the user without blocking access.
A common case is finance users receiving MFA twice. One policy requires MFA, while another shortens sign-in frequency.
How matching controls combine in one sign-in
Match policies
User, app, conditions
Any Block?
Yes: deny access
No Block
Add grant controls
Apply sessions
Token and app limits
Block overrides grants. MFA and device compliance can both be required. Report-only predicts impact but does not enforce access.
⚠️ Do not remove MFA to fix a compliant-device failure. First identify the policy that requires device compliance.
Fix the smallest scope and validate rollback
Correct the assignment or condition that caused the result, then prove recovery with a pilot sign-in.
Repair common reproducible failures
For a noncompliant-device denial, open device details in the sign-in log. Compare them with Intune compliance status.
If Intune has not evaluated the device, Conditional Access cannot treat it as compliant. Enrollment and compliance checks can take between 15 and 60 minutes after a meaningful device change.
For repeated MFA, compare the prompt time with sign-in logs and authentication details. Use the same 10 to 20 minute window.
If no Conditional Access policy challenged the user, inspect Security Defaults. Also inspect per-user MFA, authentication methods, token state, and sign-in frequency.
Most guides stop at Conditional Access. In practice, Security Defaults or per-user MFA often causes the extra prompt.
Open Conditional Access and select the Report-only policy. Review its impact for at least 7 to 14 days of normal business sign-ins.
Filter report-only failures by user, app, device platform, and location. Test named pilot users before changing the policy state to On.
Keep at least two dedicated emergency access accounts. Exclude them through explicit accounts or a dedicated group.
Test those accounts on a recurring schedule. Protect them with long unique passwords and monitored sign-ins.
Restrict their storage and document emergency ownership. Do not depend on the same device or network.
- Document the policy name, original state, editor, timestamp, and exact change before saving.
- Test one pilot user on a managed device within 10 to 20 minutes.
- Test one expected external scenario within the same 10 to 20 minutes.
- Keep a rollback action ready: restore the prior assignment or return the changed policy to Report-only.
- Confirm emergency accounts can sign in before and after the change.
Use policy layers to prevent the next conflict
Conditional Access is a Zero Trust engine. It checks each request instead of trusting a familiar network.
It checks identity, device compliance, app, client conditions, location, and risk signals. A maintainable design separates broad rules from narrow exceptions.
One baseline policy can require MFA for all users and cloud apps. A separate policy can require device compliance for sensitive finance apps.
Keep Block policies especially narrow. Document the business condition that each one protects.
Use names that show audience, app, condition, and control. For example: “CA - Finance - Unmanaged Device - Block.”
Before changing production scope, run What If and review Report-only results. Use a pilot group and keep a tested rollback path.
This design makes unexpected evaluations easier to trace. It also reduces tenant-wide outage risk.
⚠️ Do not switch a broad Report-only policy to On without tested emergency accounts and a pilot result.
This method will not fix legacy authentication, license errors, federation failures, or Intune checks still pending. It also does not apply when no Conditional Access policy matches the sign-in. Check app restrictions and controls outside Microsoft Entra in those cases.
Use the recorded correlation ID, What If result, and pilot test in your change ticket. This gives reviewers a clear rollback record before production promotion.
Questions & answers
Use these answers to separate combined Conditional Access results from unrelated authentication failures.
Why am I getting MFA prompts repeatedly?
Repeated MFA can come from sign-in frequency, authentication strength, Security Defaults, or per-user MFA. Token state and authentication methods policy can also cause prompts.
Check the sign-in event and authentication details from the same 10 to 20 minute window. Do this before changing a policy.
Does report-only block users?
No. Report-only records what a policy would have done, but it does not enforce grant, block, or session controls.
Review at least 7 days of normal sign-in activity before moving a broad policy to On. Use pilot users before broad production scope.
Why does my conditional access exclusion not work?
An exclusion fails when the user lacks effective group membership. It also fails when the account is a different guest object.
Another policy may still match the same user. Confirm actual group membership and inspect every applied policy in the sign-in log.
⚠️ A Report-only result is predicted impact, not enforced access. Never treat it as proof that production access works.
Keep evidence with every policy change
Close the incident only after the repaired sign-in succeeds and the evidence explains why.
Confirm the production result
Repeat the affected sign-in with the same app, device, and network path. Wait between 5 and 15 minutes for normal policy and token behavior.
Open the new sign-in log after that wait. Confirm the prior blocking policy is not applied, or now succeeds for the documented reason.
A user report is useful, but it is not enough. Cached tokens can hide the next policy result.
Review the next policy cycle
Review the next sign-in from the affected workflow. This catches a token cache that masked the first test.
Keep the old and new correlation IDs in the ticket. They show the exact change in policy evaluation.
⚠️ Do not close the ticket from a user report alone. Verify the new sign-in log after a fresh Conditional Access evaluation.
Which conditional access policy takes precedence?
No policy takes precedence. Microsoft Entra evaluates all matching policies in parallel.
Any matching Block control denies the sign-in. Matching grant controls, such as MFA and compliant device, can both apply.
⚠️ Do not assume policy order determines the result. Review every policy marked Success or Failure for the same correlation ID.
