Predictive what-if

What it does

Simulates a sign-in for a specific user under specific conditions and reports which CA policies would apply and what the combined verdict would be. Unlike Impact analysis (which looks at historical sign-ins), what-if is forward-looking: pick the user, pick the scenario inputs, see what would happen.

The simulator runs entirely against the latest policy snapshot - no Graph calls, no sign-in log queries. You can run it dozens of times in a row tuning the inputs.

When to use it

• Pre-change validation. "If I tighten this policy, would Alice still be able to sign in from her current device?"
• Lockout triage. A user reports "I can't sign in from my phone." Run what-if with their actual platform + app and see which policy is blocking.
• Onboarding new device classes. "If we roll out Android, what hits them on day one?"
• Customer training. Show the customer's IT lead the exact path their CEO's iPhone sign-in takes through CA.

For "would this change have blocked anyone over the last week?" use Impact analysis instead - that one runs against real history.

Running what-if on a user

1. Tenant detail → Changes → User what-if (or Users → pick a user → Simulate sign-in).
2. Choose the user from the picker or open their profile first for sign-in triage.
3. Adjust scenario inputs (see below).
4. Click Re-run simulation after changing inputs. The page reloads with the updated verdict.

For fleet-wide historical impact ("who would have been blocked last week?"), use Impact analysis under Policy impact instead.

Choosing scenario inputs

The defaults reproduce a normal interactive browser sign-in from Windows with no risk and no extra roles.

Interpreting the verdict

The output has two parts:

Per-policy evaluation

A table, one row per CA policy in the snapshot, showing:

• Applies? - true if the policy's conditions match the scenario. Most policies will be "not applicable" for any given scenario; that's normal.
• State - enabled / disabled / enabledForReportingButNotEnforced.
• Effect - block, mfa-required, compliant-device-required, session-control, no-grant-effect, or not-applicable.
• Match reason - short string explaining why this policy applied (e.g. "matched users.includeUsers", "matched conditions.platforms").

Hover any "Applies?" cell for the field-level reasoning.

Summary

The "report-only does not flip wouldBlock" rule

This is the single most important interpretation rule:

A policy in enabledForReportingButNotEnforced state can produce an effect = block row, but it does not count toward wouldBlock = true. Only enforced policies contribute to the lockout verdict.

This matches Entra's real behaviour: report-only policies are logged but not enforced. The per-policy row will still flag the block (useful to see what would happen if you enforced it), but the summary verdict reflects today's reality.

This means a common scenario shape is:

• wouldBlock = false (no enforced policy says block)
• reportOnlyPoliciesApplied = 1 (a report-only policy says block)

Read together: "this sign-in succeeds today, but if you flip that one report-only policy to enforced, the user will be blocked." That's the signal to run Impact analysis next.

Troubleshooting

• "User not in snapshot" error. The user's UPN wasn't in the last imported set. Resync the tenant and retry. The snapshot's MFA/user lists rebuild on every resync.
• Every policy says "not applicable." Check the include scope - usually means the user isn't a member of any group/role any policy targets. This is correct behaviour but easy to misread as "the simulator is broken."
• wouldBlock = false but I expect a block. Almost always one of: the blocking policy is still in report-only, or the scenario doesn't match a condition (e.g. you set platform=iOS but the policy targets Android). Read the per-policy row's match reason for the policy you expected to block.
• wouldRequireMfa = true and wouldBlock = true simultaneously. Two different policies - one requires MFA, another blocks unconditionally. Block wins at apply time; MFA never gets prompted.
• Per-policy table is huge. Filter to Applies? = true to focus on the rows that actually matter. The rest are noise.

Limits

• No session-control simulation. Sign-in frequency, persistent browser, CAE - these are evaluated as "session-control effect" without unpacking the consequence. The simulator doesn't model "what does CAE's strict location do for this specific sign-in?"
• No interactive flow. What-if reports the gate, not the user's path through MFA enrollment, device compliance prompts, etc.
• Snapshot-based. A policy added in Entra in the last hour won't appear until you resync.