The P2 Premium — $3/User/Month That Scales Dramatically
The list price differential between Entra ID P1 (~$6/user/month) and Entra ID P2 (~$9/user/month) is $3/user/month — a modest figure that accumulates aggressively at enterprise scale. For a 10,000-user organisation on M365 E3 (which includes P1 but not P2) that is evaluating P2 for the full enterprise, the annual incremental cost is $360,000. For a 20,000-user organisation, it is $720,000. If P2 is genuinely required for 800 privileged users rather than 10,000, the correctly segmented cost is $28,800/year versus $360,000/year — a $331,200 annual difference from one population segmentation decision. This is the P1 vs P2 question in its commercial form: not "should we have P2?" but "for how many users is P2 actually required?"
Most enterprise organisations that have purchased full-population P2 did so because the security team identified PIM, Identity Protection, or Access Reviews as requirements — legitimate requirements for specific populations — and the commercial process defaulted to the full EA user count rather than the deployment population. The typical outcome is that 8–12% of P2-licensed users are in privileged roles or high-risk populations where P2 adds genuine security value, and 88–92% of P2-licensed users experience zero P2 feature activation beyond the P1 capabilities they already have.
P2 Features — What Each Actually Does and Who Needs It
Privileged Identity Management (PIM) — Target: Privileged Role Holders
PIM provides just-in-time (JIT) privileged access management for Entra ID roles (Global Admin, User Admin, Security Admin, Exchange Admin, etc.) and Azure resource roles (Owner, Contributor, User Access Administrator on subscriptions, resource groups, and resources). PIM replaces permanent standing privileged access with time-limited, approval-based, MFA-enforced activation. The security value is significant: eliminating standing Global Admin access and replacing it with 2-hour JIT activation with approval workflow and audit logging is a material reduction in attack surface and breach impact radius.
Who needs PIM licensing: The users in PIM scope — the accounts whose role assignments are managed through PIM. This includes IT administrators with Azure/Entra privileged roles, security operations staff with Security Reader/Analyst roles, and any account with Owner/Contributor access to production Azure subscriptions or sensitive resource groups. For a 10,000-user enterprise, this is typically 50–300 accounts. The other 9,700–9,950 users have no privileged role assignments to manage via PIM — paying for P2 to enable PIM for those users produces zero security improvement.
Identity Protection — Target: Risk Policy Scope Users
Identity Protection adds risk-based intelligence to Conditional Access policies. Sign-in risk (is this sign-in exhibiting anomalous behaviour — impossible travel, atypical location, malware-linked IP?) and user risk (has this account been detected in credential breach data, or exhibited sustained suspicious behaviour?) are fed from Microsoft's threat intelligence into CA policies that enforce step-up MFA for risky sign-ins or block access for high-risk users. The capability adds a dynamic threat signal layer over the static conditions of P1 Conditional Access.
Who needs Identity Protection licensing: Users in the scope of risk-based CA policies. This is where the segmentation decision requires the most care. If the organisation configures a sign-in risk policy that applies to "All Users" — a common default configuration — then all users in that policy require P2. If the policy is scoped to a privileged user group (administrators, executives, finance team members with payment system access), only those users require P2. The approach of applying risk-based CA to all users is technically valid but commercially expensive if P2 is not otherwise required for the full population. The alternative — applying risk-based CA selectively, combined with full-population P1 standard CA for location/device compliance — maintains strong security posture for the general population while concentrating P2 spend on the highest-risk accounts.
Access Reviews — Target: Reviewed Users and Guest Accounts
Access Reviews enables periodic certification of access rights: who has access to which groups, applications, and privileged roles, with automated review campaigns and removal of access for users whose reviewers certify the access is no longer required. The primary compliance-driven use cases are privileged role certification (quarterly review of who holds Global Admin, Security Admin roles), guest access certification (monthly or quarterly review of active B2B guest accounts), and sensitive application access (bi-annual review of users with access to regulated systems).
Who needs Access Reviews licensing: Users being reviewed in Access Review campaigns require P2 (not the reviewers). For privileged role reviews: the privileged users being reviewed (50–300 accounts). For guest access reviews: the guest accounts under review (External ID guest users require P2 for the reviewed entity — this is a licensing interaction worth validating for large B2B collaboration environments). For application access reviews: users in the application's assignment group. The total P2 requirement for Access Reviews in most enterprises is 200–1,500 users — not 10,000.
Entitlement Management — Target: Governed Access Populations
Entitlement Management provides access package-based provisioning and lifecycle management: creating access packages (bundles of group/app/SharePoint site access), defining approval workflows for access requests, and automating access expiry and review. It is most valuable for organisations with complex multi-system access provisioning needs — onboarding new employees to department-specific resources, managing partner access to specific applications, or automating joiners/movers/leavers access lifecycle without manual IT tickets. The user population that benefits from Entitlement Management access packages requires P2. For organisations using simpler group-based app assignment (a P1 feature), Entitlement Management may not provide sufficient incremental value to justify P2 beyond the PIM and Identity Protection use cases.
| P2 Feature | P2 Required For | Typical Target Population | Full-Pop P2 Justified? |
|---|---|---|---|
| Privileged Identity Management (PIM) | Users in PIM role scope | 50–300 privileged accounts | No — scope to privileged roles |
| Identity Protection (sign-in risk CA) | Users in risk-based CA policy scope | Policy-dependent (500–2,000 if all-users policy) | Only if all-users risk CA is deployed |
| Access Reviews | Users being reviewed | 200–1,500 (privileged + guest + app access) | No — scope to reviewed populations |
| Entitlement Management (access packages) | Users in access package scope | Varies widely by deployment model | Evaluate against P1 group-based assignment |
| P1 (Conditional Access — standard) | All users needing CA policies | Full enterprise population | Yes — P1 for full population, P2 for elevated subset |
M365 E3 vs E5 — The P2 Inclusion Impact
The P1 vs P2 decision is different depending on whether the organisation is on M365 E3 (P1 included, P2 not included) or M365 E5 (P2 included). For M365 E5 organisations, P2 is included for every licensed user — there is no additional Entra P2 cost. The population segmentation question disappears. The relevant commercial question for E5 organisations is whether E5 is itself right-sized (i.e., whether the E5 premium is justified by the combination of Entra P2 + Defender P2 + Purview P2 + Sentinel free ingestion together). Our M365 E3 vs E5 comparison covers this upgrade economics in full.
For M365 E3 organisations, the P2 decision is a standalone incremental purchase that should be scoped to the deployment population. The key trap is that Microsoft's account team will often propose a full-population P2 add-on for M365 E3 renewals based on a security team request — the commercial framing is "you need P2 for your Zero Trust programme" without specifying which users are in scope. A Zero Trust programme does not require P2 for all users; it requires P2 for the users in PIM scope, risk-based CA scope, and Access Review scope — which is a fraction of the enterprise. Our Entra ID complete guide provides the full tier architecture context.
EA Negotiation — Three P2 Tactics
1. Deploy the Population Segmentation Anchor
Before your EA renewal, prepare a P2 deployment population document: export the list of PIM-managed role assignments from Entra admin centre (Privileged Identity Management > Azure AD Roles > Role assignments); export the scope of any risk-based Conditional Access policies (Identity Protection > Sign-in risk policy and User risk policy > Users in scope); and export the Access Review scope from the Identity Governance review definitions. The combined, de-duplicated user count from these three sources is your P2 anchor. Present this as the validated deployment population and propose P2 licensing for this count, with P1 for the remaining users. This is not a request for a discount — it is a request for correct sizing. Microsoft cannot commercially justify P2 for users with no P2 features in scope.
2. Use the Okta Competitive Signal for Discount Authority
Okta Workforce Identity Platform — specifically Okta Identity Governance and Okta Identity Threat Protection — provides PIM-equivalent and risk-based access management capabilities. Okta's governance pricing at EA scale is comparable to Entra P2 list price, but the Microsoft Entra product team has significant discount authority for P2 and the Entra Suite when competitive displacement is documented. A formal competitive evaluation of Okta for your identity governance programme — even if the organisation ultimately retains Entra — generates 20–30% discount authority on standalone Entra P2 lines that is not available through standard EA volume pricing. The evaluation cost ($50–150K for a formal Okta PoC) is typically recovered within 3–6 months of the P2 discount. This is the same dynamic we describe for competitive pressure in Microsoft EA negotiations — applied specifically to the Entra identity layer.
3. Negotiate Right-to-Expand at Committed P2 Pricing
If your organisation is in early stages of PIM deployment or Identity Protection rollout, the P2 population will grow as the programme matures. Rather than committing full-population P2 at signing (Microsoft's preferred position), negotiate a right-to-expand provision: commit the validated current deployment population at P2 pricing with a contractual right to add users at the same per-user rate during the EA term. This approach prevents the pattern of paying for 10,000 P2 licences when 300 are currently deployed, while securing EA pricing for future expansion. The right-to-expand provision is available in Microsoft EA structures and is a standard amendment mechanism — request it explicitly as part of the Entra P2 line negotiation.
PIM population: Entra admin centre → Identity Governance → Privileged Identity Management → Azure AD Roles → Role assignments. Export active + eligible assignments. Count unique users.
Identity Protection population: Entra admin centre → Protection → Conditional Access → policies with "Sign-in risk" or "User risk" conditions. For each policy, check Users → Include. Count users in scope groups.
Access Reviews population: Entra admin centre → Identity Governance → Access Reviews → active review definitions. Export reviewed users from each active review campaign.
Combined P2 count: de-duplicate across all three exports. This is your P2 anchor. Add a 15–20% growth buffer for planned role expansion and submit as the renewal position.
P1 vs P2 in the Context of the Full EA
The P1 vs P2 segmentation decision is one component of a broader identity licensing strategy that intersects with the M365 suite tier, the Microsoft Security stack, and the Intune deployment. For organisations on M365 E3 considering a selective P2 add-on for privileged users, the alternative path of E3-to-E5 upgrade for a subset of privileged users (giving them Entra P2, Defender P2, and Purview P2 together via E5) may produce better economics than standalone P2 for some populations. The M365 E3/E5 hybrid model — E5 for privileged/regulated users, E3 for general population — is a valid commercial structure that our E3 vs E5 guide covers in detail. The integration with Microsoft Security licensing is also relevant: Entra P2 Identity Protection signals feed directly into Microsoft Sentinel risk analytics and Defender for Identity investigations, creating compound value for organisations with mature SOC operations where P2 is deployed to privileged accounts and the security team actively uses the risk intelligence.