Microsoft Entra Conditional Access Licensing: P1, P2, and What the Free Tier Actually Covers

The Licensing Boundary That Most Organisations Misread

Conditional Access is the most commercially significant feature in the Entra ID product line — and also one of the most misunderstood from a licensing perspective. The common misconception is that Conditional Access requires Entra ID P1 or P2 for all users to whom any CA policy applies. The reality is more nuanced: the licence tier required depends on which CA features are used in the policy, not simply whether a CA policy exists. Getting this boundary right matters commercially. For a 15,000-user enterprise, the difference between P1 for the full population (~$6/user/month = $1.08M/year) and correctly scoped P1 for the users in CA scope who need P1 features (typically 70–80% of users) is $216,000–$324,000 per year. Add the P1-to-P2 segmentation layer for risk-based CA, and the savings compound further.

This article maps the CA licensing structure systematically: what the free tier covers, what P1 adds, what P2 adds, and how to structure your CA policies and licence commitments to align with actual deployment scope.

What the Entra ID Free Tier Covers for Conditional Access

Microsoft provides Security Defaults in the Entra ID Free tier — a preset security baseline that enforces MFA for all users, blocks legacy authentication protocols, and requires MFA for privileged roles. Security Defaults are a binary on/off control. They cannot be customised: you cannot exclude specific applications, create exceptions for service accounts, or apply location-based conditions. For small organisations with homogeneous user populations and no complex application estate, Security Defaults provide adequate baseline security without any Entra licence investment.

The Free tier does not provide configurable Conditional Access policies. Once an organisation requires policy granularity — different MFA requirements for different applications, device compliance conditions, location exclusions for trusted networks, application-specific access controls — it has exceeded the Free tier and requires P1 for the users in scope of those configurable policies. This threshold is reached by virtually every enterprise organisation with more than a handful of applications, any service accounts requiring exemptions, or any requirement to enforce device compliance as a CA condition.

Entra ID P1 Conditional Access — The Core Policy Engine

Entra ID P1 (included in M365 E3, M365 Business Premium, EMS E3, and available as a standalone at ~$6/user/month) provides the full configurable Conditional Access policy engine. P1 CA policies can target users, groups, roles, and applications with conditions based on user identity, device state, location (named locations, trusted networks, country/region), client applications (browser, mobile apps, Exchange ActiveSync, legacy authentication), and sign-in risk level at the P1 feature boundary. The P1 CA control actions include grant controls (require MFA, require compliant device, require domain-joined device, require approved client app) and session controls (sign-in frequency, persistent browser session, application-enforced restrictions for SharePoint/Exchange).

The P1 policy engine is the foundation of a Zero Trust access control model for the vast majority of enterprise use cases. Device compliance enforcement (requiring Intune-compliant devices as a CA grant condition), named location exclusions for on-premises networks, MFA registration enforcement, and legacy authentication blocking are all P1 features that cover the standard enterprise security posture requirements. The commercial implication is that most enterprises can achieve a strong CA-based access control framework entirely within P1, and P2 additions are reserved for specific risk intelligence use cases.

Who Requires P1 Licensing for Conditional Access?

Microsoft's licensing requirement for Conditional Access is that users subject to CA policies must be licensed for the Entra ID tier that covers those policies. For P1 CA policies, the users assigned to or included in the scope of the policy require P1. This creates a practical scoping consideration: if a CA policy targets "All Users," all users in the tenant require P1. If a CA policy targets a specific group (e.g., a "Corporate Device Users" group with 8,000 of 12,000 total users), only the 8,000 users in the group technically require P1 — the 4,000 users not subject to any P1 CA policy do not. In practice, most enterprises apply at minimum a device compliance or MFA enforcement policy to all corporate users, making full-population P1 the correct starting point — but this should be validated against your specific CA policy scope rather than assumed.

Entra ID P2 Conditional Access — Risk-Based Intelligence

The P2 additions to Conditional Access are driven by Identity Protection's risk signals. Sign-in risk assessment evaluates each authentication attempt against Microsoft's threat intelligence: impossible travel (sign-in from London followed by sign-in from Sydney 90 minutes later), anonymous IP address usage, atypical location, malware-linked IP, leaked credentials from Microsoft's breach intelligence feeds. User risk accumulates over time based on sustained anomalous behaviour patterns and confirmed breaches. These risk scores — low, medium, high — can be used as conditions in CA policies: require MFA step-up for medium sign-in risk, block access for high user risk, require password reset for high user risk.

