Microsoft Entra ID Protection Licensing: Costs, Capabilities, and When P2 Actually Delivers ROI

What Entra ID Protection Actually Is — and What It Is Not

Microsoft Entra ID Protection (formerly Azure AD Identity Protection) is a risk detection service that uses Microsoft's threat intelligence signals to identify compromised accounts, risky sign-ins, and identity-based attack patterns in your Entra tenant. It provides three primary capabilities: risk detection and reporting, risk-based Conditional Access policies, and automated risk remediation workflows.

What it is not: a full identity threat detection and response (ITDR) platform, a SIEM, or a replacement for Defender for Identity on-premises active directory monitoring. ID Protection operates exclusively on Entra ID (cloud identity) signals. It does not cover on-premises Active Directory. For hybrid environments where AD compromise is a primary attack vector, Microsoft Defender for Identity fills the on-premises gap and is a separate licence requirement.

The distinction matters commercially because organisations often assume that "comprehensive identity protection" means either product. It does not — it means both, and they are separately licensed at different price points addressing different risk surfaces.

P1 vs P2: The Entra Licensing Architecture

The Entra plan structure is frequently misunderstood. Entra P1 is included in M365 E3 — meaning organisations on E3 already have a substantial Entra capability set. The question for most E3 organisations is not "should we buy Entra?" but "what specific P2 capabilities are we missing, and are they worth the incremental investment?"

Feature	Entra Free	Entra P1 (in M365 E3)	Entra P2
Basic MFA (per-user/Security Defaults)	Yes	Yes	Yes
Conditional Access (standard policies)	No	Yes	Yes
Conditional Access — Sign-in Risk Policy	No	No	Yes
Conditional Access — User Risk Policy	No	No	Yes
Risk-based MFA step-up	No	No	Yes
User risk detection and reporting	No	Limited (7-day report)	Full history + API access
Risky sign-in report	No	Limited (7-day)	Full history + API access
Risk detections API access	No	No	Yes (Graph API)
Automated user risk remediation	No	No	Yes (self-service password reset)
Privileged Identity Management (PIM)	No	No	Yes
Access Reviews	No	No	Yes
Entitlement Management	No	No	Yes

What ID Protection's Risk Engine Actually Detects

The P2 risk detection engine classifies risks into two categories: sign-in risks (anomalies in a specific authentication event) and user risks (signals suggesting an account is compromised). Understanding the detection taxonomy helps determine which user populations benefit most from risk-based CA.

Sign-in Risk Detections

Sign-in risk detections fire during authentication and assess the probability that the authentication event is not from the legitimate user. Key detection types include: anomalous token characteristics (token replay attacks, unfamiliar token properties), atypical travel (sign-in from location physically incompatible with prior sign-in timing), malicious IP address (sign-in from IP associated with known threat actors), and password spray attacks (multiple failed attempts across accounts from the same IP).

The value of sign-in risk detection is that it enables risk-adaptive Conditional Access — a policy that requires MFA step-up or blocks access when a high-risk sign-in is detected, rather than requiring MFA for every sign-in. For organisations where MFA fatigue or usability pressure has led to MFA being selectively disabled or bypassed, risk-based CA provides a commercially defensible middle ground.

User Risk Detections

User risk detections accumulate over time and indicate persistent signs that an account may be compromised. Key detection types include: leaked credentials (credentials appearing in dark web or breach databases monitored by Microsoft), Entra Threat Intelligence (known attack actor targeting), anomalous user activity patterns, and nation-state attribution signals (for high-value targets).

User risk policies can automatically trigger password reset (via Self-Service Password Reset — also a P2 capability) when a user's risk level crosses a threshold. This automated remediation workflow is the feature that most commonly distinguishes the P2 value proposition for security operations teams operating at scale.

The P1 Baseline: What M365 E3 Already Provides

Before assessing whether P2 is justified, establish exactly what M365 E3's Entra P1 delivers for identity security. The E3 baseline is more capable than many organisations realise:

• Conditional Access with any condition except risk: Location-based CA, device compliance CA, app-specific CA, MFA requirements for any access, trusted network exclusions, named locations. The absence of risk-based CA is the P1 limitation, not a general CA absence.
• MFA via Conditional Access: Configurable MFA requirements without per-user MFA, enabling MFA to be applied contextually (e.g., required for external access, trusted IPs excluded).
• Password Protection: Custom banned password lists and smart lockout, preventing the most common credential-based attacks at no P2 cost.
• Identity risk reporting: 7-day risky sign-ins and risky users reports are available at P1. The 7-day window is a genuine limitation for organisations with SOC workflows that require historical data, but for organisations without a dedicated identity investigation capability, the 7-day report captures most operationally relevant signals.
• SSPR (Self-Service Password Reset): Available at P1. Automated password reset in response to user risk requires P2, but SSPR itself is a P1 capability.

The Four Scenarios That Justify P2 ID Protection

Based on deployments across hundreds of enterprise tenants, four scenarios consistently produce positive ROI from Entra P2's ID Protection capability:

Scenario 1: High-Value Account Populations with Elevated Breach Risk

