IAM4.5 Certificate-Based Authentication

What certificate-based authentication is

Certificate-based authentication uses public-key cryptography with X.509 digital certificates. The certificate contains the user's identity information (name, email, UPN) and a public key, signed by a trusted certification authority (CA). The corresponding private key is stored on a hardware token, typically a smart card, a USB security device, or the device's TPM through a virtual smart card. When the user authenticates, the client presents the certificate to Entra ID, proves possession of the private key by signing a challenge, and Entra ID validates the certificate against its trusted CA store.

The authentication flow is conceptually identical to FIDO2: a challenge-response exchange where the private key never leaves the hardware. The difference is infrastructure. FIDO2 uses the WebAuthn protocol and requires no issuing infrastructure: the key generates its own key pair during registration, and the relying party (Entra ID) stores the public key directly. CBA uses the X.509 PKI ecosystem and requires a certification authority that issues certificates, a certificate revocation mechanism (CRL or OCSP), certificate-to-user mapping rules in Entra ID, and ongoing certificate lifecycle management (renewal, revocation, re-issuance).

The infrastructure cost goes beyond the initial deployment. Certificates expire, typically every 1–3 years depending on your CA policy. When a certificate expires, the user can't authenticate until IT issues a replacement. In an organization with 500 certificate users, you'll process 150–500 certificate renewals annually (depending on the certificate lifetime). Each renewal requires the user to connect to the enrollment system, authenticate with an alternative method during the renewal window, and verify the new certificate works. This ongoing lifecycle management is the hidden cost of CBA that FIDO2 and WHfB don't have. FIDO2 keys don't expire (the key generates new credentials as needed), and WHfB credentials are managed automatically by the TPM.

Hardware vs software certificate storage is the critical design decision. A certificate stored on a smart card or virtual smart card (backed by the TPM) qualifies as a hardware-bound credential: the private key can't be exported, and possession of the physical card is required for authentication. A certificate stored in the Windows certificate store as a PFX file is software-stored: the private key can be exported, copied to another machine, and used without the original hardware. Entra ID's authentication binding rules distinguish between these: hardware-stored certificates can satisfy multi-factor authentication (the card is "something you have," the PIN is "something you know"), while software-stored certificates should be classified as single-factor because the credential isn't physically bound to the user.

This is why CBA configuration requires careful authentication binding rules, not all certificates are equal, and treating them equally creates a false assurance gap.

This infrastructure cost is why CBA is not the recommended first choice for passwordless adoption. FIDO2 and WHfB achieve phishing resistance without PKI. CBA makes sense in two scenarios: your organization already has a PKI and smart card infrastructure (government, defense, financial services), or your compliance framework explicitly requires certificate-based authentication (NIST SP 800-63B at AAL3, Common Criteria environments, US federal PIV/CAC mandates).

For organizations that already have PKI, the cost equation shifts significantly. The CA infrastructure exists. The certificate issuance process exists. The smart cards or virtual smart cards are already deployed. The marginal cost of enabling CBA in Entra ID is nearly zero, it's configuration, not infrastructure. In this scenario, CBA can be the fastest path to phishing-resistant authentication because the credentials are already in users' hands. The Entra ID configuration (CA trust upload, binding rules, authentication strength classification) takes hours, not weeks. The deployment timeline is "configure and enable" rather than "procure, distribute, and register."

The hidden cost for PKI-equipped organizations is ongoing lifecycle management. You already manage the PKI, so the incremental cost is the Entra ID integration: monitoring CBA-specific sign-in failures, maintaining the CRL endpoint for internet accessibility, and governing the authentication binding rules as your PKI issues new certificate templates. If your PKI team and your Entra ID team are different groups (which they usually are), the operational handoff, who monitors what, who troubleshoots CBA failures, who approves new certificate templates for Entra ID authentication, needs explicit documentation.

Estimated time: 50 minutes.

Configuring CBA in Entra ID

Entra ID CBA works by trusting your organization's certification authority chain and mapping certificates to user objects. The configuration has three steps: upload your CA certificates, configure certificate-to-user mapping rules, and enable CBA as an authentication method.

Verify the uploaded CA certificates:

$cas = Invoke-MgGraphRequest -Method GET `
  -Uri "https://graph.microsoft.com/v1.0/organization/{orgId}/certificateBasedAuthConfiguration" `
  -OutputType PSObject

foreach ($ca in $cas.certificateAuthorities) {
    Write-Host "CA: $($ca.issuer)"
    Write-Host "  Is root CA: $($ca.isRootAuthority)"
    Write-Host "  CRL URL: $($ca.certificateRevocationListUrl)"
    Write-Host "  Delta CRL: $($ca.deltaCertificateRevocationListUrl)"
}

