Microsoft 365 and Entra ID

Read a sign-in like an admin: Conditional Access decisions

Change who signs in, from where and on what device, and watch six policies decide. Then read the same decision in a real sign-in log.

  • Intermediate
  • About 30 minutes
  • Admin portal
  • Simulation + real-world
  • Published 26 October 2026

The scenario

"Why was I blocked?" and "Why wasn't I asked for MFA?" are everyday identity questions. The answer is in how Conditional Access policies combine. Experiment safely here, then find the same evidence in a real tenant.

Before you start

  • Basic understanding of user accounts and multifactor authentication (MFA)
  • For the real-world part, a test or trial tenant you administer. Never experiment in production.
  • Conditional Access requires Microsoft Entra ID P1 licensing. Risk-based conditions require P2.

Tools

  • Microsoft Entra admin center
  • Sign-in logs
  • What If tool
  • Report-only mode

You'll be able to

You can predict whether a sign-in will be allowed, challenged or blocked, explain which policy caused it, and find the same answer in a sign-in log.

Try it

Browser simulation. Runs entirely in your browser. Nothing connects to real systems.

Simulated tenant with six example policies. A simplified model of how Conditional Access decides; it never connects to Microsoft services.

The sign-in attempt

Result

Access granted after MFA

The sign-in was interrupted for multifactor authentication, then allowed because every applicable policy was satisfied.

Sign-in status
Success
Conditional Access
Success

Policies in this tenant

Change a policy's state to see report-only mode in action: it is evaluated and logged, but never enforced.

  • CA001Block legacy authenticationAll users, all apps, legacy clients
    Not appliedClient is a browser or modern app
  • CA002Require MFA outside the officeAll users, all apps, except trusted locations
    SuccessSign-in is from an untrusted location. Satisfied: multifactor authentication.
  • CA003Require a compliant device for Microsoft 365Staff and admins, Outlook and SharePoint
    SuccessStaff or admin opening a Microsoft 365 app. Satisfied: a compliant device.
  • CA004Protect admin portalsAdmins, Azure portal
    Not appliedOnly admins are in scope
  • CA005Block high-risk sign-insAll users, all apps, high sign-in risk. Risk conditions need Microsoft Entra ID P2.
    Report-only: Not appliedSign-in risk is none
  • CA006Guests always use MFAGuests, all apps
    Not appliedUser is not a guest

How Conditional Access makes a decision

Every sign-in is checked against every enabled policy. Each policy has two halves:

  • Assignments and conditions decide whether the policy applies: which users, which apps (Microsoft calls these target resources), and conditions such as location, device platform, client type and sign-in risk.
  • Access controls decide what happens if it applies: block, or grant with requirements such as MFA or a compliant device.

Three rules explain most outcomes you will see:

  1. All applicable policies must be satisfied. If one policy requires MFA and another requires a compliant device, the user needs both.
  2. Block wins. One applicable block policy blocks the sign-in, whatever the others say.
  3. No applicable policy means no Conditional Access at all. The sign-in result shows “Not applied”. That is worth noticing, because it means nothing protected that sign-in.

Try these in the simulation

  • Sign in as Alex from the office, then from “anywhere else”. Which policy brings in MFA?
  • Switch Alex to a personal, unenrolled device. Why does Outlook block but the Azure portal does not?
  • Choose a legacy protocol. Why can’t MFA save this sign-in?
  • Set the sign-in risk to high. CA005 is in report-only mode, so it records “Report-only: Failure” but does not block. Switch it On and compare.
  • Turn every policy off. Notice the Conditional Access status becomes “Not applied”.

Reading the same decision in a real tenant

In the Microsoft Entra admin center, open the Sign-in logs (under monitoring) and select a sign-in. The details pane has a Conditional Access tab that lists every policy with its result:

  • Success: the policy applied and its requirements were met.
  • Failure: the policy applied and its requirements were not met, or it blocked.
  • Not applied: the policy’s conditions did not match this sign-in.
  • Report-only: Success / Failure / User action required: what the policy would have done had it been enforced.

Select a policy in that tab to see exactly which assignments and conditions matched. Admin center menus get reorganised from time to time; if a label has moved, search for “Sign-in logs”.

Safe practice: report-only first, then What If

  1. In a test tenant, create a policy in Report-only state. This is how new policies should start in real environments too, because report-only lets you see the impact before anyone is locked out.
  2. Sign in as a test user and find the sign-in in the logs. Check the policy’s report-only result.
  3. Use the What If tool in Conditional Access to simulate a sign-in for a given user, app, location and device without anyone signing in.
  4. Exclude at least one emergency access (“break-glass”) account from your policies, so a mistake can never lock every administrator out.

Expected result

You can explain, for any combination in the simulation, why the result is what it is, and you know which three places in a real tenant (sign-in logs, the Conditional Access tab and What If) give you the same evidence.

Further reading

Key lessons

  • Every applicable policy must be satisfied, and a single block wins.
  • "Not applied" in a sign-in log means nothing protected that sign-in.
  • Start new policies in report-only mode and check the impact before enforcing them.

Keep going