The Phishing-Resistant MFA Licensing Trap
Regulatory pressure for phishing-resistant multi-factor authentication has intensified sharply since 2023. The US CISA Memo M-22-09 requirements, UK NCSC guidance, NIS2 in the EU, and sector-specific mandates from the FCA, PRA, and others have created a procurement driver that Microsoft is exploiting effectively. The default response — upgrade to E5 Security or E5 Compliance to satisfy the phishing-resistant MFA requirement — is frequently unnecessary and always expensive.
Entra Certificate-Based Authentication (CBA) is Microsoft's cloud-native X.509 certificate authentication capability for Entra ID. It allows users to authenticate using a smart card, hardware security token, or software certificate issued by your organisation's PKI — satisfying phishing-resistant MFA requirements without any SMS, voice call, or authenticator app involvement. The licensing reality, however, is more nuanced than Microsoft's sales motion suggests.
This guide covers what CBA is and what it is not, the precise licence requirements for each CBA capability, how it compares to FIDO2 and passkeys, the regulatory context, and how to build a cost-efficient phishing-resistant MFA deployment without unnecessary Entra P2 or E5 expenditure.
Key licensing fact: Entra CBA itself — the ability to authenticate using X.509 certificates against Entra ID — is available to all Entra ID plans including the free tier. The features that require Entra P1 or P2 are Conditional Access policies, which are typically required to enforce CBA as the only permitted authentication method, block legacy authentication, or create differentiated policies by user group or application. Understanding this distinction is the basis of the cost optimisation.
What Entra CBA Actually Is
Entra Certificate-Based Authentication enables an organisation to authenticate users to Entra ID using X.509 digital certificates. The certificate can be stored on a smart card (PIV/CAC cards), a hardware security key (YubiKey with PIV application), or as a software certificate on a managed device. When the user presents the certificate during authentication, Entra ID validates it against the organisation's certificate authority (CA) chain configured in Entra.
This is distinct from both FIDO2 security key authentication (which uses the FIDO2/WebAuthn protocol rather than X.509 certificates) and Microsoft Authenticator passwordless phone sign-in (which uses device attestation and app-based push). Each of these three phishing-resistant methods has different infrastructure requirements, user experience characteristics, and licensing implications — all are available with Entra ID P1, not exclusively P2 or E5.
CBA Use Cases by Organisation Type
CBA has particular relevance in four enterprise contexts:
Government and defence: PIV (Personal Identity Verification) and CAC (Common Access Card) smartcards are the dominant authentication method in US federal and allied defence environments. Entra CBA is the cloud-native path for these organisations to satisfy Federal PKI requirements while accessing Microsoft 365 and Azure.
Regulated financial services: UK and EU financial institutions operating under FCA, PRA, EBA, and DORA requirements increasingly need demonstrable phishing-resistant authentication. CBA with smartcards or hardware tokens provides the audit evidence that regulators can evaluate — more clearly than push-notification-based MFA, which is considered phishing-resistant-with-caveats by most regulatory guidance.
Healthcare: HIPAA compliance, NHS Digital's Data Security and Protection Toolkit, and sector-specific clinical workstation requirements often mandate smartcard authentication for access to clinical systems. CBA bridges the identity from existing smartcard infrastructure into Entra-authenticated Microsoft 365 applications.
Critical infrastructure: Organisations in energy, water, and transport sectors responding to NIS2 and equivalent national regulations that require phishing-resistant authentication for privileged and operational access.
Entra CBA Licensing: The Precise Breakdown
This is where most vendor briefings and Microsoft documentation obscure the commercial reality. The table below clarifies what each tier provides:
| CBA Capability | Entra Free | Entra P1 | Entra P2 | Notes |
|---|---|---|---|---|
| Configure CA trust chain in Entra | Yes | Yes | Yes | Core CBA configuration is free |
| Authenticate with X.509 certificate | Yes | Yes | Yes | The authentication act itself is free |
| CBA as MFA method (satisfy MFA requirement) | Yes (with Security Defaults) | Yes | Yes | Security Defaults enforce MFA broadly |
| Enforce CBA-only authentication via Conditional Access | No | Yes | Yes | CA policies require P1 |
| Block all other MFA methods for specific users/apps | No | Yes | Yes | Requires CA Authentication Strengths |
| Affinity Binding (tie cert to specific user) | No | Yes | Yes | Required for high-assurance deployments |
| Identity Protection risk signals with CBA | No | No | Yes | P2 feature |
| Access Reviews for CBA-requiring applications | No | No (basic only) | Yes (advanced) | P2 adds multi-stage, ML recommendations |
The practical implication: In the vast majority of enterprise CBA deployments, Entra P1 is the required and sufficient licence level. Entra P2 adds Identity Protection risk-based signals and advanced Access Reviews — valuable capabilities, but not required to deploy and enforce phishing-resistant CBA across an enterprise user population. Do not accept a sales proposal that positions E5 or E5 Security as a prerequisite for CBA deployment without challenging that framing.
CBA and Conditional Access Authentication Strengths
Authentication Strengths is the Entra P1 feature that enables organisations to define which authentication methods are considered sufficiently strong for specific Conditional Access policies. For CBA enforcement, Authentication Strengths is the mechanism that says "for access to this application, only X.509 certificate authentication is permitted — no authenticator app, no SMS, no FIDO2."
This is important for regulatory compliance precisely because it provides the enforceable policy layer. An organisation that has CBA configured but only uses it as an optional MFA option (not enforced via CA policy) will have difficulty demonstrating to a regulator that phishing-resistant authentication is actually required. The CA policy + Authentication Strength combination is what creates the auditable enforcement record.
Authentication Strengths includes three built-in strength definitions (Multifactor authentication, Passwordless MFA, and Phishing-resistant MFA) plus the ability to create custom strengths. The Phishing-resistant MFA built-in strength satisfies requirements for CBA, FIDO2, and Windows Hello for Business — all three phishing-resistant methods are included. Custom strengths allow organisations to restrict to a specific subset (e.g., CBA-only, or FIDO2-only) for specific application populations.
CBA vs FIDO2 vs Passkeys: Licensing and Practical Comparison
Organisations implementing phishing-resistant MFA typically choose between these three methods — or combine them for different user populations. The licensing implications are similar but the infrastructure and operational costs differ significantly:
| Method | Licence Required | Infrastructure Required | User Experience | Best For |
|---|---|---|---|---|
| Entra CBA (smartcard/PIV) | Entra P1 (for CA enforcement) | PKI CA, smartcard readers, card issuance process | Card tap + PIN | Regulated industries, shared workstations, existing PKI |
| FIDO2 Security Key (YubiKey etc.) | Entra P1 (for CA enforcement) | FIDO2-certified keys, key management process | Key tap + PIN/biometric | Knowledge workers, remote/hybrid users, no existing PKI |
| Passkeys (device-bound) | Entra P1 (for CA enforcement) | Managed devices with TPM 2.0 | Device biometric/PIN | Modern managed device estates, consumer-style UX |
| Windows Hello for Business | Entra P1 + Windows 10/11 Enterprise | Hybrid/cloud joined devices | Face/fingerprint/PIN | Windows-first managed estates |
The licence requirement is effectively identical across all four options — Entra P1 to enforce the authentication method via Conditional Access. The differentiating cost is infrastructure: CBA requires an enterprise PKI and card issuance process; FIDO2 requires hardware key procurement (YubiKey 5 series costs approximately £40–£60 per key in volume); passkeys require TPM-equipped managed devices. For organisations without existing PKI, FIDO2 security keys or passkeys typically offer a lower total deployment cost than standing up a new certificate authority for CBA.
PKI already in place? Organisations that have an on-premises Microsoft PKI (Active Directory Certificate Services) or a third-party CA already issuing smart card certificates have a strong argument for CBA. The incremental cost to extend that infrastructure to Entra CBA is primarily configuration — no new licence category is required beyond Entra P1. If you're already issuing smart card certificates for on-premises authentication, moving those cards to Entra CBA is often the lowest-cost path to cloud phishing-resistant authentication.
The Regulatory Compliance Question
Organisations implementing phishing-resistant MFA to satisfy a specific regulatory requirement need to confirm that their chosen method satisfies the regulation's technical specification. CBA, FIDO2, and Windows Hello for Business all satisfy NIST SP 800-63B AAL3 and equivalent frameworks. Microsoft Authenticator passwordless (push notification) satisfies MFA requirements but is not universally considered phishing-resistant — it is susceptible to real-time phishing (adversary-in-the-middle) attacks in ways that certificate-based and FIDO2 methods are not.
For UK financial institutions responding to FCA/PRA requirements, DORA-regulated entities, or US organisations subject to OMB M-22-09, CBA and FIDO2 are both suitable. The choice between them should be driven by infrastructure fit and deployment cost rather than regulatory differentiation — both satisfy the requirement at the same Entra P1 licence level.
For NIS2 compliance across EU member states, the specific technical requirements for phishing-resistant authentication are still being interpreted nationally. Entra CBA satisfies the standard in all current interpretations, but organisations should confirm with their compliance team and local regulatory guidance before making the final architecture decision on the basis of a single regulation's requirements.
CBA for Privileged Identity and Break-Glass Accounts
A targeted CBA deployment for privileged accounts is a cost-effective pattern that does not require tenant-wide P1 licensing. In this model, only privileged users (Global Admins, Privileged Role Administrators, Security Administrators, and other Tier 0/Tier 1 roles) are licensed with Entra P2 (for PIM) and governed by a Conditional Access policy that requires phishing-resistant CBA or FIDO2. General users continue with existing MFA methods.
This pattern satisfies the most common regulatory interpretation of phishing-resistant MFA requirements — which typically focus on privileged access rather than all users — while keeping the incremental licence cost proportional to the risk profile. A 5,000-user organisation might have 50–150 privileged users who genuinely need phishing-resistant MFA enforcement, and licensing only those users for the relevant capabilities is commercially and operationally justifiable.
Break-glass accounts (emergency access accounts) should be exempt from CA policies by design and governed through separate break-glass procedures — the phishing-resistant MFA policy should be applied to break-glass accounts through a separate, more restrictive mechanism that does not rely on Conditional Access.
Cost Modelling: CBA Deployment Scenarios
The following cost comparisons illustrate the licensing economics across three typical deployment scenarios:
Scenario 1: 5,000-user regulated financial services organisation, full phishing-resistant MFA enforcement. All users require phishing-resistant MFA (CBA). Existing PKI infrastructure in place. Required: Entra P1 for all 5,000 users at approximately £4.20–£5.50/user/month (depending on whether standalone or bundled through M365 E3) = £252,000–£330,000/year. Infrastructure cost: PKI maintenance (already borne) + smartcard reader deployment for non-managed devices. No CBA-specific licensing premium above P1.
Scenario 2: 5,000-user organisation, privileged users only (100 admins). Only privileged users require phishing-resistant MFA. Required: Entra P2 for 100 users at approximately £7.00–£9.00/user/month = £8,400–£10,800/year. Infrastructure cost: 100 FIDO2 keys at £45 each = £4,500 one-time. Total three-year cost: approximately £35,000. Compare this to the E5 Security upgrade approach Microsoft typically proposes for "phishing-resistant MFA" — at £10/user/month that's £600,000 over three years for 5,000 users. The scoped approach saves £565,000.
Scenario 3: 5,000-user organisation with existing M365 E3 deployment. Entra P1 is already included in E3. Full CBA deployment is available at no incremental licence cost — only the PKI infrastructure or FIDO2 key procurement is needed. This is the most common scenario and the most underexploited: the licence to deploy phishing-resistant MFA is already included in M365 E3, but organisations repeatedly purchase E5 Security add-ons under the mistaken impression that CBA requires E5.
The most common mistake: Accepting a Microsoft proposal that upgrades E3 users to E5 Security to "enable phishing-resistant MFA." Entra P1 (included in E3) is sufficient for CBA deployment and enforcement. E5 Security adds Defender XDR, Entra P2, and MDCA — none of which are required for the authentication method itself. Confirm that the CBA requirement is the real driver before accepting an E5 upgrade proposal.
EA Negotiation Strategy for Entra Authentication Licensing
The negotiation position for Entra CBA and phishing-resistant MFA licensing is straightforward once the architecture is clear:
Confirm your existing P1 entitlement before any discussion. If your organisation is on M365 E3, Business Premium, or EMS E3, Entra P1 is already included. Any sales proposal that prices phishing-resistant MFA as an incremental cost above your current E3 deployment needs to explain what additional capability beyond P1 is being purchased and why it is required for your specific CBA use case.
Scope P2 purchases to the users who genuinely need them. Entra P2's Identity Protection and advanced Access Reviews add real value for privileged users and high-risk populations. They do not add CBA capability above P1. Purchasing P2 for the full user population to serve a privileged-access phishing-resistant requirement is not cost-proportionate. License the privileged population at P2 and maintain the general population at P1.
Use phishing-resistant MFA as a competitive leverage point, not a compliance cost. The migration from on-premises AD-based smart card authentication to Entra CBA represents a commitment to the Microsoft platform. Use that commitment signal in EA renewal negotiations — particularly if you are simultaneously evaluating whether to expand Entra ID usage or consider third-party identity solutions like Okta or Ping. The commercial leverage exists if you create it; it does not exist if you accept the upgrade proposal without challenging it.
For further context on the Entra product family and licensing tiers, see our guides on Entra P1 vs P2 licensing, Entra PIM licensing, and Entra ID Governance licensing.
FAQ
Is CBA supported for all Entra ID authentication scenarios?
Entra CBA supports browser-based authentication and modern authentication clients. It supports both single-factor (the certificate satisfies password) and multi-factor (the certificate satisfies MFA) modes depending on the Certificate Binding Policy configuration. Legacy authentication protocols (Basic Auth, NTLM) are not supported — which is consistent with the security goal of eliminating legacy authentication channels. Organisations with legacy application dependencies should inventory those applications before deploying CBA as a universal enforcement policy.
Does CBA require Hybrid Azure AD Join or full Entra ID join?
Entra CBA works with cloud-only Entra ID users, Hybrid Entra ID joined, and Entra ID joined devices. The join state does not determine CBA eligibility. What matters is that the user's certificate is issued by a CA chain that is registered in Entra ID. For on-premises Active Directory Certificate Services (AD CS), this is typically a straightforward extension of the existing PKI configuration.
Can we combine CBA for some users and FIDO2 for others?
Yes. Authentication Strengths policies can be assigned at the user group or application level. You can deploy CBA for regulated populations that have existing smartcard infrastructure and FIDO2 for other populations — both satisfy the phishing-resistant MFA requirement in the Entra policy framework, and both require Entra P1 for Conditional Access enforcement. Mixed-method deployment is operationally common and fully supported.