Executives, finance teams, M&A participants, and IT administrators are disproportionately targeted in credential attacks. These populations have access to high-sensitivity data and actions — and the consequence of account compromise is significantly higher than for a general office worker. Scoped P2 deployment to these populations (typically 5–15% of the total user base) provides the risk-based CA and automated remediation that their risk profile warrants, at a fraction of tenant-wide P2 cost.

For a 3,000-user organisation, scoped P2 for 300 high-value accounts costs approximately £15,120–£17,640/year at EA pricing, compared to £151,200–£176,400/year for tenant-wide deployment. The risk reduction on the target population is substantially similar.

Scenario 2: Regulated Industries with MFA and Authentication Logging Requirements

Financial services organisations subject to FCA/PRA operational resilience requirements, DORA, or EBA guidelines face increasing prescriptiveness around authentication assurance levels and audit logging. P2's complete risk detection history (vs. P1's 7-day window) combined with Graph API access for SIEM integration provides the audit trail and control evidence that regulators increasingly require. Healthcare organisations subject to DSPT standards face similar requirements. For these organisations, P2 is a compliance cost rather than a discretionary security investment.

Scenario 3: SOC-Operated Environments with Identity Investigation Workflows

For organisations with a functioning Security Operations Centre that investigates identity-related alerts, the difference between P1's 7-day reporting window and P2's full history with Graph API access is operationally significant. Incident investigations frequently require identity risk history beyond 7 days — particularly for low-and-slow credential compromise attacks that develop over weeks. If your SOC is ingesting Entra identity signals into Sentinel or a third-party SIEM, P2's API access is the enablement layer that makes investigation workflows functional. The SOC without P2 is working with one hand tied behind its back on identity investigations.

Scenario 4: E5 Security Bundle Economics Already Justify the Upgrade

Organisations evaluating the E5 Security add-on (~£10/user/month at EA pricing) receive Entra P2 as part of the bundle alongside MDE P2, MDO P2, MDCA, and MDI. If the E5 Security bundle value case is being assessed primarily on MDE P2 and MDO P2, Entra P2 is effectively free within the bundle economics. This is the scenario in which deploying P2 without incremental cost is appropriate for a broader user population — not because every user needs ID Protection, but because the licences are already held and the deployment cost (configuration, policy design) is the only incremental investment required.

P2 Licensing Cost Model at Enterprise Scale

Deployment Scope	User Count	Annual Cost (EA Pricing)	Appropriate For
Privileged users only	50–150	£2,520–£8,820/year	Organisations with P1 E3 as base, tightly scoped to admins and executives
High-value user population	200–500	£10,080–£29,400/year	Finance, legal, M&A, IT staff + executives in 2,000–5,000 user org
Regulated function subset	500–1,500	£25,200–£88,200/year	Financial services regulated function, all staff with regulatory obligation
Tenant-wide (E5 bundle)	Full org	Included in E5 Security bundle (~£10/user/month blended)	Organisations already evaluating E5 Security bundle on MDE/MDO/MDI grounds
Tenant-wide standalone P2	Full org	£50,400–£176,400/year (1,000–3,500 users)	Rarely justified unless E5 bundle value case exists

The calculation uses a blended EA P2 standalone price of £4.20–£4.90/user/month. Where Entra P2 is obtained via E5 Security bundle, the effective P2 cost is substantially lower — approximately £1.50–£2.00/user/month as an internal allocation within the bundle.

Entra ID Protection vs Standalone ITDR Solutions

Organisations evaluating P2 for ID Protection should also consider whether a dedicated Identity Threat Detection and Response (ITDR) platform — such as CrowdStrike Falcon Identity, Varonis DatAdvantage Cloud, or Semperis DSP — better addresses their specific requirements.

The honest comparison is this: Entra ID Protection is a cloud-identity-only risk detection service built into the identity plane. It is deep on Entra ID signals and integrates natively with Conditional Access. It is not an ITDR platform in the full sense — it does not cover on-premises AD lateral movement, does not provide entity behaviour analysis across the full estate, and does not generate the incident reconstruction data that mature SOC teams need for dwell-time analysis.

For organisations with a functioning SOC and a need for comprehensive identity threat investigation, P2 plus Defender for Identity (for on-premises AD) plus Sentinel ingestion of identity signals provides a credible Microsoft-native ITDR stack. This is not cheap — it requires P2, MDI, Sentinel, and the operational investment to use them — but it is coherent. Deploying P2 in isolation without MDI and Sentinel integration produces reporting data that no one has the operational capacity to act on, which is the most common P2 implementation failure mode.

EA Negotiation Strategy for Entra P2

The commercial approach for Entra P2 follows the same scoped-vs-tenant-wide principle that applies to every premium Entra tier. The specific negotiation positions worth pursuing:

