Frequently asked questions around Microsoft Entra ID Protection

This article includes answers to frequently asked questions about Microsoft Entra ID Protection. FAQ sections include: detections, leaked credentials, remediation, licensing, and B2B users.

For more information, see Microsoft Entra ID Protection overview.

Detections

How can I simulate risk to understand why a user is getting flagged?

We have a guide for how to simulate risk. This guide provides several options to simulating different types of risk. You can also use the Conditional Access WhatIf tool to see how specific policies get applied. We also recommend turning on Conditional Access policies in Report-Only mode to understand how policies work in the tenant without affecting your users' ability to access the resources they need.

I just received a high-risk alert but they aren't showing up in the "Impact analysis of risk-based policies" workbook. Why?

If the user is assigned high risk, but hasn't signed-in yet, you won't see them in this report. The report only uses sign-in logs to populate this data.

What if incorrect credentials were used to attempt to sign-in?

ID Protection generates risk detections only when the correct credentials are used. If incorrect credentials are used on a sign-in, it doesn't represent risk of credential compromise.

Is password hash synchronization required?

Risk detections like leaked credentials require the presence of password hashes for detection to occur. For more information about password hash synchronization, see Implement password hash synchronization with Microsoft Entra Connect Sync.

Why are risk detections generated for disabled accounts?

First, it's important to know that user accounts in a disabled state can be reenabled. If the credentials of a disabled account are compromised, and the account gets re-enabled, bad actors might use those credentials to gain access. ID Protection generates risk detections for suspicious activities against these disabled accounts to alert customers about potential account compromise.

If an account is no longer in use and won't be reenabled, customers should consider deleting it to prevent compromise. No risk detections are generated for deleted accounts.

I tried to sort the Risk detections report using the "Detection time" column, but it's not working.

Sorting by Detection time in the Risk detections report might not always give the correct result because of a known technical constraint. To sort by Detection time, open the report in the Microsoft Entra admin center and select Download to export the data as a CSV file and sort accordingly.

Where does Microsoft find leaked credentials? How often are they processed?

Microsoft finds leaked credentials in various places, including:

• Public paste sites where bad actors typically post such material.
• Law enforcement agencies.
• Other groups at Microsoft doing dark web research.

Leaked credentials are processed immediately after they're found, normally in multiple batches per day.

Why am I not seeing any leaked credentials?

Leaked credentials are processed anytime Microsoft finds a new, publicly available batch. Because of the sensitive nature, the leaked credentials are deleted shortly after processing. Only new leaked credentials found after you enable password hash synchronization (PHS) are processed against your tenant. Verifying against previously found credential pairs isn't done.

To see how leaked credentials could appear in ID Protection for your tenant, try simulating leaked credentials in GitHub for Workload Identities. For more information, see Simulate risk detections in Microsoft Entra ID Protection.

If you don't see any leaked credential risk events, it is because of the following reasons:

• You don't have password hash sync enabled for your tenant.
• Microsoft didn't find any leaked credential pairs that match your users.

Remediation

When does ID Protection autoremediate sign-in risk without a risk-based policy in place?

ID Protection autoremediates sign-in risk when the user immediately provides a second factor, such as multifactor authentication (MFA) following their risky sign-in. Providing this second factor composes a strong authentication.

ID Protection also operates two models for risk assessment on sign-ins. The first is the real-time model that uses limited information to make a fast determination during the sign-in. Second is an offline model that uses other sign-in data once the sign-in is complete. The offline model can close risk when it reassesses the risk score as safe. This assessment applies to real-time and offline detections of any risk level.

When does ID Protection autoremediate user risk without a risk-based policy in place?

ID Protection autoresolves users with low user risk after six months without elevation of user risk. Risky users with medium or high risk aren't autoresolved without a risk policy or admin dismissal.

What if I don't use Microsoft Entra for multifactor authentication?

If you don't use Microsoft Entra multifactor authentication, you might still see sign-in risk remediated in your environment if you use a non-Microsoft MFA provider. External authentication methods make it possible to remediate risk when using a non-Microsoft MFA provider.

What are the best Conditional Access controls for accounts that are passwordless?

Check out our guidance on deploying phishing-resistant passwordless authentication: Get started with a phishing-resistant passwordless authentication deployment

Should we add "Enforce sign-in frequency - Every time" to our Conditional Access policies for high risk?

