MFA Registration Policy and Risky User Remediation – SC-300 Exam Guide
Why Is This Important?
Multi-Factor Authentication (MFA) registration policy and risky user remediation are critical pillars of Microsoft Entra ID Protection. In the real world, compromised identities are one of the leading causes of data breaches. Ensuring that users register for MFA before an attack occurs—and having automated policies to remediate risky users—dramatically reduces the blast radius of credential-based attacks. For the SC-300 exam (Microsoft Identity and Access Administrator), this topic falls squarely within the Implement and manage identity protection objective, and you can expect multiple questions on how these features work together.
What Is the MFA Registration Policy?
The MFA Registration Policy in Microsoft Entra ID Protection allows administrators to enforce MFA registration for users. It works through Conditional Access and targets users who have not yet registered for MFA. The policy ensures that all users in scope have at least one additional authentication method registered, so that when a risk-based policy or Conditional Access policy requires MFA, the user can actually satisfy the requirement.
Key characteristics of the MFA Registration Policy:
- It is configured within Entra ID Protection (formerly Azure AD Identity Protection), not directly in Conditional Access (though it leverages Conditional Access under the hood).
- It targets all users or specific groups and can exclude certain users or groups (such as emergency access accounts).
- It prompts unregistered users to complete MFA registration the next time they sign in interactively.
- It does not require a premium license to register for MFA itself, but the policy configuration requires Microsoft Entra ID P2.
- It is separate from sign-in risk and user risk policies, but it complements them by ensuring users are MFA-capable.
What Is Risky User Remediation?
A risky user is a user account that Microsoft Entra ID Protection has flagged because of suspicious activity, such as leaked credentials, sign-ins from anonymous IP addresses, impossible travel, or other threat intelligence signals. The user risk level can be Low, Medium, or High.
Risky user remediation refers to the process of bringing a compromised or potentially compromised user back to a secure state. There are two primary approaches:
1. Self-Remediation (Automated)
- A User Risk Policy is configured in Entra ID Protection.
- When a user's risk level meets or exceeds the configured threshold (e.g., High), the policy automatically requires the user to perform a secure password change using MFA.
- This is why the MFA Registration Policy is so important: if the user hasn't registered for MFA, they cannot self-remediate. They will be blocked instead.
- After the user successfully changes their password via MFA, the user risk is automatically dismissed.
2. Administrator Remediation (Manual)
- An administrator can manually dismiss the user risk in the Entra ID Protection portal.
- An administrator can manually reset the user's password.
- An administrator can confirm that the user is compromised, which forces the risk to High and can trigger additional policies.
- Administrators can also use Microsoft Graph API to manage risky users programmatically.
How It All Works Together
Here is the typical flow:
1. MFA Registration Policy is enabled → Users register for MFA at their next interactive sign-in.
2. User Risk Policy is configured with a threshold (e.g., High) and the action set to Require secure password change.
3. Sign-In Risk Policy (optional but recommended) is configured to require MFA for risky sign-ins at Medium or above.
4. A threat is detected (e.g., leaked credentials appear on the dark web) → The user's risk level is elevated to High.
5. At the user's next sign-in, the User Risk Policy fires → The user must authenticate with MFA and then change their password.
6. Once the password is changed, the user risk is automatically remediated, and the risk state changes to Remediated.
Key Configuration Details
- License Requirement: Microsoft Entra ID P2 (or equivalent, such as Microsoft 365 E5) is required for Identity Protection policies including MFA registration policy, user risk policy, and sign-in risk policy.
- Exclusions: Always exclude at least one emergency access (break-glass) account from all risk policies and the MFA registration policy to avoid lockout.
- Policy Scope: You can target all users or specific groups. Best practice is to start with a pilot group before rolling out broadly.
- Risk Levels: User risk is calculated based on offline detections (e.g., leaked credentials, threat intelligence). Sign-in risk is calculated in real-time during the authentication flow.
- Self-Service Password Reset (SSPR): For self-remediation to work, SSPR must be enabled because the secure password change leverages SSPR combined with MFA.
- Combined Registration: Microsoft recommends enabling combined security information registration so users register for both MFA and SSPR in a single experience.
Important Distinctions for the Exam
- User Risk vs. Sign-In Risk: User risk is associated with the identity (the user account itself is considered compromised). Sign-in risk is associated with a specific authentication request (that particular sign-in looks suspicious). They are different policies with different remediation actions.
- User Risk Policy remediation action: Require secure password change (which requires MFA first).
- Sign-In Risk Policy remediation action: Require MFA.
- Dismiss vs. Confirm Compromised: Admins can dismiss a user's risk (clears it) or confirm the user is compromised (elevates risk to High and revokes tokens).
- Block vs. Allow with remediation: If you set the user risk policy to Block access, the user cannot self-remediate. The recommended approach is to Allow access but Require password change.
Exam Tips: Answering Questions on MFA Registration Policy and Risky User Remediation
Tip 1: If a question asks how to ensure users can self-remediate when their risk level is elevated, the answer always involves two things: (a) enabling the MFA Registration Policy (so users have MFA registered), and (b) configuring the User Risk Policy to require a secure password change. Both are needed.
Tip 2: Remember that SSPR must be enabled for self-remediation. If a scenario says SSPR is disabled, users will not be able to self-remediate through password change, and an admin must intervene.
Tip 3: When a question mentions that a user is blocked and cannot sign in after being flagged as risky, check whether the policy is set to Block rather than Allow access with password change required. Also check whether the user has registered for MFA.
Tip 4: The MFA Registration Policy is found under Entra ID Protection → MFA registration policy, not under Conditional Access directly. However, Microsoft is migrating risk policies into Conditional Access, so be aware that newer exam questions may reference configuring user risk and sign-in risk conditions within Conditional Access policies.
Tip 5: Always exclude break-glass accounts. If an exam question presents a scenario where all admins are locked out after enabling a risk policy, the correct remediation is to use emergency access accounts, and the preventive measure is to exclude those accounts from the policy.
Tip 6: Entra ID P2 is required. If a question states that the tenant only has Entra ID P1 or Free, Identity Protection risk policies (including MFA registration policy) are not available. In that case, MFA can still be enforced through standard Conditional Access (P1) or Security Defaults (Free), but the risk-based automation will not work.
Tip 7: If a question asks about programmatic management of risky users (bulk dismiss, bulk confirm compromised), the answer is the Microsoft Graph API (specifically the riskyUsers endpoint).
Tip 8: Pay attention to the difference between risk state values: At risk (active risk detected), Remediated (risk was resolved automatically or by user), Dismissed (admin manually cleared the risk), and Confirmed compromised (admin confirmed the account is compromised).
Tip 9: For scenarios involving Conditional Access migration of risk policies, note that Microsoft now recommends creating user risk and sign-in risk conditions directly in Conditional Access rather than using the legacy Identity Protection policy blades. Exam questions may test whether you know that the grant control for user risk in Conditional Access is Require password change (which implicitly requires MFA).
Tip 10: A common exam trap: requiring only MFA for user risk. MFA alone does not remediate user risk—a password change is required because the user's credentials are considered compromised. MFA is the appropriate remediation for sign-in risk, not user risk.
Summary
The MFA Registration Policy ensures users are prepared for MFA challenges before threats arise. The User Risk Policy automates the remediation of compromised accounts by requiring MFA-verified password changes. Together, these features form a powerful automated defense mechanism in Microsoft Entra ID Protection. For the SC-300 exam, focus on understanding the interplay between these policies, the licensing requirements, the distinction between user risk and sign-in risk, and the prerequisites (SSPR, MFA registration) that make self-remediation possible.
