Microsoft Entra Certificate-Based Authentication (CBA)

Microsoft Entra ID icon

Microsoft Entra certificate-based authentication (CBA) allows users to sign in to Microsoft Entra ID directly with an X.509 certificate issued by your own public key infrastructure (PKI). Before Entra CBA, certificate authentication to Entra ID required federation with Active Directory Federation Services (AD FS). Today, Entra ID validates the certificate itself, so organizations can deliver passwordless, phishing-resistant authentication with smart cards, virtual smart cards, and TPM-protected certificates without any federation infrastructure.

Last updated: November 9, 2026

How Entra CBA Works

Entra CBA uses mutual TLS between the client and a dedicated Entra ID certificate authentication endpoint. A typical sign-in includes the following steps.

  1. The user accesses an application and enters their username, or selects certificate sign-in.
  2. Entra ID redirects the client to the certificate authentication endpoint (certauth.login.microsoftonline.com for the public cloud), which requests a client certificate.
  3. The user selects a certificate and, for a smart card or Windows Hello for Business certificate, enters a PIN or uses a biometric to unlock the private key.
  4. Entra ID validates the certificate chain against the CAs in the tenant’s trust store and checks revocation using the configured certificate revocation list (CRL).
  5. Username bindings map a field in the certificate to an attribute on a single user object.
  6. The authentication binding policy determines whether the sign-in counts as single-factor or multifactor, and Conditional Access evaluates the result.

Because the private key never leaves the device or smart card and the TLS session is bound to the legitimate Entra ID endpoint, the authentication can’t be captured and replayed by a phishing site.

Benefits

Entra CBA offers several advantages over federated certificate authentication and password-based sign-in, including the following.

  • No AD FS. Certificate authentication happens in Entra ID, eliminating federation servers, Web Application Proxy servers, and their certificates and patching.
  • Phishing resistance. Certificates with smart card or Windows Hello for Business protection satisfy the built-in phishing-resistant MFA authentication strength in Conditional Access.
  • Use your existing PKI. Organizations with smart cards, PIV or CAC credentials, or AD CS deployments can extend them to Entra ID and Microsoft 365.
  • No additional license. Entra CBA is included in every edition of Microsoft Entra ID. Conditional Access and authentication strengths require Microsoft Entra ID P1 or higher.

Configuring Entra CBA

Configuring Entra CBA requires planning in several areas, including the following.

Trusted CAs and the PKI-Based Trust Store

Administrators upload the root and issuing CA certificates that issue user certificates to the Entra ID trust store. Microsoft recommends the PKI-based trust store over the classic trust store. It groups CAs into a container for each PKI, supports up to 250 CAs, and is required for newer features such as issuer hints. Managing the trust store requires the Privileged Authentication Administrator role, and Entra CBA fails if any CA in the chain is missing.

Certificate Revocation

Entra ID checks revocation using CRLs only. OCSP isn’t supported. When planning revocation for Entra CBA, consider the following.

  • Each trusted CA supports one CRL distribution point, and it must be an internet-reachable HTTP URL. LDAP CDPs aren’t supported, so many AD CS deployments need an HTTP CDP published before Entra CBA will work.
  • If a CRL is configured and Entra ID can’t download it because of availability, size, or latency, authentication fails. When a delta CRL is configured, both the base and delta CRLs must be valid and reachable.
  • Enable the Require CRL validation option so authentication fails for certificates issued by a CA with no CRL configured. Disabling CRL checking means certificates can’t be revoked.
  • Entra ID caches CRLs, so a revocation takes effect only after a new base or delta CRL is published and downloaded. For a compromised account, revoke the user’s sessions in Entra ID in addition to revoking the certificate. Shorter certificate lifetimes also help, as I explain in The Case for Short-Lived Certificates in Enterprise Environments.

Username Bindings and Affinity

Username bindings determine how a certificate is mapped to a user account. By default, Entra ID maps the SAN principal name in the certificate to the user’s userPrincipalName. Each binding is classified as low affinity or high affinity.

  • Low affinity. SAN principal name, SAN RFC822 name, Subject, and Issuer and Subject. These match on values that another certificate from a trusted CA could also contain.
  • High affinity. Subject Key Identifier (SKI), SHA1 public key, and Issuer and Serial Number. These identify one specific certificate or key pair and are matched against the certificateUserIds attribute on the user object.

High-affinity bindings are the Entra ID equivalent of strong certificate mapping in Active Directory. Entra CBA is only as secure as the weakest binding configured, so Microsoft recommends using a single binding, or no more than one low-affinity binding. Administrators can require high affinity tenant-wide or for specific issuers or policy OIDs. For hybrid users, certificateUserIds can be populated from the altSecurityIdentities attribute in Active Directory using Microsoft Entra Connect.

Authentication Binding Policy

By default, certificate sign-in is single-factor. Administrators can create rules that classify certificates as multifactor based on the issuing CA, a certificate policy OID, or both. Issuer and policy OID rules take precedence over policy OID rules, which take precedence over issuer rules, and a certificate with conflicting policy OIDs is treated as single-factor. A rule only classifies the certificate and doesn’t add a second factor. Microsoft requires multifactor certificates to be protected by a PIN or biometric, so I recommend classifying certificates as multifactor only when the private key requires one, such as a smart card, virtual smart card, or Windows Hello for Business certificate, ideally identified by a dedicated policy OID issued from a separate template. A TPM-protected certificate without a PIN is a single possession factor, as I explain in Digital Certificates for Strong, Phishing-Resistant Authentication.

