Conditional Access Explained: How Microsoft Decides Whether to Allow Access

Every single time someone signs in to a Microsoft 365 account, the exact same set of questions gets asked before anything is granted. Not sometimes, not for suspicious logins only, every time, for every user, on every device. Microsoft describes this as "the policy engine that combines signals such as user, device, and location to make access decisions," and that description is accurate but abstract. Here's what it actually looks like as a real sequence of questions, with real examples showing exactly how a decision comes out the other end.

I've touched on Conditional Access as the Decision Maker in the security team analogy and why it needs more than one signal to be meaningful. This is the cornerstone piece: the actual mechanics of how it decides.

User Sign-in
     ↓
Who?
     ↓
Which Device?
     ↓
Which Application?
     ↓
Where?
     ↓
Risk?
     ↓
Compliant?
     ↓
MFA Required?
     ↓
ALLOW / BLOCK / REQUIRE CONTROL

The Eight Questions, One at a Time

How the Engine Actually Combines All of This

This is the part most explanations skip, and it's the actual mechanism, not just a list of signals.

Three Real Sign-Ins, Walked Through

Example 1: A Normal Morning (Allow)

Example 2: An Impossible Sign-In (Block)

Example 3: The Middle Ground (Require Control)

Why "Require Control" Is the Answer Most Often Missed

Beginners tend to think of Conditional Access as a yes/no gate. In practice, Require Control is where most real policies actually land, MFA, a compliant device, an approved client app, or some combination, rather than a flat allow or block. The three examples above show why: the same person, the same app, can land on three completely different outcomes purely based on device and context, and the middle outcome is normal, not an edge case.

Putting the Whole Engine Together

Conditional Access isn't one rule, it's an engine that runs every applicable rule at once and resolves them with the two combination rules above. Understanding those two rules, block always wins, and required controls stack, is the difference between designing policies deliberately and discovering what they actually do after they've already surprised someone.

Which outcome catches people off guard most in your own experience, an unexpected Block from an old policy nobody remembered, or a Require Control step that felt like it came from nowhere? Drop a comment below with what actually happened.