Microsoft Entra Suite Masterclass Step by step · Step 8

Right Password, Wrong Person: Risk-Based Conditional Access

Sign-in risk vs user risk, and two Entra templates: require MFA for risky sign-ins and a secure password change for risky users.

8 November 2026 · 4 min read

Conditional Access policies including the two risk policies in report-only mode — Watch the lesson: Step 8: When a sign-in looks wrong: risk-based Conditional Access | Entra Suite

What if someone has the right password, but it isn’t them? A stolen password looks like a normal sign-in, unless something scores the risk. That is ID Protection, and the response is Conditional Access. This is Step 8 of the Entra Suite Masterclass.

Two kinds of risk

Sign-in risk: this one sign-in looks wrong. An anonymous IP address, impossible travel, an unfamiliar place.
User risk: the account itself is probably compromised, for example its password turned up in a leak.

Microsoft scores the risk. You decide the response:

A risky sign-in, medium or high: require MFA. Prove it’s really you.
A high-risk user: require a secure password change.

Risky sign-in, medium or high, then require MFA — The rule for risky sign-ins.

Step 1: MFA for risky sign-ins

Conditional Access → Policies → New policy from template, the Zero Trust set. Two templates need Entra ID P2, which the suite includes. First: Require multifactor authentication for risky sign-ins.

Policy templates: Require multifactor authentication for risky sign-ins selected — The risk templates sit in the Zero Trust set.

Review it: all users except you, the admin who creates it, so you cannot lock yourself out. Sign-in risk: high and medium. Grant: require MFA. State: report-only.

Review + Create: policy name and Report only state — Report-only logs what the policy would do on every sign-in.

Why report-only? This tenant keeps security defaults on, and the two cannot enforce side by side.

Step 2: Remediation for high-risk users

Second template: Require risk remediation for high-risk users. For an account that is probably compromised, fix it first, with a secure password change and its sessions revoked. Report-only, and Create.

Policies list with seven report-only policies including the two risk policies — Seven policies now, including the two risk policies.

Where risk shows up

ID Protection → Dashboard: attacks blocked (six in the last three months in this tenant, from Microsoft’s own protections, before any policy of ours), and the reports: risky users, risky sign-ins and risk detections.

ID Protection dashboard: number of attacks blocked — The dashboard and the risk reports.

How you know it worked

In the next step of the course we cause a real risky sign-in, and find it in Risk detections, with the sign-in log showing what the report-only policies would have done.

What a tech lead should take away

Risk policies need P2, and they are the cheapest strong protection against stolen passwords.
Remediate, don’t just block: a secure password change plus revoked sessions fixes a compromised account.
Report-only first, then switch on once the sign-in log matches what you expect.

Do it yourself

Lab guides, practice and full mock exams come with a subscription. See the plans