Certificate-to-user mapping

After uploading the CA trust chain, configure how Entra ID maps a presented certificate to a user object. The mapping rule determines which certificate field (Subject, SAN, Issuer) maps to which user attribute (UPN, email, certificate user ID). This mapping is how Entra ID answers "which user does this certificate belong to?"

The authentication binding policy is the critical design decision. Entra ID can treat CBA as single-factor (the certificate proves identity but doesn't satisfy MFA) or multi-factor (the certificate proves identity AND satisfies MFA). The multi-factor classification requires the certificate to be stored on hardware: a smart card with a PIN or a TPM-protected virtual smart card. If the certificate is stored in software (a PFX file in the user's certificate store), it should be classified as single-factor because the private key can be exported and copied.

# Query current CBA configuration
$cbaConfig = Invoke-MgGraphRequest -Method GET `
  -Uri "https://graph.microsoft.com/v1.0/policies/authenticationMethodsPolicy/authenticationMethodConfigurations/x509Certificate" `
  -OutputType PSObject

Write-Host "CBA state: $($cbaConfig.state)"
Write-Host "Authentication mode default: $($cbaConfig.authenticationModeConfiguration.x509CertificateAuthenticationDefaultMode)"
foreach ($rule in $cbaConfig.authenticationModeConfiguration.rules) {
    Write-Host "  Rule: $($rule.x509CertificateRuleType) = $($rule.identifier) → $($rule.x509CertificateAuthenticationMode)"
}

foreach ($binding in $cbaConfig.certificateUserBindings) {
    Write-Host "Binding: cert.$($binding.x509CertificateField) → user.$($binding.userProperty) (priority: $($binding.priority))"
}

CBA state: enabled
Authentication mode default: x509CertificateSingleFactor
  Rule: issuerSubject = CN=NE-Smartcard-CA → x509CertificateMultiFactor
Binding: cert.PrincipalName → user.userPrincipalName (priority: 1)
Binding: cert.RFC822Name → user.onPremisesUserPrincipalName (priority: 2)

The output shows that CBA defaults to single-factor, with a rule that elevates certificates issued by NE-Smartcard-CA to multi-factor. The binding rules try UPN matching first, then fall back to email matching. This is a well-configured CBA setup for an organization with hardware smart cards.

Certificate mapping pitfalls

The certificate-to-user mapping is the most error-prone part of CBA configuration. Three common issues surface during deployment.

UPN mismatch. The certificate's Subject Alternative Name contains the user's UPN as user@northgateeng.com, but the user's Entra ID UPN is user@northgateeng.onmicrosoft.com (the tenant's default domain). The mapping fails because the strings don't match. The fix depends on your environment: either reissue certificates with the correct UPN, configure a custom domain in Entra ID so UPNs match, or use the onPremisesUserPrincipalName binding (which maps to the UPN from on-premises AD, not the Entra ID UPN).

Multiple binding rule conflicts. If you configure both PrincipalName → UPN and RFC822Name → mail as priority 1, the binding behavior is undefined when a certificate contains both fields. Always use priority ordering: set the primary binding rule to priority 1 and the fallback to priority 2. Entra ID evaluates rules in priority order and uses the first match.

Certificate without identity attributes. Older certificates issued for purposes other than authentication (code signing, encryption) may contain only a common name in the Subject field with no SAN. These certificates can't map to an Entra ID user because there's no machine-readable identity attribute. If your PKI issued certificates without SAN attributes, you'll need to re-issue them with the PrincipalName or RFC822Name SAN extension before CBA will work.

Verify a specific user's certificate mapping will work:

# Test CBA mapping, check if a user's certificate attributes match the binding rules
$userId = (Get-MgUser -Filter "displayName eq 'Rachel Okafor'" -Property UserPrincipalName,OnPremisesUserPrincipalName,Mail).Id
$user = Get-MgUser -UserId $userId -Property UserPrincipalName,OnPremisesUserPrincipalName,Mail

Write-Host "CBA Binding Check for: $($user.DisplayName)"
Write-Host "  userPrincipalName: $($user.UserPrincipalName)"
Write-Host "  onPremisesUserPrincipalName: $($user.OnPremisesUserPrincipalName)"
Write-Host "  mail: $($user.Mail)"
Write-Host ""
Write-Host "  Certificate SAN must contain one of these values for binding to succeed"
Write-Host "  Priority 1 (PrincipalName → UPN): certificate SAN must contain $($user.UserPrincipalName)"
Write-Host "  Priority 2 (RFC822Name → onPremUPN): certificate SAN must contain $($user.OnPremisesUserPrincipalName)"

Monitoring CBA authentication events

