What's changed: Created SC-300 Chapter 3 (Domain 2: authentication methods (CBA/TAP/passkeys FIDO2/Authenticator/MFA/SSPR/Windows Hello/password protection/Entra Kerberos); Conditional Access (assignments/controls/session/CAE/authentication context/protected actions/templates/report-only/break-glass exclusion); ID Protection (user/sign-in risk/risky workload id/registration campaigns); Global Secure Access (GSA client/Entra Private Access ZTNA/Entra Internet Access SWG/Internet Access for M365/tenant restrictions)).
3.3Managing risk with Microsoft Entra ID Protection
Understand detecting user risk and sign-in risk with Microsoft Entra ID Protection, risk-based response via Conditional Access, MFA registration campaigns, and monitoring/investigating/remediating risky users/sign-ins/workload identities.
Microsoft Entra ID Protection detects identity risk with machine learning and enables risk-based automated response. The access administrator combines it with Conditional Access to "tighten only when risk rises."
3.3.1User risk and sign-in risk
ID Protection scores two risk types. User risk is "the likelihood the credential is compromised" (e.g., leaked credentials, dark-web detection), remediated by a secure password change. Sign-in risk is "the likelihood the sign-in is not the legitimate user" (e.g., unfamiliar location, anonymous IP, impossible travel), remediated by MFA. Risk-based Conditional Access (or ID Protection policies) automate "high user risk → password change" and "high sign-in risk → MFA." Not confusing the two is a frequent exam point.
3.3.2Monitoring/investigating/remediating and registration campaigns
Admins monitor risky users / risky sign-ins reports, investigate, and remediate (confirm password reset, dismiss/confirm risk). Recently risky workload identities (anomalies in service principals/managed identities) are also covered. To drive MFA adoption, use registration campaigns (nudge to Authenticator), moving users from weak methods like SMS to stronger ones. This runs the "detect → respond → reduce" loop for risk.
Cues: "credential possibly compromised" = user risk → secure password change. "this sign-in is suspicious" = sign-in risk → MFA. "respond automatically by risk" = risk-based CA (with ID Protection). "anomaly in service principal/managed identity" = risky workload identity.
Watch the mix-ups: (1) Distinguish user risk (credential leak → password change) from sign-in risk (this-session anomaly → MFA). (2) ID Protection risk-based policies depend on P2 licensing. (3) Registration campaigns nudge method migration—they are not hard blocks.
3.3.3Section summary
- User risk (leak) → secure password change; sign-in risk (anomaly) → MFA; automate via risk-based CA
- Monitor/investigate/remediate risky users/sign-ins/workload identities
- Registration campaigns drive adoption of stronger MFA (P2 license-dependent)
Sign in to track progress — Log in.
Quick check
(just a quick review)Q1. A user’s credentials were found on the dark web, flagged as likely compromised. What is the best automated ID Protection response?
Q2. Anonymous IP and impossible travel suggest the sign-in is likely not the legitimate user. What is the best automated response?
Q3. Which correctly distinguishes user risk from sign-in risk?
Q4. You want to detect/respond to anomalous behavior of service principals or managed identities. What ID Protection target fits?
Q5. You want to move SMS-dependent users to Microsoft Authenticator and drive registration of stronger MFA. Which is best?