P1 tells you an account is risky. It will not tell you what triggered that, or how bad it is.
The feature table Microsoft publishes settles this without argument. Below P2, the risky users view lists only medium and high risk accounts, with the details drawer and the risk history both absent, while risky sign-ins carries neither a risk level nor any explanation. Everything that turns the signal into a control, the risk policies, the alerting and the complete reports, sits behind P2. Worth settling first, because a security process built on a report you cannot open is a process that quietly does nothing.
- P2Required for risk policies and full reports
- Real timeA risk level generated on every sign-in
- Self-remediatingRisk cleared when the user passes the control
- 600 millionAttacks on Microsoft customers per day, per Microsoft
The capability P1 genuinely delivers, taken straight from the published table.
No question comes up more often than this one, and none is easier to answer, because Microsoft prints the comparison and there is nothing to debate.
- Below P2 the risky users list is cut down to medium and high accounts, with no drawer to open and no history to scroll. A flag appears, and you cannot establish what caused it, when it happened, or whether this account has done the same thing before.
- Risky sign-ins is similarly thin below P2: neither the level nor the reason is displayed. You learn that a sign-in was considered risky, without knowing how risky or on what basis, which leaves triage running on intuition.
- Risk detections is absent entirely on Free, present but shallow on P1 with no drawer, and complete on P2. Risk policies, both the sign-in and user varieties whether configured in ID Protection or Conditional Access, and including the Microsoft managed remediation ones, exist only at P2.
- Taken together, P1 is not identity protection at a lower price point. It is an alert with no way to look into it and no automatic response attached. Most companies work this out only after they have written a runbook around it, which is why the conversation belongs at the start.
Eight things about ID Protection, starting with what your license actually gives you.
Where P1 stops and P2 begins, which decides whether any of this is worth configuring
It is written down in a comparison table. Free and P1 both give a cut-down risky users view, medium and high only, with nothing behind the row and no history to compare against, and a risky sign-ins view that omits the level and the reason. The risk policies themselves, the overview report, the alerting, the weekly digest and unrestricted Graph access to the reports all require P2. What P1 leaves you with is a signal and no lever.
A risk level generated on every sign-in
Every sign-in is scored as it happens. The real-time detections run, a session risk level comes out the other side, and policy acts on that number. Nothing here is a nightly batch job writing a report for someone to read tomorrow, which is precisely why risk can gate access at the moment somebody tries to use it.
Risk that remediates itself
Depending on the level that comes back, the policy can demand a phishing resistant method, a second factor, or a password reset done securely. Complete the challenge and the risk is cleared automatically, with no ticket and no analyst. That single behavior is what makes the capability survivable for a small team, because the bulk of what gets flagged resolves itself.
Three reports, and how a user becomes risky
Three reports, three different things. Risk detections is the raw list of what was found. Risky sign-ins are the sign-ins carrying at least one of those detections. Risky users are accounts with either a risky sign-in against them or a detection reported on them. That second route is the one that catches people out, because an account can be flagged with nothing at all in the sign-in log to explain it.
Detections drawn from a genuinely large signal base
The detection set is built on trillions of daily signals drawn from Active Directory, consumer Microsoft accounts and Xbox. Sign-ins from anonymizing infrastructure, password spray, and credentials found circulating are all named. That last one is the interesting case, because no single company could ever generate that signal from its own telemetry.
Some detections need a Defender license as well
Some detections are not produced here at all, they arrive from Defender, and you need whichever Defender license owns the signal. Cloud Apps supplies activity from an anonymizing address, impossible travel, bulk access to sensitive files and sign-in from a new country. Office 365 supplies suspicious inbox rules. Endpoint supplies the attempt against the primary refresh token.
Alerts and a weekly digest, both P2
Both the users at risk alert and the weekly summary email are P2 features. Where nobody has a portal open all day, and that is most companies, those messages are the only route by which any of this reaches a person. It is another reason P1 tends to end up as a feature nobody opens rather than a budget version of the same protection.
The data can leave the portal
There are three ways out. Graph, for pulling risk into whatever platform your analysts already live in. A native Sentinel connector. Or diagnostic settings, which will write to Log Analytics, park the data in a storage account or push it onto Event Hubs. If you need to keep risk data longer than the portal will hold it, that is the supported route rather than something you have to improvise.
Four things separate identity risk that is a real control from identity risk that is a dashboard.
We establish the license position before designing anything
Below P2 the reports are deliberately restricted and the policies simply are not there. No amount of configuration recovers that. It is more use to a company to hear on day one that their tier gives them a flag they cannot open than to have somebody build a workflow that depends on detail which was never going to appear.
We lean on automatic remediation rather than manual review
Satisfy the control the policy asked for and the risk clears itself. Set up sensibly, most of what gets detected never reaches a person, which is exactly what a small IT team needs. Human review is then dealing with what is left over rather than with the whole stream.
We check which detections your Defender licensing actually enables
A handful of the named detections originate in Defender and depend on holding that product. Cloud Apps carries impossible travel, bulk access to sensitive files, activity from an anonymizing address and new country. Office 365 carries suspicious inbox rules. Endpoint carries the primary refresh token one. Establishing which of those you actually own stops you waiting on detections that were never going to fire.
We assign the roles deliberately, including the odd ones
The role boundaries have some awkward edges. Security Reader sees everything and can feed nothing back on a detection. Security Operator can dismiss risk, mark a sign-in safe and confirm a compromise, but cannot touch policy or reset a password. Security Administrator has the run of ID Protection and still cannot reset a password. Work out which named person holds which of those before you need them, not during.
Six US situations where identity risk detection earns its license.
An organization whose credentials have appeared in a breach
Leaked credentials sits in the named detection list, and the signal behind it is one no single company could ever assemble alone. Pair it with a user risk policy that forces a secure reset and a password found circulating online turns into a reset the person completes that afternoon, instead of an account somebody quietly walks into a quarter later.
A distributed, travel-heavy workforce
For a distributed American workforce, impossible travel and new country carry real weight, and both come from Defender for Cloud Apps. The tuning is the hard part. Too tight and you are stopping a sales lead from working out of a hotel in Denver. Right, and you catch the session from a place the person provably is not.
A regulated firm expected to act on identity risk
When a bank examiner, a SOC 2 auditor or an underwriter renewing your cyber policy asks how a suspicious sign-in gets handled, a risk-based Conditional Access rule that forces a second factor or a secure reset is a control you can demonstrate and evidence. A report whose detail nobody can open is not a control, and below P2 that is what is on the table.
A small team with no capacity for daily review
Self-clearing risk is the entire case for this. Anything the user resolves by completing a challenge never becomes work, and the alerting and weekly summary put whatever is left in front of a person. Neither exists below P2, which leaves a portal that nobody ever has a reason to open.
An organization being targeted by password spray
Password spray is on the named list, and it is unusual in that it is invisible from any one account. Three attempts against four hundred people looks like nothing per person. Only a view across the whole tenant surfaces it, and a sign-in risk policy is what makes it stop being a problem.
An organization feeding a SIEM
Graph, the Sentinel connector, or diagnostic settings to Log Analytics, a storage account or Event Hubs. If you are lining identity risk up against other telemetry, or keeping it for audit and incident work, those routes are what let the signal live anywhere other than the Entra portal.
How identity risk is actually handled in US tenants.
| Feature | P2 with risk policies | P1, report visible only | Nothing configured |
|---|---|---|---|
Risk evaluated on every sign-in | Yes | Yes | Yes |
Risk level visible to you | Yes | No | No |
Reason for the risk visible | Yes | No | No |
Risk history available | Yes | No | No |
Automatic control applied on risk | Yes | No | No |
Risk clears when the user passes the control | Yes | Not applicable | Not applicable |
Alerts and weekly digest | Yes | No | No |
Full risk data through Graph | Yes | No | No |
Leaked credentials acted on automatically | Yes | No | No |
Frequency in the US mid-market | Uncommon | Common | Common |
Reproduced from the published licensing table.
Capability
Sign-in and user risk policies
- Free and P1
- No
- P2
- Yes
Capability
Security reports overview
- Free and P1
- No
- P2
- Yes
Capability
Risky users report
- Free and P1
- Medium and high accounts only, nothing behind the row, no history
- P2
- Full access
Capability
Risky sign-ins report
- Free and P1
- No risk detail or risk level shown
- P2
- Full access
Capability
Risk detections report
- Free and P1
- Not available on Free, no details drawer on P1
- P2
- Full access
Capability
Users at risk detected alerts
- Free and P1
- No
- P2
- Yes
Capability
Weekly digest
- Free and P1
- No
- P2
- Yes
Capability
MFA registration policy via Conditional Access
- Free and P1
- No
- P2
- Yes
Capability
Microsoft Graph access to all risk reports
- Free and P1
- No
- P2
- Yes
Capability
Risky workload identities report
- Free and P1
- Requires Workload Identities Premium licensing
- P2
- Requires Workload Identities Premium licensing
Five steps, and the first can close the whole question inside an afternoon.
- 1
Establish what your license enables
Which Entra tier you are on, and which Defender products sit alongside it, given that several detections will not fire without the matching license. Between them those two answers fix both what can ever be detected and whether anything automatic can happen afterward. It takes very little time and the answer is not ambiguous.
- 2
Review the risk that already exists
We go through the three reports as they stand right now. A tenant that has never had a policy configured has almost always built up flagged accounts that nobody has ever opened. Clearing that first means the day policy goes live is not also the day a backlog lands on somebody desk.
- 3
Design the risk policies
Deciding which level demands what: a second factor, a phishing resistant method, or a secure password reset, and where each threshold sits. Then the exclusions, and the first of those is always a tested break glass account, because a risk policy is precisely the sort of control capable of locking out the only people who could undo it.
- 4
Assign roles against the published capability split
Who reads, who can dismiss and confirm a compromise, who edits policy, and who is able to reset a password, bearing in mind that Security Administrator cannot. Assigning those to named colleagues in advance beats finding the gap at two in the morning.
- 5
Connect the outputs and set the review rhythm
Alerts and the weekly summary pointed at an inbox somebody actually reads, an export path through Graph, the Sentinel connector or diagnostic settings wherever retention or correlation is needed, and a fixed rhythm for working through whatever automatic remediation left behind.
What US organizations ask about Entra ID Protection.
Fifteen questions worth answering first.
Entitlement
- Are you on Entra ID P1 or P2?Risk policies and full reports are P2 only.
- Do you hold Defender for Cloud Apps?Four named detections come from it.
- Do you hold Defender for Office 365?Suspicious inbox rules comes from it.
- Do you hold Defender for Endpoint?Primary refresh token detection comes from it.
- Do you need workload identity risk?That needs separate premium licensing.
Policy design
- What risk level should trigger a control?Policies act on the detected level.
- Should high user risk force a password reset?Secure password reset is one of the options.
- Should sign-in risk require multifactor authentication?The most common configuration.
- Are the Microsoft managed remediation policies in scope?They are part of the P2 capability.
- Who is excluded, and why?Break-glass accounts, at minimum.
When somebody is flagged
- Who reviews risky users, and how often?Automatic remediation handles most, not all.
- Who can dismiss or confirm compromise?Security Operator can, Security Reader cannot.
- Who can reset a password?Not the Security Administrator, per the roles table.
- Are alerts and the weekly digest going somewhere read?Both are P2 capabilities.
- Is risk data exported to a SIEM?Graph, Sentinel connector or diagnostic settings.
The pages around this one.
Entra ID P1 versus P2
The full tier comparison, where identity protection is among the starkest of the differences.
Conditional Access
The layer that takes the risk signal and turns it into the requirement that clears it.
Microsoft Defender
The product family several named detections draw their signals from.
Find out which tier you hold before planning a single thing.
Two minutes of checking gives you an answer that settles everything. With P2 in hand this is a short build ending in a control that genuinely works. Without it, you have a list of medium and high accounts carrying no detail, no history and no automatic response, and no amount of configuration alters that.
Related Services
Explore more solutions that work great with this service
Microsoft Entra Workload Identities
Workload identity governance for US organizations: applications
Learn moreMicrosoft Entra ID P1 and P2 Licensing Review
Independent Entra ID P1 against P2 advice for US organizations:
Learn moreMicrosoft Entra Conditional Access Design
Conditional Access design and review for US organizations:
Learn moreMicrosoft Defender
Advanced endpoint and email threat protection
Learn morePasswordless Authentication and Passkeys
Passwordless authentication rollouts for US organizations using
Learn moreMicrosoft Security Services
The Microsoft security stack deployed and managed end to end
Learn more