Implement Authentication and Access Management · Topic 5 of 6
Identity Protection and Risk
SC-300 ID Protection: user and sign in risk, risk policies, self remediation with SSPR and writeback, risky workload identities, reports and roles.
- 5 min
- User risk is about the account over time. Sign in risk is about one sign in.
- Risk levels are low, medium and high. Policies live in Conditional Access.
- Self remediation needs MFA registration, and a password change needs SSPR scope and writeback for synced users.
What it is
Microsoft Entra ID Protection uses Microsoft's view of global attacks to detect identity risk and let you respond automatically. It scores two kinds of risk, user risk and sign in risk, and feeds them into Conditional Access so that risky events trigger MFA, a password change or a block.
ID Protection needs Microsoft Entra ID P2 for its full set of detections and reports.
How it works
User risk and sign in risk
| User risk | Sign in risk | |
|---|---|---|
| Question | Is this account likely compromised? | Is this sign in likely not by the real owner? |
| Time | Calculated over time and remains until fixed | Real time or offline, for one sign in |
| Examples of detections | Leaked credentials, anomalous user activity, suspicious API traffic, threat intelligence | Anonymous IP address, atypical travel, unfamiliar sign in properties, malicious IP address, password spray |
Each risk is rated low, medium or high. Atypical travel is a sign in risk, and leaked credentials is a user risk. An administrator account that makes unusual directory changes and then queries users through high volume Microsoft Graph calls can raise the user risk detections Anomalous user activity and Suspicious API traffic.
Risk policies in Conditional Access
Use Conditional Access to respond to risk.
| Policy | Typical setting |
|---|---|
| Sign in risk policy | Medium and above, require multifactor authentication |
| User risk policy | High, require a secure password change |
To remediate user risk with a password change, the user must be able to complete self service password reset. For synchronised users, the user must be in the SSPR scope and password writeback must be enabled, so the new password reaches on premises Active Directory. A user who is not set up for this cannot self remediate and is stuck. Passwordless users who are flagged can be handled by requiring MFA, and a user risk policy that needs a password change fits only users who have a password.
Registration and remediation
- MFA registration can be encouraged with registration campaigns, so that more users are ready to self remediate.
- Self remediation: the user completes the required MFA or password change, and the risk is cleared.
- Administrator remediation: reset the password, or dismiss the user's risk if it is a false positive, or confirm the user as compromised, which raises the risk to high.
Monitoring, investigating and remediating
The reports show what needs attention.
| Report | Shows |
|---|---|
| Risky users | Users at risk, their risk level, and the detections that caused it |
| Risky sign ins | Sign ins flagged as risky and why |
| Risk detections | Every detection with details such as location and IP address |
| Risky workload identities | Applications and service principals at risk |
An investigator reviews the details, decides whether the risk is real, then confirms compromised, dismisses risk, resets the password, or blocks the user. These actions need roles such as Security Operator or Security Administrator, and Security Reader can view.
Risky workload identities
ID Protection also detects risk for workload identities, such as application service principals. A risky service principal can be flagged, investigated, and blocked through a Conditional Access policy that targets workload identities. This needs the Workload ID Premium licence.
Choosing the response
| The scenario | Response |
|---|---|
| Sign in from an anonymous network | Sign in risk policy requiring MFA |
| Credentials found in a leak | User risk policy requiring a password change |
| A synced user flagged high risk cannot change their password | Add them to the SSPR scope and enable password writeback |
| A detection is clearly a false alarm | Dismiss the user's risk |
| An administrator is confirmed hacked | Confirm compromised, reset, and revoke sessions |
| A service principal behaves oddly | Investigate it in risky workload identities, block it with policy |
A worked scenario
A company enables a sign in risk policy that requires MFA at medium risk or above, and a user risk policy that requires a secure password change at high risk. A synchronised user is flagged high risk after a credential leak, but cannot complete the password change. The team finds that the user is not in the SSPR group and that password writeback is not enabled. After adding the user to the group and turning on writeback, the user resets the password and the risk clears. A separate alert for a service principal sends the team to the risky workload identities report, where they block it.
What to remember for the exam
- User risk is about the account over time. Sign in risk is about one sign in.
- Risk levels are low, medium and high. Policies live in Conditional Access.
- Self remediation needs MFA registration, and a password change needs SSPR scope and writeback for synced users.
- Administrators can dismiss risk, confirm compromised, or reset passwords.
- Workload identity risk needs the Workload ID Premium licence.
"Cannot complete the required password change" for a synced user means SSPR scope and password writeback.
How the exam asks about this
- "Two user risk detections that unusual admin activity can raise." Anomalous user activity and Suspicious API traffic.
- "Which risk type is atypical travel?" Sign in risk.
- "Fix a false positive." Dismiss the user's risk.
- "Where do you see risky service principals?" The risky workload identities report.
Common mistakes
Mixing up user risk and sign in risk. One is the account, the other is a single sign in.
Requiring a password change for passwordless users. Require MFA instead.
Forgetting writeback for synced users. They cannot self remediate without it.
Expecting ID Protection to need only P1. The full feature set needs P2.
Check yourself
What is the difference between user risk and sign in risk?
User risk rates whether an account is compromised, and sign in risk rates whether a single sign in is not by the owner.
What does a synced user need to self remediate a password change?
To be in the SSPR scope and have password writeback enabled.
What does dismissing a user's risk do?
It clears the risk when the detection was a false positive.
Topic 5 of 6 in Implement Authentication and Access Management
Test yourself on Implement Authentication and Access Management
The full Microsoft SC-300 question bank has 650 questions, with timed practice exams and an explanation for every answer.
This study guide is independent and is not affiliated with, endorsed by, or sponsored by Microsoft. Vendor names, certification names and exam codes are trademarks of their respective owners and are used for identification only.