2.3.2. Risk-Based Policies and MFA Registration Campaigns
💡 First Principle: Risk response belongs in the same engine as every other access decision. Microsoft deprecated the standalone ID Protection policies in favor of Conditional Access policies with risk conditions — one engine, richer conditions, report-only testing, and exclusions that respect your break-glass discipline.
The two canonical policies: Sign-in risk policy — condition: sign-in risk Medium+ (typical); control: require MFA (grant) — challenge the suspicious event, pass if it's really the user. User risk policy — condition: user risk High (typical); control: require secure password change (grant) — the user must MFA and then set a new password, curing the presumed-stolen credential. Both built as ordinary CA policies: scope to all users minus break-glass and service accounts, dry-run in report-only, watch the insights workbook. Blocking outright is reserved for High sign-in risk when your org prefers hard stops over challenges; remember blocked users generate helpdesk load and blocked ≠ remediated.
Self-remediation is the design goal: with policies wired, a risky sign-in resolves itself via MFA, and a risky user resolves via secure password change — no analyst in the loop for the common cases. For hybrid users, secure password change requires password writeback (2.1.4) to propagate; without it, user-risk policies for synced users should block instead (an exam-favorite dependency).
Registration campaigns close the loop's prerequisite: risk-based MFA only works for users who can MFA. The registration campaign (authentication methods → registration campaign) nudges — or with limited snoozes, effectively requires — users at sign-in to register Microsoft Authenticator (and drives passkey adoption in newer experiences). Combine with a CA policy protecting the register security information user action so attackers can't register their own method on a compromised account from an untrusted network.
⚠️ Exam Trap: "Require password change" for risky users is a grant control with MFA built into the flow, and for synced users it silently depends on password writeback. If a stem says hybrid + user-risk remediation fails, look for writeback before anything exotic.
Reflection Question: Why does Microsoft pair require MFA with sign-in risk but secure password change with user risk — what does each control actually invalidate?
