On P1 you can see that a user is risky. You cannot see why, or how risky.
Microsoft publishes the split plainly: on Entra ID Free and P1, risky users shows only medium and high risk with no details drawer and no risk history, and risky sign-ins shows no risk detail or risk level at all. Risk policies, alerts and the full reports require P2. That is the whole decision.
- 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
What Entra ID P1 actually gives you here, in Microsoft own words.
This is the most common misunderstanding we correct, and it is settled by a published table rather than by opinion.
- Risky users on Free and P1: limited information, only users with medium and high risk shown, no details drawer and no risk history. So you see a flag and cannot see what caused it, when, or whether it has happened before.
- Risky sign-ins on Free and P1: limited information, with no risk detail and no risk level shown. You can see a sign-in was considered risky and not how risky or why, which makes triage largely guesswork.
- Risk detections: not available on Free, limited on P1 with no details drawer, full on P2. And risk policies, meaning sign-in and user risk policies through ID Protection or Conditional Access including the Microsoft managed remediation policies, are P2 only.
- The practical consequence is that on P1 this is not a cheaper version of identity protection, it is a notification you cannot investigate and cannot act on automatically. Organisations frequently discover this after building a process around it, which is the conversation worth having before rather than after.
Eight things about ID Protection, starting with what your licence actually gives you.
The P1 and P2 split, which decides whether this is usable
Microsoft publishes it in a table. On Free and P1, risky users shows limited information with only medium and high risk users displayed, no details drawer and no risk history, and risky sign-ins shows no risk detail or risk level at all. Risk policies, the overview report, alerts, the weekly digest and full Graph access to risk reports are all P2 only. On P1 you get a signal you cannot act on.
A risk level generated on every sign-in
Microsoft states that during each sign-in, ID Protection runs all real-time sign-in detections and generates a sign-in session risk level indicating how likely the sign-in is compromised, with policies then applied based on that level. This is not a periodic scan producing a report, it is an evaluation at the moment of access, which is what makes risk-based Conditional Access possible.
Risk that remediates itself
Risk-based Conditional Access policies can require a strong authentication method, multifactor authentication, or a secure password reset based on the detected risk level. Microsoft states that if the user successfully completes the access control, the risk is automatically remediated. That is the property that makes this operable by a small team: most risk clears without anybody looking at it.
Three reports, and how a user becomes risky
Risk detections records each risk found. Risky sign-ins reports a sign-in with one or more detections against it. Risky users reports a user who either has one or more risky sign-ins, or has one or more risk detections reported. Knowing that a risky user can arise without a risky sign-in matters when somebody asks why an account is flagged and nothing appears in the sign-in log.
Detections drawn from a genuinely large signal base
Microsoft describes detections built on the analysis of trillions of signals each day from Active Directory, Microsoft Accounts and Xbox, naming anonymous IP address usage, password spray attacks and leaked credentials among the risky behaviours identified. Leaked credentials in particular is a detection almost no organisation could produce for itself.
Some detections need a Defender licence as well
Microsoft is explicit that ID Protection receives signals from Defender products for several detections, so you also need the licence for the product owning that signal. Activity from anonymous IP address, impossible travel, mass access to sensitive files and new country come from Defender for Cloud Apps. Suspicious inbox rules comes from Defender for Office 365. Possible attempt to access the primary refresh token comes from Defender for Endpoint.
Alerts and a weekly digest, both P2
Users at risk detected alerts and the weekly digest are listed as P2 capabilities. For an organisation without anybody watching a portal daily, those notifications are how the signal reaches a human at all, which is another reason the P1 position tends to produce a capability nobody uses rather than a cheaper version of the same control.
The data can leave the portal
Risk data can be exported through Microsoft Graph APIs for processing in a SIEM, connected to Microsoft Sentinel through a data connector, or sent via diagnostic settings to a Log Analytics workspace, archived to a storage account or streamed to Event Hubs. For organisations needing retention beyond what the portal holds, that export path is the answer rather than a workaround.
Four things that decide whether identity risk becomes a control.
We establish the licence position before designing anything
Because on Free and P1 the reports are explicitly limited and risk policies are unavailable. There is no configuration that works around that. Telling an organisation early that their current licence gives them a flag they cannot investigate is more useful than building a process that depends on detail the tier does not include.
We lean on automatic remediation rather than manual review
Microsoft states that when a user successfully completes the required access control, the risk is automatically remediated. Designed properly, the majority of detected risk resolves without anybody looking at it, which is what makes this workable for a team of two. Manual review then handles the residue rather than the volume.
We check which detections your Defender licensing actually enables
Several named detections come from Defender products and require the corresponding licence: impossible travel, mass access to sensitive files, activity from an anonymous IP address and new country from Defender for Cloud Apps, suspicious inbox rules from Defender for Office 365, and the primary refresh token detection from Defender for Endpoint. Knowing which you get avoids expecting detections that will never fire.
We assign the roles deliberately, including the odd ones
The published roles table has some sharp edges. A Security Reader can view everything and cannot give feedback on detections. A Security Operator can dismiss risk, confirm a safe sign-in and confirm compromise but cannot configure policies or reset a password. A Security Administrator has full access to ID Protection and still cannot reset a user password. Those splits need mapping to real people before an incident.
Six UAE situations where identity risk detection earns its licence.
An organisation whose credentials have appeared in a breach
Leaked credentials is one of the named detections, and it draws on a signal base no individual organisation could replicate. Combined with a user risk policy forcing a secure password reset, a credential that surfaced somewhere on the internet becomes a reset the user completes, rather than an account somebody logs into three months later.
A workforce that travels constantly
Impossible travel and new country detections, both sourced from Defender for Cloud Apps, are unusually relevant in a market where staff move between countries weekly. Getting the policy right here matters, because tuned badly it blocks legitimate travel and tuned well it catches the sign-in from somewhere the person demonstrably is not.
A regulated firm expected to act on identity risk
Where a regulator or an auditor asks what happens when a sign-in looks compromised, a risk-based Conditional Access policy that requires multifactor authentication or a secure password reset is a working control with evidence behind it. A report nobody can see the detail of is not, and on P1 that is what you have.
A small team with no capacity for daily review
Automatic remediation is the whole argument here. Risk that clears when the user completes a control does not need a human, and the alerts and weekly digest bring the residue to somebody attention. Without P2 neither the automation nor the notifications exist, which leaves a portal nobody opens.
An organisation being targeted by password spray
Password spray is a named detection, and it is one of the few attacks that looks like nothing from inside a single account: a handful of attempts against many users rather than many attempts against one. Detection at the tenant level is how it becomes visible, and a sign-in risk policy is how it stops mattering.
An organisation feeding a SIEM
Risk data can be exported through Graph, connected to Sentinel through a data connector, or sent through diagnostic settings to a Log Analytics workspace, a storage account or Event Hubs. For anybody correlating identity risk with other telemetry, or retaining it beyond the portal, those paths are what make the signal usable outside the Entra admin centre.
How identity risk is actually handled in UAE 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 UAE market | Uncommon | Common | Common |
Reproduced from the published licensing table.
| Capability | Free and P1 | P2 | |
|---|---|---|---|
| Sign-in and user risk policies | No | Yes | |
| Security reports overview | No | Yes | |
| Risky users report | Medium and high only, no details drawer, no risk history | Full access | |
| Risky sign-ins report | No risk detail or risk level shown | Full access | |
| Risk detections report | Not available on Free, no details drawer on P1 | Full access | |
| Users at risk detected alerts | No | Yes | |
| Weekly digest | No | Yes | |
| MFA registration policy via Conditional Access | No | Yes | |
| Microsoft Graph access to all risk reports | No | Yes | |
| Risky workload identities report | Requires Workload Identities Premium licensing | Requires Workload Identities Premium licensing |
Five steps, and the first one may end the conversation cheaply.
- 1
Establish what your licence enables
Entra ID P1 against P2, plus which Defender products you hold, since several named detections require the corresponding Defender licence. This determines both which risks will ever be detected and whether you can act on them automatically, and it is a short exercise with a decisive answer.
- 2
Review the risk that already exists
Risky users, risky sign-ins and risk detections as they stand today, because tenants that have never configured a policy usually have accumulated risk nobody has looked at. That backlog is worth working before enabling automation, so the first day of policy does not arrive with a queue attached.
- 3
Design the risk policies
Which risk level triggers which control: multifactor authentication, a strong authentication method, or a secure password reset, and at what threshold. Plus exclusions, starting with tested emergency access accounts, since a risk policy is exactly the kind of control that can lock out the people who would fix it.
- 4
Assign roles against the published capability split
Who views, who can dismiss risk and confirm compromise, who configures policy, and who can reset a password, noting that the Security Administrator role explicitly cannot do the last one. Mapping those to real people before an incident is considerably better than discovering the gap during one.
- 5
Connect the outputs and set the review rhythm
Alerts and the weekly digest routed somewhere read, export to a SIEM through Graph, the Sentinel connector or diagnostic settings where you need retention or correlation, and a defined cadence for reviewing the risk that automatic remediation did not clear.
What organisations 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 wider licence comparison, of which identity protection is one of the sharpest differences.
Conditional Access
The policy layer that consumes the risk signal and applies the control that remediates it.
Defender XDR
Where identity risk becomes one of eleven signal sources feeding a correlated incident.
Check whether you are on P1 or P2 before planning anything.
It is a two minute check with a decisive answer. On P2 this is a short configuration project with a real control at the end. On P1 it is a report showing medium and high risk with no detail, no history and no way to act automatically, and no configuration changes that.
Related Services
Explore more solutions that work great with this service
Entra ID P1 vs P2
What P2 genuinely adds, and what quietly moved
Entra Conditional Access
The control that decides who reaches your data
Defender XDR
Eleven signal sources, one incident, and containment without a human
Microsoft Entra
Identity and access management solutions
Passwordless and Passkeys
Three seconds instead of sixty nine, and it cannot be phished
Privileged Identity Management
Just-in-time admin access, approval, and audit history you can download
Microsoft Security Dubai
Entra, Defender, Purview, Sentinel, and what you already own
MFA Solutions
Entra MFA, passwordless, FIDO2