Conditional Access Lab
Identity is the new perimeter, and Conditional Access is how you defend it. Build policies on who, where, what device and how risky, evaluate real-looking sign-ins, and learn the two things that bite every tenant: the legacy-auth protocol that quietly bypasses MFA, and the block policy that locks you out of your own emergency account. Other analysts are tuning the same tenant alongside you.
Goal
Require MFA for everyone, block legacy authentication, block high-risk sign-ins, and NEVER lock out the break-glass account. Legitimate staff and admins must still get in (with MFA); the attacker sign-ins must not.
Conditional Access policies (all matching apply)
Score vs goal
Build your policies, then evaluate the sign-ins.
Live now
4 working this scenariowatching the tenant…
What this lab is
- A free Conditional Access lab: build identity policies (by group, location, device, risk and client) and evaluate labelled sign-ins against them.
- Policies combine the way Entra does — every matching policy applies, a Block overrides everything, and all required grant controls (MFA, compliant device) must be satisfiable.
- It catches the two mistakes that cause real incidents: a legacy-auth gap that bypasses MFA, and a block policy that locks out the break-glass account.
- A live arena shows other (simulated) analysts tuning their policies and a stream of AI-driven sign-ins — staff and attackers — hitting the tenant as you work.
- Goal-based scenarios: require MFA, block legacy auth and high risk, and keep legitimate users and the emergency account working.
Frequently asked questions
What is the Conditional Access Lab?
A free, in-browser exercise where you build identity access policies — conditions on user group, location, device state, sign-in risk and client type, granting block / require MFA / require compliant device — and then evaluate a set of labelled sign-ins (legitimate users and attackers) to see who gets in, who is challenged, and who is blocked.
How do the policies combine?
Like Microsoft Entra Conditional Access: all policies whose conditions match a sign-in apply at once. If any matching policy says Block, the sign-in is blocked. Otherwise the required grant controls across all matching policies are combined — so "require MFA" and "require compliant device" both have to be satisfiable or access is denied. If no policy matches at all, the sign-in is allowed, which is itself a gap.
What are the break-glass and legacy-auth traps?
A break-glass (emergency) account must be excluded from blocking policies, or an outage in your identity provider can lock you out of your own tenant — the lab flags a lockout if your policy blocks it. Legacy authentication protocols (IMAP, POP, basic auth) cannot perform modern MFA, so if you do not explicitly block legacy clients, an attacker uses them to bypass MFA entirely — the lab flags that gap too.
Is the multiplayer real?
The other participants are a self-contained simulation inside the page — AI-driven analysts and sign-in traffic that react to your progress. It is there to make the exercise feel like a live tenant, not a quiz. No real users, accounts or network are involved.