When CBA is deployed, monitor authentication events to confirm successful sign-ins and identify failures:

# CBA sign-in events in the last 7 days
$cbaSignIns = Get-MgAuditLogSignIn -Filter "authenticationDetails/any(a:a/authenticationMethod eq 'X.509 Certificate')" -All `
  -Property UserDisplayName,CreatedDateTime,Status,AuthenticationDetails |
  Where-Object { $_.CreatedDateTime -gt (Get-Date).AddDays(-7) }

$success = ($cbaSignIns | Where-Object { $_.Status.ErrorCode -eq 0 }).Count
$failures = ($cbaSignIns | Where-Object { $_.Status.ErrorCode -ne 0 }).Count

Write-Host "CBA Authentication Events (last 7 days):"
Write-Host "  Successful: $success"
Write-Host "  Failed: $failures"

# Show failure details
$cbaSignIns | Where-Object { $_.Status.ErrorCode -ne 0 } |
  Select-Object UserDisplayName, @{N="Error";E={$_.Status.FailureReason}}, CreatedDateTime |
  Format-Table

Common failure reasons in CBA sign-in logs: "Certificate validation failed" (certificate expired, CRL unreachable, or certificate not issued by a trusted CA), "User binding failed" (the certificate's identity attribute doesn't match any user in the directory), and "Authentication strength not satisfied" (the certificate was classified as single-factor but the CA policy requires multi-factor).

CRL and OCSP, revocation checking

Certificate revocation is the mechanism that invalidates a certificate before its expiry date. When a smart card is lost, when an employee leaves the organization, or when a private key is compromised, the certificate must be revoked immediately. Entra ID checks revocation status during every CBA authentication by querying the Certificate Revocation List (CRL) or the Online Certificate Status Protocol (OCSP) responder.

CRL and OCSP serve the same purpose, answering "is this certificate still valid?", but they work differently. A CRL is a signed file published by the CA containing the serial numbers of all revoked certificates. Entra ID downloads the CRL, caches it, and checks the presented certificate against the cached list. CRLs are efficient for small to medium deployments but can grow large in organizations that issue thousands of certificates. The CRL cache means there's a delay between when you revoke a certificate and when Entra ID sees the revocation, this delay depends on the CRL's validity period (typically 1–24 hours) and whether your CA publishes delta CRLs (incremental updates rather than full republication).

OCSP is a real-time protocol. When a user presents a certificate, Entra ID sends the certificate's serial number to the OCSP responder, which queries the CA's database and returns a signed response: "good," "revoked," or "unknown." OCSP provides near-real-time revocation status without caching delays, but it requires the OCSP responder to be available for every authentication attempt. If the responder is down, every CBA authentication fails (unless you configure a CRL fallback).

The design decision between CRL and OCSP, or using both, depends on your revocation latency requirement. If revoking a certificate must take effect within minutes (high-security environments, administrator credentials), you need OCSP. If revocation within a few hours is acceptable (standard user credentials), CRL with a short validity period is sufficient. Most organizations deploy both: OCSP for real-time checking with CRL as the fallback if the OCSP responder is unreachable.

If your CRL endpoint is unreachable during an authentication attempt, Entra ID's behavior depends on your configuration. The default is to allow the authentication when the CRL can't be checked: a fail-open approach that prioritizes availability over security. For high-security environments, configure CBA to fail-closed: deny authentication when revocation status can't be verified.

The fail-open default is a governance decision that should be documented in your ADR. Most organizations accept fail-open because the alternative, blocking all CBA authentication when the CRL endpoint has a momentary network hiccup, creates a disproportionate impact. If you choose fail-open, the compensating control is monitoring: alert when the CRL endpoint is unreachable for more than 15 minutes, and investigate whether any certificates were revoked during the outage window.

Test CRL accessibility:

# Test CRL endpoint accessibility
$crlUrl = "http://crl.northgateeng.com/pki/NE-Root-CA.crl"
try {
    $response = Invoke-WebRequest -Uri $crlUrl -Method Head -TimeoutSec 10
    Write-Host "CRL accessible: $crlUrl (status: $($response.StatusCode))"
} catch {
    Write-Host "⚠ CRL UNREACHABLE: $crlUrl"
    Write-Host "  Entra ID will fail-open on CBA authentication if CRL is unavailable"
    Write-Host "  Action: publish CRL to a publicly accessible endpoint"
}

At Northgate Engineering: NE does not currently have a PKI infrastructure. The 22 administrator accounts use FIDO2 keys (section 4.3), and the 680 dedicated workstation users get Windows Hello for Business (section 4.4). CBA is documented as "not deployed: no existing PKI, no compliance requirement mandating certificate-based authentication." ADR-IAM4-005 records the decision: "CBA is not justified for NE's current threat model and compliance requirements. FIDO2 + WHfB provide phishing-resistant authentication without PKI infrastructure cost. Revisit if NE pursues government contracts requiring PIV/CAC authentication or if a future compliance audit mandates certificate-based credentials."

Decision-point simulation

Scenario 1. Your organization has an existing on-premises PKI that issues smart card certificates for building access (physical security). The CISO asks: "Can we reuse these certificates for Entra ID authentication instead of deploying FIDO2 keys?" What do you evaluate?

Three questions determine the answer. First, do the existing certificates contain UPN or email in the Subject Alternative Name? Building-access certificates often contain only a card serial number: no identity attribute that maps to an Entra ID user. Second, is the CA's CRL published to a publicly accessible endpoint? On-premises CAs typically publish CRLs to internal LDAP or internal HTTP. Entra ID can't reach those. Third, are the certificates hardware-bound with PIN enforcement? Building-access cards sometimes skip the PIN to speed physical access, making them single-factor for Entra ID CBA. If all three answers are yes, reusing the existing certificates is viable and avoids FIDO2 hardware cost. If any answer is no, the remediation cost (re-issuing certificates, publishing CRL externally, configuring PIN enforcement) likely exceeds the cost of FIDO2 keys.

Scenario 2. A compliance auditor reviewing your NIST 800-171 controls asks: "How do you prove that certificates used for privileged access are stored on hardware and not software?" What evidence do you produce?

The authentication binding rule in Entra ID that grants multi-factor status only to certificates from your hardware CA is the primary evidence, it proves the platform enforces hardware-bound certificates for privileged access. Supplement with: the CA's certificate template configuration (showing the "private key is not exportable" flag), the hardware vendor's FIPS 140-2 certification for the smart card, and sign-in log entries showing CBA authentications with authenticationMethodDetail indicating the certificate issuer that maps to your hardware binding rule.

Scenario 3. Your CRL endpoint goes down on a Friday evening. By Monday morning, 200 CBA users have been authenticating for 60 hours without revocation checking. How do you assess the risk?

The risk depends on whether any certificates should have been revoked during the outage window. Check your CA's revocation queue, if no certificates were revoked between Friday evening and Monday morning, the fail-open behavior produced no security gap. If a certificate was revoked (employee termination, lost smart card) and the revoked certificate was used during the outage, you have a confirmed gap. Action: review sign-in logs for CBA authentications during the outage, cross-reference against the revocation list, and investigate any authentications from revoked certificates. Long-term fix: deploy a redundant CRL endpoint, monitor CRL availability with synthetic checks, and evaluate whether fail-closed is acceptable for your environment.

Reusable script. CBA configuration audit

# IAM4.5. CBA Configuration Audit
# Validates CA trust chain, binding rules, and CRL accessibility

Connect-MgGraph -Scopes "Policy.Read.All"

# CBA method state
$cba = Invoke-MgGraphRequest -Method GET `
  -Uri "https://graph.microsoft.com/v1.0/policies/authenticationMethodsPolicy/authenticationMethodConfigurations/x509Certificate" `
  -OutputType PSObject

Write-Host "`n=== CBA Configuration ==="
Write-Host "  State: $($cba.state)"
Write-Host "  Default auth mode: $($cba.authenticationModeConfiguration.x509CertificateAuthenticationDefaultMode)"

