Key takeaways

  • There are two risk policies in Conditional Access: user risk, which asks whether the account is probably compromised, and sign-in risk, which asks whether this one sign-in is probably not the real user. Microsoft says not to combine them in one policy.
  • Full ID Protection and risk-based access policies need Microsoft Entra ID P2 (or the Entra Suite). Tenants without P2 see generic "additional risk detected" events without the detail.
  • Microsoft's recommendation: for user risk, require risk remediation at the High level. For sign-in risk, require multifactor authentication at Medium and High.
  • Self-remediation only works if people are registered for multifactor authentication first. Unregistered users are blocked and need an administrator, and hybrid users also need password writeback.
  • Exclude emergency access accounts and service accounts, and run every new policy in report-only mode before turning it on.
  • The older risk policies configured inside ID Protection were scheduled to retire on October 1, 2026. Risk policies belong in Conditional Access now.

What ID Protection does

Microsoft Entra ID Protection watches for signs that an identity is being abused. Microsoft's overview says it detects risky behavior such as anonymous IP address use, password spray attacks and leaked credentials, then lets you investigate and remediate. Detections feed Conditional Access, so an access decision can use the risk level the same way it uses a user's group or a device's state. They can also be sent to a security information and event management (SIEM) tool through Microsoft Graph.

During each sign-in, ID Protection runs the real-time detections and calculates a sign-in risk level. Other detections run offline and raise or lower the account's user risk. You see the results in three reports: risk detections, risky sign-ins and risky users.

Two kinds of risk

User risk is the probability that an account is compromised. Microsoft's list of user-risk detections includes leaked credentials, anomalous token, attacker in the middle and a suspicious credential addition. A password found in a leak is the textbook case.

Sign-in risk is the probability that a particular authentication request is not authorized by the account owner. Its detections include anonymous IP address, atypical travel, password spray, unfamiliar sign-in properties and a suspicious multifactor approval. A user can have a clean account and still produce a risky sign-in, for example when they travel and use a hotel network.

The distinction drives the response. A risky sign-in can usually be settled in the moment, by asking the person to prove it is them. A risky user means the account may already be in the wrong hands, so the safe step is to make the user change the credential and throw out existing sessions.

Licensing: what P2 gives you

Microsoft Learn is direct about this. A Microsoft Entra ID P2 license, or the Microsoft Entra Suite, is required for full access to ID Protection, and risk-based Conditional Access policies need P2. Its table of detections marks each one as Premium or Nonpremium. Leaked credentials and some threat-intelligence detections are available without P2, but many, including atypical travel, password spray and anomalous token, need it. Without P2 you receive detections titled "additional risk detected" with no details. Conditional Access itself needs P1 or higher, so P2 is the step above a normal Conditional Access baseline.

The two policies Microsoft recommends

Both are created in Conditional Access. The Conditional Access Administrator role is the least privileged role for creating or editing them, and Microsoft's remediation article names Security Administrator as the least privileged role for creating or editing risk-based policies.

User risk policy. Microsoft recommends the grant control Require risk remediation when user risk is High. For people who sign in without a password, ID Protection revokes the sessions and they must sign in again. For password users, they are prompted to complete a secure password change after multifactor authentication. When you choose this control, Require authentication strength and Sign-in frequency set to every time are applied automatically. The older Require password change control also exists, and Block access exists too. If a user falls under several of these, Require risk remediation overrides Require password change, and Block overrides all others, so assign each user to one at a time. Require risk remediation is not supported for external and guest users, because Entra does not support session revocation for them.

Sign-in risk policy. Microsoft recommends requiring multifactor authentication when sign-in risk is Medium or High, and adding the sign-in frequency control so risky sign-ins must reauthenticate. A successful strong authentication, such as multifactor authentication or passwordless sign-in, is how a risky sign-in is self-remediated.

Choosing the threshold

Microsoft describes the trade-off plainly. Acting only at High risk means the policy fires less often and costs users less friction, but it leaves Low and Medium events alone, which may not stop an attacker using a compromised identity. Including Medium and Low interrupts more people. A reasonable starting point for a small firm is Microsoft's own recommendation, then a look at the risky sign-in report after a month to decide whether to tighten.

Prepare the people first

Risk policies fail in a predictable way: they block someone who has never registered a second factor. Microsoft's warning is that users must register for multifactor authentication before they face a situation requiring remediation, and that hybrid users synced from on-premises need password writeback enabled. Users who are not ready are blocked and need an administrator. Finish registration for everyone first, using a passkey or another strong method where you can.

Also leave out the accounts that must never be locked out. Microsoft recommends excluding emergency access (break-glass) accounts, and service accounts and service principals. Calls from service principals are not stopped by user-scoped policies; Conditional Access for workload identities covers them.

A safe rollout order

  • Check licensing and roles. Confirm P2 for the users in scope and that two emergency accounts exist and are excluded.
  • Register everyone for multifactor authentication and, for hybrid users, turn on password writeback.
  • Clear current risk. Microsoft advises investigating and remediating any active risks before enabling the policies, so users are not hit with a wall of prompts on day one.
  • Create the user risk policy and the sign-in risk policy as two separate policies, each in report-only mode.
  • Read the report-only results in the sign-in logs for a week or two. Look for legitimate users who would have failed.
  • Turn them on, and watch the risky users and risky sign-ins reports. Where a user is blocked, an administrator can reset the password, dismiss the risk or confirm the account as compromised after looking at the evidence.

Retiring the old way

If your tenant still has the user risk or sign-in risk policy configured inside ID Protection, Microsoft says to migrate it to Conditional Access. Its page states that the legacy policies were scheduled to retire on October 1, 2026. Conditional Access gives you one place to manage access policies, report-only mode and exclusions that the legacy policies lacked.

Our team designs these policies for Microsoft 365 tenants, runs the report-only phase and the registration push, and keeps the break-glass accounts tested.

Sources

This article is general information, not legal or technical advice for your environment. Product menus, license names and provider rules change; check the vendor's current documentation before you act. Last reviewed .

Next article

Related reading

Need help with this?

We find out whether everything you run is safe from attackers, then we fix it.

Cybersecurity