Conditional Access Rule Simulator

Define simplified Microsoft Entra ID Conditional Access policies and simulate a sign-in against them to see which apply and what grant controls result.

This is a teaching model, not a policy engine. It reproduces the shape of Conditional Access evaluation - condition matching, then a union of grant controls, then block wins - so you can reason about the logic and explain it to others. It is not connected to any tenant, does not reflect every real-world condition or control, and is not a substitute for testing actual policies with Entra's What If tool or a pilot group.

1. Sign-in scenario

The sign-in event you want to test the policies against.

The groups this sign-in's user belongs to. Add as many as apply.

2. Conditional Access policies

Each condition defaults to "Any", meaning the policy does not filter on it. Leave a condition on Any when it should not narrow who the policy applies to.

Grant controls

Blocking access is exclusive - a policy either blocks, or grants access subject to the other controls checked here.

Defined policies

How the simulation actually decides

Real Conditional Access evaluates every enabled policy independently and then combines the outcomes - it does not stop at the first match. This simulator follows the same shape: it finds every enabled policy whose conditions match the scenario, and if any of those matching policies blocks access, the overall result is blocked, full stop. Otherwise, the grant controls required by every matching policy are combined into one list - a user must satisfy all of them, not just the ones from whichever policy happened to be defined first.

If no policy matches the scenario at all, the simulated result is the same as a tenant with no applicable Conditional Access policy: access allowed, with nothing extra required. That is worth showing junior engineers explicitly, since "no policy applies" is a genuinely common and dangerous gap in real tenants.

What this leaves out on purpose: session controls (like sign-in frequency or app enforced restrictions), authentication strength (specific MFA methods), risk-based policies that key off user risk rather than sign-in risk, report-only mode, exclusions, and the dozens of other conditions Entra actually supports. Treat this as a way to build intuition for the evaluation logic, not a reference for what conditions exist.