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
- Tenant detail → Changes → User what-if (or Users → pick a user → Simulate sign-in).
- Choose the user from the picker or open their profile first for sign-in triage.
- Adjust scenario inputs (see below).
- 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
| Input | Values | What it represents |
|---|---|---|
| Platform | windows / macOS / iOS / android / linux |
OS of the device the user is signing in from |
| Client app | browser / mobileAppsAndDesktopClients / exchangeActiveSync / other |
How the user is connecting |
| App | All or a specific Graph app id |
Which target app they're trying to reach |
| Sign-in risk | none / low / medium / high |
What Identity Protection says about this sign-in |
| User risk | none / low / medium / high |
What Identity Protection says about the user |
| Roles assigned | (multi-select) | Directory roles the user has - overridable |
| Is guest | toggle | Whether to evaluate the user as a guest identity |
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, ornot-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
| Field | Meaning |
|---|---|
wouldBlock |
Would the user actually be blocked from completing this sign-in? |
wouldRequireMfa |
Would they be prompted for MFA? |
wouldRequireCompliantDevice |
Would they be sent to compliance enrollment? |
enforcedPoliciesApplied |
Count of enforced policies that applied |
reportOnlyPoliciesApplied |
Count of report-only policies that applied |
The "report-only does not flip wouldBlock" rule
This is the single most important interpretation rule:
A policy in
enabledForReportingButNotEnforcedstate can produce aneffect = blockrow, but it does not count towardwouldBlock = 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 = falsebut 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 = trueandwouldBlock = truesimultaneously. 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? = trueto 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.