Write-Host "`n=== Authentication Binding Rules ==="
foreach ($rule in $cba.authenticationModeConfiguration.rules) {
    Write-Host "  $($rule.x509CertificateRuleType): $($rule.identifier) → $($rule.x509CertificateAuthenticationMode)"
}

Write-Host "`n=== Certificate User Bindings ==="
foreach ($binding in $cba.certificateUserBindings) {
    Write-Host "  cert.$($binding.x509CertificateField) → user.$($binding.userProperty) (priority $($binding.priority))"
}

# CRL accessibility check
Write-Host "`n=== CRL Accessibility ==="
$cas = Invoke-MgGraphRequest -Method GET `
  -Uri "https://graph.microsoft.com/v1.0/organization/{orgId}/certificateBasedAuthConfiguration" `
  -OutputType PSObject

foreach ($ca in $cas.certificateAuthorities) {
    if ($ca.certificateRevocationListUrl) {
        try {
            $r = Invoke-WebRequest -Uri $ca.certificateRevocationListUrl -Method Head -TimeoutSec 10
            Write-Host "  $($ca.issuer): CRL OK ($($ca.certificateRevocationListUrl))"
        } catch {
            Write-Host "  ⚠ $($ca.issuer): CRL UNREACHABLE ($($ca.certificateRevocationListUrl))"
        }
    }
}