This setting depends on your organization's risk tolerance. Some organizations might choose to block high risk. Enforcing sign-in every time can lead to sign-in or MFA fatigue, which can increase the chance of a phishing attack.

We also recommend turning on Conditional Access policies in Report-Only mode to understand how policies work in the tenant without affecting your users' ability to access the resources they need. You can also check the Impact analysis of risk-based policies workbook in ID Protection.

What if I am in a hybrid environment?

User risk can be self-remediated using a secure password change if self-service password reset is enabled with password writeback. If only password hash sync is enabled, consider enabling allow on-premises password reset to remediate user risk.

For more information, see How to remediate risk and unblock users.

If I deploy a risk policy, will the system autoremediate users differently or do I need to redo past remediations?

The system relies on the grant controls specified in the Conditional Access policy for all remediation. This policy-driven approach gives you more control over access to resources. If the user risk policy requires a block, Conditional Access enforces that. If the sign-in risk policy requires MFA, Conditional Access enforces a new MFA challenge (when there's no MFA claim on an existing token). So, if Alice always had her risky sign-ins autoremediated thanks to another MFA policy, nothing changes in her user experience when you deploy a risk policy that requires MFA.

Licensing

What license do I need to use Microsoft Entra ID Protection?

There are several capabilities in Microsoft Entra ID Protection that require different licenses. For example, you can get limited information in the risky sign-ins report with the Microsoft Entra ID Free license, but you get full access to these reports with the Microsoft Entra ID P2 or the Microsoft Entra Suite license. For more information, see Microsoft Entra ID Protection license requirements.

Microsoft Entra ID Protection also uses signals from Microsoft Defender products that are licensed separately. For more information, see What is Microsoft Entra ID Protection?.

B2B users

Why can't I remediate risky B2B collaboration users in my directory?

The risk evaluation and remediation for B2B users occurs in their home directory, so the guest users don't appear in the risky users report in the resource directory. Admins in the resource directory can't force a secure password reset for these users.

What do I do if a B2B collaboration user was blocked due to a risk-based policy in my organization?

If a risky B2B user in your directory is blocked by your risk-based policy, the user needs to remediate that risk in their home directory. Users can remediate their risk by performing a secure password reset in their home directory. If they don't have self-service password reset enabled in their home directory, they need to contact their own organization's IT Staff to have an administrator manually dismiss their risk or reset their password. For more information, see Remediate user risk.

How do I prevent risk-based policies from affecting B2B collaboration users?

Excluding B2B users from your organization's risk-based Conditional Access policies prevents B2B users from being affected by risk evaluation. To exclude these B2B users, create a group in Microsoft Entra ID that contains all of your organization's guest users. Then, add this group as an exclusion for your built-in ID Protection user risk and sign-in risk policies, and any Conditional Access policies that use sign-in risk as a condition.

This article includes answers to frequently asked questions about Microsoft Entra ID Protection. FAQ sections include: detections, leaked credentials, remediation, licensing, and B2B users.

For more information, see Microsoft Entra ID Protection overview.

We have a guide for how to simulate risk. This guide provides several options to simulating different types of risk. You can also use the Conditional Access WhatIf tool to see how specific policies get applied. We also recommend turning on Conditional Access policies in Report-Only mode to understand how policies work in the tenant without affecting your users' ability to access the resources they need.

If the user is assigned high risk, but hasn't signed-in yet, you won't see them in this report. The report only uses sign-in logs to populate this data.

ID Protection generates risk detections only when the correct credentials are used. If incorrect credentials are used on a sign-in, it doesn't represent risk of credential compromise.

Risk detections like leaked credentials require the presence of password hashes for detection to occur. For more information about password hash synchronization, see Implement password hash synchronization with Microsoft Entra Connect Sync.

First, it's important to know that user accounts in a disabled state can be reenabled. If the credentials of a disabled account are compromised, and the account gets re-enabled, bad actors might use those credentials to gain access. ID Protection generates risk detections for suspicious activities against these disabled accounts to alert customers about potential account compromise.

If an account is no longer in use and won't be reenabled, customers should consider deleting it to prevent compromise. No risk detections are generated for deleted accounts.

Sorting by Detection time in the Risk detections report might not always give the correct result because of a known technical constraint. To sort by Detection time, open the report in the Microsoft Entra admin center and select Download to export the data as a CSV file and sort accordingly.

Microsoft finds leaked credentials in various places, including:

• Public paste sites where bad actors typically post such material.
• Law enforcement agencies.
• Other groups at Microsoft doing dark web research.

Leaked credentials are processed immediately after they're found, normally in multiple batches per day.

Leaked credentials are processed anytime Microsoft finds a new, publicly available batch. Because of the sensitive nature, the leaked credentials are deleted shortly after processing. Only new leaked credentials found after you enable password hash synchronization (PHS) are processed against your tenant. Verifying against previously found credential pairs isn't done.

To see how leaked credentials could appear in ID Protection for your tenant, try simulating leaked credentials in GitHub for Workload Identities. For more information, see Simulate risk detections in Microsoft Entra ID Protection.

If you don't see any leaked credential risk events, it is because of the following reasons:

• You don't have password hash sync enabled for your tenant.
• Microsoft didn't find any leaked credential pairs that match your users.

ID Protection autoremediates sign-in risk when the user immediately provides a second factor, such as multifactor authentication (MFA) following their risky sign-in. Providing this second factor composes a strong authentication.

ID Protection also operates two models for risk assessment on sign-ins. The first is the real-time model that uses limited information to make a fast determination during the sign-in. Second is an offline model that uses other sign-in data once the sign-in is complete. The offline model can close risk when it reassesses the risk score as safe. This assessment applies to real-time and offline detections of any risk level.

ID Protection autoresolves users with low user risk after six months without elevation of user risk. Risky users with medium or high risk aren't autoresolved without a risk policy or admin dismissal.

If you don't use Microsoft Entra multifactor authentication, you might still see sign-in risk remediated in your environment if you use a non-Microsoft MFA provider. External authentication methods make it possible to remediate risk when using a non-Microsoft MFA provider.

Check out our guidance on deploying phishing-resistant passwordless authentication: Get started with a phishing-resistant passwordless authentication deployment

This setting depends on your organization's risk tolerance. Some organizations might choose to block high risk. Enforcing sign-in every time can lead to sign-in or MFA fatigue, which can increase the chance of a phishing attack.

We also recommend turning on Conditional Access policies in Report-Only mode to understand how policies work in the tenant without affecting your users' ability to access the resources they need. You can also check the Impact analysis of risk-based policies workbook in ID Protection.

User risk can be self-remediated using a secure password change if self-service password reset is enabled with password writeback. If only password hash sync is enabled, consider enabling allow on-premises password reset to remediate user risk.

For more information, see How to remediate risk and unblock users.

The system relies on the grant controls specified in the Conditional Access policy for all remediation. This policy-driven approach gives you more control over access to resources. If the user risk policy requires a block, Conditional Access enforces that. If the sign-in risk policy requires MFA, Conditional Access enforces a new MFA challenge (when there's no MFA claim on an existing token). So, if Alice always had her risky sign-ins autoremediated thanks to another MFA policy, nothing changes in her user experience when you deploy a risk policy that requires MFA.

There are several capabilities in Microsoft Entra ID Protection that require different licenses. For example, you can get limited information in the risky sign-ins report with the Microsoft Entra ID Free license, but you get full access to these reports with the Microsoft Entra ID P2 or the Microsoft Entra Suite license. For more information, see Microsoft Entra ID Protection license requirements.

Microsoft Entra ID Protection also uses signals from Microsoft Defender products that are licensed separately. For more information, see What is Microsoft Entra ID Protection?.

The risk evaluation and remediation for B2B users occurs in their home directory, so the guest users don't appear in the risky users report in the resource directory. Admins in the resource directory can't force a secure password reset for these users.

If a risky B2B user in your directory is blocked by your risk-based policy, the user needs to remediate that risk in their home directory. Users can remediate their risk by performing a secure password reset in their home directory. If they don't have self-service password reset enabled in their home directory, they need to contact their own organization's IT Staff to have an administrator manually dismiss their risk or reset their password. For more information, see Remediate user risk.

Excluding B2B users from your organization's risk-based Conditional Access policies prevents B2B users from being affected by risk evaluation. To exclude these B2B users, create a group in Microsoft Entra ID that contains all of your organization's guest users. Then, add this group as an exclusion for your built-in ID Protection user risk and sign-in risk policies, and any Conditional Access policies that use sign-in risk as a condition.