What Is Azure AD Identity Protection? Microsoft Entra ID Protection Explained

What Is Azure AD Identity Protection? Microsoft Entra ID Protection Explained

Originally published 4 October 2020 · Reviewed 5 November 2026

Microsoft Entra ID Protection, called Azure AD Identity Protection until 2023, is the part of Microsoft Entra ID that looks for signs that an account is being attacked or has already been compromised. It converts those signs into risk levels that other controls can act on automatically. This article covers what it detects, how risk drives policy, what you need to license, and how to roll it out without locking people out.

What it detects

ID Protection looks at sign-in behaviour and at threat intelligence. The detections Microsoft documents include:

• Leaked credentials, when a username and password pair appears in data that Microsoft finds in public or criminal sources.
• Anonymous IP addresses, such as sign-ins from anonymising networks.
• Atypical travel, where sign-ins from places far apart happen too close together for the same person to be travelling.
• Unfamiliar sign-in properties, where a sign-in differs from the user's usual pattern.
• Password spray, where one source tries common passwords against many accounts.

Some detections are real-time and some are calculated offline, so a risk level can appear or change minutes or hours after a sign-in. The exact list and names change as Microsoft improves the service, so use the current documentation as the source of truth.

Two kinds of risk

Sign-in risk is the probability that a specific authentication request was not made by the genuine owner. It is calculated for each sign-in and is the right signal for "challenge this sign-in".

User risk is the probability that the account itself is compromised. It builds from detections over time, such as leaked credentials, and stays until remediated. It is the right signal for "this password must change".

Each is reported as low, medium or high, and you choose the levels that trigger action.

Acting on risk

You use risk in Conditional Access policies:

• A sign-in risk policy can require multifactor authentication when a sign-in is medium risk or above. A user who completes the challenge shows that the genuine owner is present, and the risk is dismissed.
• A user risk policy can require a secure password change when user risk is high. For a hybrid user this depends on password writeback, so the change reaches on-premises Active Directory.
• You can also block access, although Microsoft generally prefers remediation by the user so that legitimate users are not locked out and the help desk does not become the control.

You should also take an MFA registration policy into account: users must have registered a method before they can self-remediate.

Reports and investigation

Administrators can review risky users, risky sign-ins and risk detections, confirm that a user is compromised or safe, and dismiss risk after investigation. The data can be exported to a security information and event management system or used through Microsoft Graph. Microsoft's licensing page states that lower tiers see only limited information, for example only medium and high risk users without detail, so full reporting needs P2.

Licensing

Microsoft states that using Microsoft Entra ID Protection requires Microsoft Entra ID P2 licences, and that risk-based Conditional Access policies need that licence. P2 is included in Microsoft 365 E5 and the Microsoft Defender suites listed on Microsoft's licensing page. Conditional Access itself needs only P1, so you can build non-risk policies with P1 and add risk-based ones later.

A safe rollout

1. Confirm licences for the users who will be covered by risk policies.
2. Register everyone for MFA and password reset first, so remediation works without the help desk.
3. Create the policies in report-only mode and read what they would have done for at least a couple of weeks.
4. Exclude emergency access accounts and document every other exclusion.
5. Start with high risk, then widen to medium once the volume of challenges is acceptable.
6. Assign an owner to review risky users every week, and decide how to handle confirmed compromises: reset the password, revoke sessions, review recent activity and mail rules.

Limits

ID Protection is probabilistic. It will miss some attacks and flag some legitimate behaviour, such as people using a VPN. It does not replace strong authentication, device management or monitoring, and it does not apply to everything in your estate. Treat its output as a signal, tune it, and combine it with phishing-resistant authentication for administrators.

What to do when a user is flagged

When a user shows as at risk, treat it like an incident, not a notification. Check the detections that raised the risk, the sign-in locations and the applications involved. If the evidence points to compromise, reset the password, revoke refresh tokens so existing sessions end, require the user to re-register authentication methods if you suspect those were changed, and review mailbox rules, forwarding and recently granted application consents. Then confirm the user as compromised or safe in the portal so the service learns from your decision, and record what you found. If the same pattern repeats for several users, look for a shared cause such as a phishing campaign, a leaked password list, or a misconfigured application.

Microsoft references

• What is Microsoft Entra ID Protection?, reviewed 5 November 2026.
• Microsoft Entra licensing, reviewed 5 November 2026.

This article was first published on 4 October 2020. It was rewritten on 5 November 2026 with current product names and licensing. Microsoft's live documentation takes precedence if it has changed.