Frequently asked questions Microsoft Entra ID Protection

Dismiss user risk known issues

Dismiss user risk in Microsoft Entra ID Protection sets the actor in the user's risk history in ID Protection to <Admin's name with a hyperlink pointing to user's blade>.

There's a current known issue causing latency in the user risk dismissal flow. If you have a User risk policy, this policy stops applying to dismissed users within minutes of clicking on Dismiss user risk. However, there are known delays with the UX refreshing the "Risk state" of dismissed users. As a workaround, refresh the page on the browser level to see the latest user Risk state.

Frequently asked questions

Why is a user at risk?

The article How To: Investigate risk provides an explanation of why a user is at risk, and how to investigate further.

Why was my sign-in blocked but ID Protection didn't generate a risk detection?

Sign-ins can be blocked for several reasons. It's important to note that ID Protection only generates risk detections when correct credentials are used in the authentication request. If a user provides incorrect credentials, it isn't flagged by ID Protection since there isn't of risk of credential compromise unless a bad actor uses the correct credentials. Some reasons a user can be blocked that don't generate an ID Protection detection include:

  • The IP can be blocked due to malicious activity from the IP address. The IP blocked message doesn't differentiate whether the credentials were correct or not. If the IP is blocked and correct credentials aren't used, it won't generate an ID Protection detection.
  • Smart Lockout can block the account from signing-in after multiple failed attempts.
  • A Conditional Access policy can be enforced that uses conditions other than risk level to block an authentication request.

How can I get a report of detections of a specific type?

Go to the risk detections view and filter by Detection type. You can then download this report in .CSV or .JSON format using the Download button at the top. For more information, see the article How To: Investigate risk.

Why can't I set my own risk levels for each risk detection?

Risk levels in ID Protection are based on the precision of the detection and powered by our supervised machine learning. To customize what experience users are presented, administrator can include/exclude certain users/groups from the User Risk and Sign-In Risk Policies.

Why does the location of a sign-in not match where the user truly signed in from?

IP geolocation mapping is an industry-wide challenge. If you feel that the location listed in the sign-ins report doesn't match the actual location, reach out to Microsoft support.

How can I close specific risk detections like I did in the old UI?

You can give feedback on risk detections by confirming the linked sign-in as compromised or safe. The feedback given on the sign-in trickles down to all the detections made on that sign-in. If you want to close detections that aren't linked to a sign-in, you can provide that feedback on the user level. For more information, see the article How to: Give risk feedback in Microsoft Entra ID Protection.

How far can I go back in time to understand what's going on with my user?

  • The risky users view shows a user's risk standing based on all past sign-ins.
  • The risky sign-ins view shows at-risk signs in the last 30 days.
  • The risk detections view shows risk detections made in the last 90 days.

How can I learn more about a specific detection?

All risk detections are documented in the article What is risk. You can hover over the (i) symbol next to the detection to learn more about a detection.

How do the feedback mechanisms in ID Protection work?

Confirm compromised (on a sign-in) - Informs Microsoft Entra ID Protection that the sign-in wasn't by the identity owner and indicates a compromise.

  • Upon receiving this feedback, we move the sign-in and user risk state to Confirmed compromised and risk level to High.

  • In addition, we provide the information to our machine learning systems for future improvements in risk assessment.

    Note

    If the user is already remediated, don't select Confirm compromised because it moves the sign-in and user risk state to Confirmed compromised and risk level to High.

Confirm safe (on a sign-in) - Informs Microsoft Entra ID Protection that the sign-in was by the identity owner and doesn't indicate a compromise.

  • Upon receiving this feedback, we move the sign-in (not the user) risk state to Confirmed safe and the risk level to None.

  • In addition, we provide the information to our machine learning systems for future improvements in risk assessment.

    Note

    Today, selecting confirm safe on a sign-in doesn't by itself prevent future sign-ins with the same properties from being flagged as risky. The best way to train the system to learn a user's properties is to use a Conditional Access policy with sign-in risk and MFA. When a risky sign-in is prompted for MFA and the user successfully responds to the request, the sign-in can succeed, and help to train the system on the legitimate user's behavior.

    If you believe the user isn't compromised, use Dismiss user risk on the user level instead of using Confirmed safe on the sign-in level. A Dismiss user risk on the user level closes the user risk and all past risky sign-ins and risk detections.

Why am I seeing a user with a low (or higher) risk score, even if no risky sign-ins or risk detections are shown in ID Protection?

Given the user risk is cumulative in nature and doesn't expire, a user might have a user risk of low or higher even if there are no recent risky sign-ins or risk detections shown in ID Protection. This situation could happen if the only malicious activity on a user took place beyond the timeframe for which we store the details of risky sign-ins and risk detections. We don't expire user risk because bad actors are known to stay in customers' environment for long periods of time before ramping up their attack. Customers can review the user's risk timeline to understand why a user is at risk by going to the Microsoft Entra admin center > Protection > Identity Protection > Risky users > select an at-risk user > details drawer > Risk history tab. If you believe the user isn't compromised, use Dismiss user risk through Graph API.

Why does a sign-in have a “sign-in risk (aggregate)” score of High when the detections associated with it are of low or medium risk?

The high aggregate risk score could be based on other features of the sign-in, or the fact that more than one detection fired for that sign-in. And conversely, a sign-in might have a sign-in risk (aggregate) of Medium even if the detections associated with the sign-in are of High risk.

What is the difference between the "Activity from anonymous IP address" and "Anonymous IP address" detections?

The "Anonymous IP address" detection's source is Microsoft Entra ID Protection, while the "Activity from anonymous IP address" detection is integrated from Microsoft Defender for Cloud Apps. While they have similar names and you might see overlap in these signals, they have distinct back-end detections.