The security value of risk-based CA is material in environments with high-risk access patterns — executive users with broad access, finance staff with payment system access, IT administrators with privileged roles, users who travel extensively and access corporate resources from diverse locations. For a standard back-office population of knowledge workers accessing M365 and line-of-business applications from a consistent set of corporate locations and enrolled devices, the incremental protection of risk-based CA over device compliance + named location + MFA enforcement (all P1) is limited. The risk signal adds its greatest value precisely where the static conditions of P1 CA are hardest to apply: unmanaged access scenarios, privileged accounts, and high-value targets for targeted attacks.

M365 E3/E5 — What's Already Covered

For the majority of enterprise organisations with M365 E3 or E5 licences, the Conditional Access licensing question is simpler than it appears. M365 E3 includes Entra ID P1 for every licensed user — meaning the entire configurable CA policy engine, device compliance enforcement, named locations, authentication strength, and Continuous Access Evaluation are all covered with no additional Entra purchase. The E3 CA investment is already made. The only question is whether any CA policies in your environment use P2 risk-based conditions (sign-in risk, user risk from Identity Protection), and if so, which users are in scope of those policies.

M365 E5 includes Entra ID P2 for every licensed user — so risk-based CA is fully available for all E5-licensed users. For organisations on a mixed E3/E5 estate (E5 for security-intensive roles, E3 for standard users), risk-based CA can be deployed for E5 users without additional Entra P2 purchase, while E3 users' CA policies are limited to P1 features without standalone P2 add-ons. This mixed-population CA deployment is valid and commonly overlooked — it removes the pressure to upgrade the full enterprise to E5 to access risk-based CA for a privileged subset. See our M365 E3 vs E5 comparison for the full upgrade economics analysis.

The Standalone Entra P1 Duplicate Trap

The most common CA licensing error we encounter in EA reviews is standalone Entra ID P1 licences purchased on top of M365 E3. Since M365 E3 already includes Entra P1, standalone Entra P1 is a complete duplicate — $6/user/month for a capability already covered. This error typically originates from a security team requesting Entra P1 for CA deployment before or separately from the M365 E3 rollout, or from a licence consolidation failure during an M365 migration. For a 5,000-user enterprise, standalone Entra P1 on top of M365 E3 costs $360,000/year in pure duplicate spend. The correction is an EA amendment removing the standalone Entra P1 lines — the CA capability is unaffected. Our Entra ID complete licensing guide covers all the M365 inclusion mappings in detail.

EA Negotiation — Three Conditional Access Licence Tactics

1. Remove Standalone Entra P1 on Top of M365 E3

Before any EA renewal, audit your licence manifest for standalone Entra ID P1 or Azure AD Premium P1 line items alongside M365 E3 licences. This duplicate is present in approximately 1 in 6 enterprise EA portfolios we review — often persisting across multiple renewal cycles because it predates the M365 consolidation. The correction is a simple amendment, not a negotiation: Microsoft cannot commercially defend billing for a capability already included in the M365 E3 licence. Prepare the removal as a reconciliation item rather than a discount request — the framing matters for the account team interaction.

2. Scope P2 Risk-Based CA to the Policy Population

If your organisation is evaluating or has deployed risk-based Conditional Access, the P2 requirement is determined by the scope of the risk-based CA policies — not by the total user count. Before accepting a full-population P2 add-on, export the sign-in risk and user risk policy scopes from the Entra admin centre (Protection → Conditional Access → Policies → select risk condition policies → Users and groups). The users in scope of those policies are the P2 requirement. Present this validated population count in your EA negotiation as the P2 anchor. If your security team wants to expand risk-based CA scope in future, negotiate a right-to-expand provision at committed per-user pricing rather than committing full-population P2 upfront. Our Entra P1 vs P2 deep dive provides the full segmentation methodology.

3. Use Entra Suite and Global Secure Access as Competitive Levers

Microsoft is actively pushing Entra Suite (~$12/user/month) — which packages P2, Entra Governance, Entra Verified ID, and Entra Global Secure Access (network access control through the Microsoft SSE infrastructure) — as the evolution of P2. If your account team is positioning Entra Suite as the CA platform of choice, this creates a competitive signal opportunity. Network Security Service Edge (SSE) alternatives — Zscaler Private Access, Cloudflare Zero Trust, Netskope Private Access — provide equivalent or superior Global Secure Access capabilities at comparable or lower cost for many deployment architectures. A formal SSE competitive evaluation at EA renewal time generates 20–25% discount authority on Entra Suite pricing and can redirect the conversation from full-population Suite back to right-sized P2. This is the same competitive dynamics principle we describe in our competitive pressure in EA negotiations guide.