How to Configure Microsoft Entra ID Certificate-Based Authentication (CBA) for Phishing-Resistant MFA

Traditional Multi-Factor Authentication (MFA) mechanisms, such as SMS codes or standard push notifications, are increasingly vulnerable to Adversary-in-the-Middle (AiTM) phishing attacks. To achieve a true Zero Trust architecture, organisations must adopt phishing-resistant authentication. Microsoft Entra ID Certificate-Based Authentication (CBA) allows enterprises to authenticate users using X.509 certificates—typically stored on smart cards or hardware security keys (like YubiKeys)—directly against Entra ID without requiring federated servers like Active Directory Federation Services (AD FS).

This guide explains how to architect, configure, and enforce cloud-native Certificate-Based Authentication in Microsoft Entra ID to secure your workforce against sophisticated credential theft.

Understanding Cloud-Native CBA

Historically, authenticating with a smart card to Microsoft 365 required an on-premises AD FS infrastructure to perform the certificate validation. Microsoft has since integrated the validation engine directly into Entra ID. When Cloud-Native CBA is enabled, the user presents their client certificate directly to Entra ID.

Entra ID validates the certificate by checking it against your uploaded Certificate Authorities (CAs) and verifying the Certificate Revocation List (CRL) to ensure the certificate has not been revoked. If valid, Entra ID maps the certificate to a user object based on specific attributes (such as the User Principal Name or RFC822 Name) and grants access.

Prerequisites for Entra ID CBA

Before configuring CBA in your tenant, ensure you have the following:

• A Microsoft Entra ID Premium P1 or P2 license (required for Conditional Access enforcement).
• A Public Key Infrastructure (PKI). This can be an on-premises Active Directory Certificate Services (AD CS) environment or a cloud PKI.
• The public certificates of your Root CA and any Intermediate CAs (in .cer or .crt format).
• A publicly accessible HTTP endpoint hosting your Certificate Revocation List (CRL). Entra ID does not support LDAP for CRL checks.

Step 1: Uploading Certificate Authorities to Entra ID

Entra ID must trust the Certificate Authorities that issue your smart card certificates. You must upload the public keys of your Root CA and any subordinate CAs.

Navigate to the Microsoft Entra admin center:

1. Go to Protection > Show more > Security Center.
2. Select Certificate authorities under the Manage section.
3. Click Upload.
4. Select your Root CA’s .cer file.
5. Set the Is root CA toggle to Yes.
6. Enter the publicly accessible Certificate Revocation List (CRL) URL. This is critical; if Entra ID cannot reach the CRL, authentication will fail.
7. Click Add.

Repeat this process for any Intermediate CAs, ensuring you set the Is root CA toggle to No for subordinates.

Step 2: Configuring Username Bindings

When a user presents a certificate, Entra ID must know which user account it belongs to. This is configured through Username Bindings.

1. In the Entra admin center, go to Protection > Authentication methods > Policies.
2. Click on Certificate-based authentication.
3. Under the Configure tab, click Edit.
4. In the Username binding section, configure the mapping logic. The most robust mapping uses the CertificateUserIds property in Entra ID, mapped to the Subject Alternative Name (SAN) of the certificate.
5. Set the Certificate field to PrincipalName (if your PKI populates the UPN in the SAN) and the User attribute to userPrincipalName.

Step 3: Configuring Authentication Binding (MFA)

By default, CBA satisfies single-factor authentication. To ensure it satisfies Multi-Factor Authentication (MFA) requirements, you must map specific certificates (usually based on Policy OIDs or the Issuer) to the MFA claim.

1. Stay on the Configure tab for Certificate-based authentication.
2. Scroll down to the Authentication binding rules section.
3. Click Add rule.
4. Choose the Certificate Issuer or Policy OID that identifies your high-assurance smart card certificates.
5. Under Authentication strength, select Multi-factor authentication.
6. Click Save.

This configuration tells Entra ID: “If a user authenticates with a certificate from this specific issuer, treat it as a strong, multi-factor login.”

Step 4: Enabling the CBA Authentication Method

With the infrastructure and bindings configured, you must explicitly enable the method for your users.

1. On the Certificate-based authentication policy page, select the Enable and Target tab.
2. Toggle Enable to Yes.
3. Under Target, select Select groups (it is highly recommended to roll this out to a pilot group before enabling it for all users).
4. Add your pilot IT security group.
5. Click Save.

Step 5: Enforcing CBA with Conditional Access

The final step is to ensure that users are forced to use their phishing-resistant certificates rather than falling back to vulnerable passwords.

1. Navigate to Protection > Conditional Access > Policies.
2. Click New policy.
3. Name the policy “Require Phishing-Resistant MFA for Admins”.
4. Under Users, select your pilot group or highly privileged roles.
5. Under Target resources, select All cloud apps.
6. Under Grant, select Require authentication strength.
7. Choose Phishing-resistant MFA from the dropdown. This pre-built strength specifically requires FIDO2 keys, Windows Hello for Business, or Certificate-Based Authentication.
8. Set the policy to Report-only for initial testing, then switch to On.

Verifying the Configuration

To verify the setup, have a pilot user attempt to access portal.azure.com from an incognito window. When prompted for their username, they should see a “Sign in with a certificate” option on the Microsoft login screen. Selecting this will prompt their local operating system to request the smart card PIN. Once validated, the user will bypass the password prompt entirely and be granted secure, phishing-resistant access to the tenant.