Issuer Hints

Issuer hints, generally available in 2026, send the CAs in the tenant trust store to the client during the TLS handshake so the certificate picker shows only certificates issued by trusted CAs. This is a significant usability improvement for users with many certificates. When issuer hints are enabled, the endpoint becomes tenant-specific, and TLS inspection must be disabled for *.certauth.login.microsoftonline.com or certificate authentication fails. Changes can take up to 10 minutes to propagate.

CA Scoping

Previously, any CA in the trust store could issue certificates for any user. CA scoping, also generally available in 2026, restricts a specific CA to a defined Entra ID group, for example, allowing only administrators to authenticate with certificates from a dedicated privileged access CA. Each CA can be scoped to one group, with a maximum of 30 scoping rules. Test scoping rules carefully, because a misconfiguration can lock users out.

Entra CBA and MFA

Entra CBA can be used as a first factor, a second factor, or a complete multifactor credential, including the following combinations.

  • Multifactor certificate. A certificate classified as multifactor satisfies MFA on its own.
  • Single-factor certificate plus another method. CBA as the first factor followed by a passkey, FIDO2 security key, or passwordless phone sign-in.
  • CBA as a second factor. A password followed by a certificate.

Conditional Access authentication strengths control which certificates are accepted. The built-in phishing-resistant MFA strength accepts multifactor CBA, and custom authentication strengths can require certificates from a specific issuer or with a specific policy OID. Users in scope for CBA are considered MFA-capable, so exclude users who haven’t been issued a certificate, or provide a Temporary Access Pass for onboarding. See What is Multifactor Authentication (MFA)? for more on phishing-resistant MFA.

Supported Scenarios

Entra CBA supports a broad range of platforms and applications, including the following.

  • Browser sign-in on all platforms, including mobile native browsers.
  • Microsoft 365 apps on Windows, iOS, and Android, including Outlook and OneDrive.
  • Windows smart card sign-in on Microsoft Entra joined and hybrid joined devices, which returns a primary refresh token (PRT) that includes the MFA claim when the certificate is classified as multifactor. Users must use managed authentication or Staged Rollout rather than federation.
  • iOS native sign-in flows, PRT issuance, and CBA as a second factor, all generally available in 2026.
  • Certificates stored on the device, on smart cards, and on security keys such as YubiKey.

Limitations

Entra CBA has matured considerably, but administrators should be aware of the following limitations.

  • Entra ID doesn’t issue certificates. You must provide your own PKI and deliver certificates to users and devices.
  • Revocation is CRL only, with one HTTP CDP per CA. OCSP and LDAP aren’t supported.
  • Password sign-in can’t be turned off for users enabled for CBA. Use Conditional Access authentication strengths to require certificates.
  • Windows Hello for Business certificates work with Entra CBA in Edge and Chrome, but not in non-browser applications such as Microsoft 365 apps.
  • Web sign-in at the Windows sign-in screen doesn’t support CBA.
  • B2B guests can use CBA only in their home tenant, and the resource tenant must trust home tenant MFA in its cross-tenant access settings.
  • TLS inspection of the certificate authentication endpoint breaks CBA when issuer hints are enabled.

Issuing Certificates for Entra CBA

Entra CBA works with certificates from any CA you trust, including the following common options.

  • Active Directory Certificate Services (AD CS). Smart card, virtual smart card, and Windows Hello for Business certificates issued with templates and autoenrollment, or delivered with Intune using PKCS or SCEP.
  • Microsoft Cloud PKI for Intune. Cloud-hosted CAs with an Intune-hosted HTTP CRL, which meets the Entra CBA revocation requirement without any on-premises infrastructure.
  • Third-party and government PKIs. PIV and CAC credentials and commercial cloud PKI services.

Whichever CA you use, enroll private keys in the TPM or on a smart card so they can’t be exported, use a dedicated template or policy OID for authentication certificates, and plan the username binding before you issue certificates. If the same certificates are also used for Active Directory authentication, such as Always On VPN or Wi-Fi, they must also be strongly mapped. See Strong Certificate Mapping for Intune PKCS and SCEP Certificates.

Moving from AD FS

Organizations that use AD FS only for certificate authentication can move to Entra CBA and retire their federation infrastructure. Configure the trust store, CRLs, and bindings to match the existing AD FS behavior, then use Staged Rollout to move groups of users to managed authentication and validate sign-in before converting the domain from federated to managed.

How I Can Help

I help organizations design and deploy Entra CBA, including the following.

Additional Information

Overview of Microsoft Entra Certificate-Based Authentication (Microsoft Learn)

Microsoft Entra Certificate-Based Authentication Technical Deep Dive (Microsoft Learn)

Set Up Microsoft Entra Certificate-Based Authentication (Microsoft Learn)

Microsoft Entra CBA Certificate Revocation List (Microsoft Learn)

Windows Smart Card Sign-In Using Microsoft Entra CBA (Microsoft Learn)

Microsoft Entra CBA Frequently Asked Questions (Microsoft Learn)

Digital Certificates for Strong, Phishing-Resistant Authentication

What is Multifactor Authentication (MFA)?

Strong Certificate Mapping Enforcement February 2025

Start a Conversation

Planning to deploy Entra certificate-based authentication or retire AD FS? Tell me about your environment, and I’ll follow up, typically within one business day.

← Back

Thank you for your response. ✨