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

The standard model of Multi-Factor Authentication (MFA)—specifically SMS text messages and Authenticator App push notifications (e.g., “Tap Approve”)—is fundamentally broken. Attackers routinely bypass these mechanisms using Adversary-in-the-Middle (AiTM) phishing proxies like Evilginx2. The proxy sits between the user and Microsoft 365, intercepts the username, the password, and the MFA push approval, and steals the resulting session cookie, completely compromising the account.

To stop AiTM attacks, enterprise architecture must shift to Phishing-Resistant MFA.

Historically, federal governments and defense contractors achieved this using Smart Cards (PIV/CAC). When a user inserts a Smart Card into their laptop, the browser uses the physical cryptographic chip on the card to sign the authentication request. Because the cryptographic private key never leaves the card, it is mathematically impossible for a phishing proxy to intercept or steal it.

Microsoft now natively supports this architecture in the cloud via Entra ID Certificate-Based Authentication (CBA). You no longer need complex, on-premises Active Directory Federation Services (AD FS) servers to authenticate Smart Cards or YubiKeys. Entra ID handles the x.509 certificate validation directly in the cloud.

This guide explains how to deploy Entra ID CBA for phishing-resistant Zero Trust authentication.

Understanding the CBA Architecture

Entra ID CBA relies on Public Key Infrastructure (PKI):

1. The Certificate Authority (CA): Your organization must have an internal CA (like Microsoft AD CS or Intune Cloud PKI). This CA issues the client certificates (the identities) and signs them.
2. The Trust Anchor: You upload the public root certificate of your CA directly into Entra ID. This tells the Microsoft cloud: “Trust any client certificate signed by this specific CA.”
3. The Hardware Token: The user is issued a YubiKey (a hardware security key) or a traditional Smart Card. The user’s specific client certificate and its un-exportable private key are loaded onto this physical token.
4. The Authentication: When the user accesses portal.office.com, Entra ID challenges them. The user inserts the YubiKey, types their physical PIN (to unlock the token), and the YubiKey cryptographically signs the challenge. Entra ID verifies the signature against the trusted root CA and grants access.

Step 1: Uploading the Root Certificate to Entra ID

Before Entra ID will accept any client certificates, it must know who your Certificate Authority is.

1. Navigate to the Microsoft Entra admin center (entra.microsoft.com).
2. Go to Protection > Show more > Security Center > Certificate authorities.
3. Click Upload.
4. Select your Root CA’s public certificate file (usually a .cer or .crt file). Do not upload the private key.
5. Certificate Authority Type: Select Root (or Intermediate if you are uploading a subordinate CA).
6. Certificate Revocation List (CRL) URL: This is critical. You must provide a publicly accessible HTTP URL where Entra ID can download your CRL. If an employee is terminated, you revoke their certificate on your CA. Entra ID checks this URL to ensure the certificate hasn’t been revoked.
7. Click Add.

Step 2: Configuring Username Bindings

When the user presents their Smart Card, Entra ID needs to know who this certificate belongs to. You must configure the binding rules.

1. Navigate to Protection > Authentication methods > Certificate-based authentication.
2. Click Configure.
3. Navigate to the Rules tab.
4. Under Username binding, you define how Entra maps the certificate fields to the Entra ID user object. The most secure and common method is mapping the Subject Alternative Name (Principal Name) on the certificate to the UserPrincipalName in Entra ID.

Step 3: Enforcing MFA Status

Not all certificates are created equal. A certificate installed in the software registry of a laptop is highly vulnerable to extraction by malware. A certificate locked inside a YubiKey (hardware-bound) is highly secure.

You must tell Entra ID which certificates qualify as “Multi-Factor Authentication” (MFA) and which only qualify as “Single-Factor” (replacing a password, but still requiring an Authenticator app push).

Still on the Rules tab, under Authentication binding:

1. Create a rule based on the Certificate Issuer or Policy OID.
2. For example, if your CA issues certificates with a specific Policy OID for Hardware Smart Cards, configure the rule: If Policy OID = 1.2.3.4.5, then Protection Level = Multi-Factor Authentication.

If the user authenticates with a software certificate, Entra will log them in (single factor) but will immediately prompt them for an Authenticator push to satisfy the MFA requirement.

Step 4: Enabling the Policy and Conditional Access

Finally, you turn the feature on.

1. On the Basics tab of the CBA settings, set Enable to Yes.
2. Target a specific pilot group of users (e.g., IT Administrators).
3. Save the policy.

To enforce the phishing-resistant architecture, you must update your Conditional Access policies.

1. Navigate to Protection > Conditional Access.
2. Create a policy targeting the IT Administrators group.
3. Under Grant controls, do not select “Require multifactor authentication” (which allows vulnerable Authenticator app pushes). Instead, select Require authentication strength.
4. Choose the built-in Phishing-resistant MFA strength. This explicitly forces the user to use either Windows Hello for Business, FIDO2, or Certificate-Based Authentication.

Conclusion

As Adversary-in-the-Middle proxy attacks become completely commoditized, reliance on passwords and mobile push notifications represents a critical vulnerability. By deploying Microsoft Entra ID Certificate-Based Authentication with hardware tokens (Smart Cards or YubiKeys), enterprise security teams can achieve cryptographically enforced, phishing-resistant Zero Trust access directly from the cloud, rendering credential theft mathematically impossible.