Licensing and capability tiers
On this page
Licensing dependencies
The agent must state licensing dependencies without inventing entitlements. Two rules
govern this file:
- Name the capability tier, not the SKU price. "Requires the Entra ID P2 capability
set" is defensible. "Costs $57 per user" is not, and pricing must never be stated unless
backed by a current, cited Microsoft source.
- Entitlement is not assignment. Conditional Access evaluates on assigned licences.
A tenant that owns E5 but has assigned E3 to most users cannot use risk-based policies
for those users. The agent must say this rather than assuming tenant-wide entitlement.
Capability tiers
| Capability | Tier required | Notes |
|---|---|---|
| Conditional Access itself | Entra ID P1 | The baseline for everything in this product |
| Authentication strengths (incl. phishing-resistant) | P1 | benchmark guidance tags 5.2.2.5 as E3, so P1 |
| Device compliance / hybrid join grants | P1 + Intune | The grant is P1; the compliance evaluation is Intune |
| Session controls: sign-in frequency, persistent browser | P1 | |
| Token protection | P1 | benchmark guidance tags 5.2.2.16 as E3 |
| Authentication flow conditions (device code, auth transfer) | P1 | benchmark guidance tags both as E3 L1 |
| Named locations, geographic conditions | P1 | |
| Application-enforced restrictions | P1 | |
| Sign-in risk conditions | Entra ID P2 | ID Protection |
| User risk conditions | Entra ID P2 | ID Protection |
| Risky user / risky sign-in reporting | P2 | |
| Privileged Identity Management | P2 | benchmark guidance |
| Access reviews | P2 (Entra ID Governance) | benchmark guidance–5.3.3 · [VERIFY] — governance packaging has changed |
| Conditional Access App Control session policies | Defender for Cloud Apps | sessionControls.cloudAppSecurity |
| Break-glass monitoring via the benchmark guidance-prescribed method | Defender for Cloud Apps | benchmark guidance — Azure Monitor/Sentinel are accepted alternatives |
| Workload identity Conditional Access | Separate add-on | Not bundled with P1/P2 · [VERIFY] |
The benchmark guidance profile shortcut
The most defensible licensing statement the agent can make comes from benchmark guidance profile tags —
sourced and dated rather than recalled:
A Conditional Access control tagged E3 Level 1 or E3 Level 2 in benchmark guidance v7.0.0 is
achievable with the P1 capability set. A control tagged only E5 requires P2.
For section 5.2.2 this boundary falls exactly on the three risk-based controls:
| Control | Profile | Tier |
|---|---|---|
| 5.2.2.6 Identity Protection user risk policy | E5 L1 | P2 |
| 5.2.2.7 Identity Protection sign-in risk policy | E5 L1 | P2 |
| 5.2.2.8 Block medium/high sign-in risk | E5 L2 | P2 |
| All fourteen others (5.2.2.1–5, 9–17) | E3 L1 or L2 | P1 |
SKU inclusion — stated with appropriate hedging
The agent may state these as the general packaging, always adding that assignment must be
confirmed in the tenant. [VERIFY] — Microsoft repackages SKUs, so treat this table as
an orientation aid rather than a citation.
| SKU | Generally includes |
|---|---|
| Microsoft 365 Business Premium | Entra ID P1, Intune Plan 1 |
| Microsoft 365 E3 | Entra ID P1, Intune Plan 1 |
| Microsoft 365 E5 | Entra ID P2, Intune Plan 1, Defender for Cloud Apps |
| Microsoft 365 F1 / F3 | Varies materially by SKU — do not assume; confirm |
| Entra ID P1 / P2 standalone | The corresponding capability tier only |
| Microsoft Entra Suite | Bundles P2 with additional identity capabilities · [VERIFY] |
Frontline SKUs are the ones most often got wrong. If the user mentions F1 or F3, the agent
should ask rather than assume.
Mixed licensing — the case most often mishandled
Real tenants rarely have one licence. Rules:
- A policy using risk conditions applies meaningfully only to users holding P2. Scoping
such a policy to All users in a mixed tenant is a design error — flag it.
- Scope risk policies to a group containing exactly the P2-licensed users, and keep
that group's membership tied to licence assignment.
- Device-compliance grants require the user to be Intune-licensed and the device
enrolled. Two separate conditions, both of which can fail.
- Where populations differ, propose a tiered baseline: E3 L1 controls tenant-wide, P2
controls scoped to the licensed population. Say explicitly which users get which.
Phrasing patterns
Good:
This design uses sign-in risk as a condition, which requires the Entra ID P2 capability
set — generally included with Microsoft 365 E5. Confirm P2 is assigned to the users in
scope, not merely owned by the tenant; risk conditions do not evaluate for users without
it, so the policy would silently under-apply.
Bad:
You'll need E5, which costs about $57/user/month.
Also bad:
This requires P2. (no mention that assignment must be verified)
What the agent cannot determine
State these as requiring tenant inspection rather than guessing:
- Which licences are actually assigned, and to whom
- Whether an add-on is present
- Whether a capability is GA, preview, or region-restricted in that tenant
- Whether a trial has expired
- Any current price
- Whether a Microsoft-managed policy is already providing part of the coverage