• Audit the P2-justified population before any commercial commitment. The population sizes cited above (50–500 users) are meaningful commercial positions, not symbolic gestures. A 500-user scoped P2 deployment vs 3,000-user tenant-wide represents £50K–£100K annual difference that compounds over the EA term.
• Negotiate P2 as part of the EA renewal, not as a mid-term add-on. Mid-term add-ons for P2 are typically processed at list price or a nominal EA discount. EA-renewal pricing for a defined P2 user subset secures 20–35% better effective pricing than a mid-term request, particularly when the P2 count is bundled with the broader M365 volume discussion.
• Use E5 Security bundle economics as a benchmark ceiling. If Microsoft's standalone P2 pricing is approaching the E5 Security bundle cost on a per-user basis for the target population, the bundle may be commercially superior for the scoped group — providing MDE P2, MDO P2, MDCA, and MDI alongside Entra P2. Model both options before committing to standalone P2. See our E5 Security worth-it guide for the complete bundle economics.
• Request mid-term count reduction provisions for P2 seats. User populations that justify P2 — high-value targets, regulated function staff — change over the EA term due to attrition, restructuring, and role changes. A provision allowing count reduction at EA anniversary prevents overpaying for departed employees in high-risk roles.

The P2 Activation Problem

Organisations that purchase P2 and fail to activate ID Protection's risk policies gain nothing beyond the reporting views. The ID Protection value is delivered through configured risk-based Conditional Access policies — specifically a sign-in risk policy and a user risk policy. These require explicit configuration choices that many organisations defer indefinitely: what risk threshold triggers MFA vs. block, which users are in scope, how self-service remediation is configured for user risk, and how automated remediation interacts with helpdesk workflows.

The activation deferral problem is common: 35–45% of organisations with P2 licences have not activated ID Protection risk policies beyond the default reporting views. In these organisations, P2 is being paid for and providing no incremental security benefit over P1. If your organisation is in this position, the correct commercial question is not whether to renew P2 — it is whether to invest in activation before the renewal conversation, so the P2 ROI is measurable and defensible.

The Four-Question P2 Decision Framework

For most organisations evaluating Entra P2 for ID Protection, four questions determine whether the investment is commercially justified:

1. Have you fully activated and configured all P1 Conditional Access capabilities? If the answer is no, start there. P1 correctly configured delivers 80–90% of the identity security value. P2 without P1 foundation delivers no additional security — it adds risk detection capability on top of a misconfigured identity security base.
2. Do you have a named owner for identity security investigations? If no one in your organisation is responsible for reviewing and acting on the risky sign-in and risky user reports, P2 produces data with no operational consequence. P2 without operational capacity is a licence cost without a security benefit.
3. Do you have a population of users whose compromise would be materially more consequential than average? If yes — and the answer for most organisations is yes, typically 5–15% of users — scoped P2 for that population is commercially rational regardless of the broader upgrade decision.
4. Are you already evaluating E5 Security on other grounds (MDE P2, MDO P2)? If yes, P2 is effectively included and the incremental activation cost is modest. If no, standalone P2 requires its own ROI case on the identity risk detection value alone.

Frequently Asked Questions

Does M365 E5 include Entra P2?

Yes. M365 E5 includes Entra P2 as part of its security stack. Organisations on M365 E5 do not need to purchase Entra P2 separately — the ID Protection capability is available to all E5 users without incremental cost. The activation and configuration work still applies; the licence cost does not.

Can we deploy P2 to some users and P1 to others in the same tenant?

Yes. Entra P1 and P2 are user-licensed, not tenant-licensed. You can assign P2 to a specific population (executives, IT admins, finance team) and P1 to the remainder of the organisation. Risk-based Conditional Access policies apply only to users with P2 licences assigned. Standard Conditional Access policies (location, device, app) apply to all licensed users regardless of P1 or P2. This is the operational foundation for scoped P2 deployment and is the correct commercial approach for most organisations.

Is Entra ID Protection the same as Microsoft Defender for Identity?

No — these are complementary products that address different attack surfaces. Entra ID Protection monitors cloud identity (Entra ID / Azure AD) for risk signals. Microsoft Defender for Identity monitors on-premises Active Directory for lateral movement, credential theft, and domain dominance attacks. A hybrid environment requires both for comprehensive identity threat visibility. MDI is separately licensed (not included in Entra P2) and typically priced within the E5 Security bundle or standalone at approximately £3.50–£4.00/user/month.

Does enabling ID Protection risk policies cause user disruption?

Yes, if not configured carefully. Risk-based Conditional Access policies that block on high-risk sign-ins or require password reset on high-risk users will trigger for legitimate users with unusual sign-in patterns — travelling employees, shared devices, VPN exit nodes. The standard deployment approach is: enable reporting mode first (no policy enforcement, visibility only), review the detection data for 30 days to calibrate thresholds, then enable enforcement for the highest-confidence detections first (high-risk sign-in block, high-risk user password reset), and expand from there. Deploying enforcement without the calibration period is the primary cause of P2 user disruption complaints.

Related Security Licensing Resources

• Microsoft Security Licensing: The Complete Guide
• Entra ID P1 vs P2: Feature and Cost Comparison
• Entra Privileged Identity Management Licensing
• Entra ID Governance Licensing
• Microsoft Defender for Identity Licensing
• Is Microsoft E5 Security Worth It?
• How to Rationalise Your Microsoft Security Stack
• Microsoft Zero Trust Licensing Requirements