Plan your identity investigation

  • 4 minutes

Your journey through identity protection typically starts with the Microsoft Entra ID Protection dashboard. The dashboard provides access to:

  • Reports, such as:
    • Users flagged for risk
    • Risk events
    • Vulnerabilities
  • Settings, such as:
    • Security policies
    • Notifications
    • Multifactor authentication registration

The dashboard is typically an organization's starting point for an investigation. From here, the organization can review the activities, logs, and other relevant information related to a risk event. Based on its findings, an organization can decide whether remediation or mitigation steps are necessary. The findings also enable an organization to understand how someone compromised and used the identity.

Mitigation sign-in risk events

A sign-in risk level is an indication (High, Medium, or Low) of the likelihood the legitimate owner of a user account didn't perform a sign-in attempt.

A mitigation is an action to limit the ability of an attacker to exploit a compromised identity or device without restoring the identity or device to a safe state. A mitigation doesn't resolve previous sign-in risk events associated with the identity or device.

To mitigate risky sign-in attempts automatically, organizations can configure sign-in risk security policies. Organizations can then use these policies to:

  • Consider the risk level of the user or the sign-in to block risky sign-in attempts.
  • Require the user to do multifactor authentication.

These actions can prevent an attacker from exploiting a stolen identity to cause damage. They can also give you some time to secure the identity.

Mitigation best practices

Choosing a High threshold reduces the number of times the system triggers a policy. It also minimizes the effect on users. At the same time, it excludes Low and Medium sign-ins flagged for risk from the policy. By doing so, it might not block an attacker from exploiting a compromised identity.

Best practices to follow when setting a policy include:

  • Exclude users who do not/cannot have multifactor authentication.
  • Exclude users in locales where enabling the policy isn't practical, such as locales with no access to a helpdesk.
  • Exclude users who are likely to generate numerous false-positives, such as developers and security analysts.
  • Use a High threshold during initial policy rollout, or if you must minimize challenges seen by end users.
  • Use a Low threshold if your organization requires greater security. Selecting a Low threshold introduces other user sign-in challenges, but increased security.

To strike a balance between usability and security, the recommended default for most organizations is to configure a rule for a Medium threshold.

The sign-in risk policy is:

  • Applied to all browser traffic and sign-ins using modern authentication.
  • Not applied to applications using older security protocols. To not apply a policy, you must disable the WS-Trust endpoint at the federated IDP, such as ADFS.

User risk

A user's active risk events detected by Microsoft Entra ID contribute to a logical concept known as user risk. A user flagged for risk is an indicator of a potentially compromised user account.

Additional reading. For more information, see Microsoft Entra ID Protection.

A user risk level is an indication (High, Medium, or Low) of the likelihood that someone compromised the user’s identity. The system calculates the user risk level based on the user risk events associated with a user's identity.

The status of a risk event is either Active or Closed. Only risk events that are Active contribute to the user risk level calculation.

The system calculates the user risk level using the following inputs:

  • Active risk events impacting the user.
  • Risk level of these events.
  • Remediation actions the organization completed.

Organizations can use the user risk levels to create conditional access policies. For example, they can create a policy that blocks risky users from signing in. Or they can create a policy that forces the user to securely change their password.

Closing risk events manually

Organizations usually take remediation actions such as a secure password reset to automatically close risk events. However, remediation actions might not always be possible, such as when:

  • Someone deleted a user with active risk events.
  • An investigation reveals the legitimate user performed a reported risk event.

Risk events that are Active contribute to the user risk calculation. As such, organizations might have to manually lower a risk level by closing risk events manually.

During an investigation, you can choose to take one of the following actions to change the status of a risk event:

  • Resolve. Mark an event as Resolved when you take an appropriate remediation action outside Microsoft Entra ID Protection after investigating a risk event, and you believe you closed the event. Resolved events set the risk event’s status to Closed, and the risk event no longer contributes to user risk.
  • Mark as false-positive. In some cases, you can investigate a risk event and discover the system incorrectly flagged it as a risk. You can help reduce the number of such occurrences by marking the risk event as False-positive. Identifying risk events as False-positive helps the machine learning algorithms to improve the classification of similar events in the future. When you mark a risk event as False-positive, its status automatically changes to Closed, and it no longer contributes to user risk.
  • Ignore. If you didn't take any remediation action but you want to remove a risk event from the active list, you can mark the risk event Ignore. By doing so, the system automatically changes the event status to Closed. Because ignored events don't contribute to user risk, you should only use them under unusual circumstances.
  • Reactivate. You can reactivate risk events that you manually closed (by choosing Resolve, False positive, or Ignore). To do so, set the event status back to Active. Reactivated risk events contribute to the user risk level calculation. You can't reactivate risk events closed through remediation (such as a secure password reset).

Remediating user risk events

A remediation is an action to secure a compromised or potentially compromised identity or device. A remediation action restores the identity or device to a safe state. It also resolves previous risk events associated with the identity or device.

To remediate user risk events, organizations can:

  • Complete a secure password reset to remediate user risk events manually.
  • Configure a user risk security policy to mitigate or remediate user risk events automatically.
  • Reimage the infected device.

Microsoft Entra ID Protection notifications

Microsoft Entra ID Protection sends two types of automated notification emails to help organizations manage user risk and risk events:

  • Users at risk detected email
  • Weekly digest email

In response to a detected account at risk, AIP generates an email alert with Users at risk detected as the email Subject. The email includes a link to the Users flagged for risk report. As a best practice, you should immediately investigate the users at risk.

Microsoft Entra ID Protection playbook

The playbook helps organizations understand how Microsoft Entra ID Protection works. It also simulates risk events and vulnerabilities. Organizations can also set up risk-based conditional access policies and test the effect of these policies.

Additional reading. For more information, see Microsoft Entra ID Protection playbook.