Microsoft Announces Mandatory CA Enforcement for Azure AD Certificate-Based Auth
Microsoft has announced that Azure AD certificate-based authentication (CBA) will enforce strict CA binding starting August 12, 2026. Tenants using third-party CAs, self-signed certificates, or CAs not explicitly uploaded to the Azure AD Trusted Certificate Authorities store will experience authentication failures. Audit your tenant now.
What Is Changing
Azure AD CBA currently allows certificate authentication with a permissive CA validation mode — certificates signed by CAs not in the tenant's trusted CA store can still authenticate under certain conditions. Starting August 12, 2026, Microsoft is enforcing strict CA binding: every certificate used for CBA must chain to a CA explicitly uploaded to the Azure AD Trusted Certificate Authorities configuration.
This change affects all Azure AD tenants using certificate-based authentication, including hybrid environments where on-premises ADCS issues certificates used for cloud authentication.
Which Configurations Are at Risk
The following configurations will break after the enforcement date if not remediated:
- Third-party CA certificates not uploaded to Azure AD Trusted CAs — any certificate from DigiCert, Entrust, or other commercial CAs used for user authentication.
- On-premises ADCS Issuing CA certificates not synced to Azure AD — common in hybrid environments where the CA was set up before CBA was configured.
- Intermediate CA certificates missing from the trust store — the full chain from Root CA to Issuing CA must be present.
- Self-signed certificates used for device or service authentication.
- Expired CA certificates in the trust store — Azure AD will reject chains to expired CAs.
How to Audit Your Tenant
Use the Microsoft Graph API or Azure AD PowerShell to enumerate your current trusted CA configuration and compare it against the CAs that issued certificates currently in use:
# List current trusted CAs in Azure AD
Get-MgOrganizationCertificateBasedAuthConfiguration -OrganizationId <tenantId>
# Export all user certificates and their issuer chains
Get-MgUser -All | Get-MgUserAuthenticationMethod | Where-Object { $_.AdditionalProperties["@odata.type"] -eq "#microsoft.graph.x509CertificateAuthenticationMethod" }Remediation Steps
For each CA that issues certificates used in CBA, upload the full certificate chain (Root CA + all Intermediate/Issuing CAs) to Azure AD. Ensure CRL Distribution Points are accessible from Azure AD's validation infrastructure — Microsoft publishes the IP ranges that must be able to reach your CDP endpoints.
Certificate-based authentication is increasingly used as a phishing-resistant MFA replacement. A misconfigured CA trust store will silently break authentication for affected users on August 12 — with no grace period. Organizations with complex hybrid PKI environments or multiple CAs are most at risk.
- 1Audit your Azure AD Trusted Certificate Authorities store against all CAs currently issuing CBA certificates.
- 2Upload missing Root CA and Issuing CA certificates to Azure AD via the Azure Portal → Security → Certificate Authorities.
- 3Verify CRL Distribution Points are reachable from Azure AD IP ranges (published in Microsoft's service tags).
- 4Test CBA authentication in a non-production tenant or with a test user before the August 12 deadline.
- 5Set a calendar reminder for August 1 to run a final pre-enforcement validation.
This is a breaking change with a hard deadline. Microsoft has given reasonable notice, but the audit process is non-trivial in environments with multiple CAs or third-party certificates. The organizations most likely to be caught off guard are those that set up CBA years ago and have not revisited the configuration since. Run the audit this week.
InsecurePlanet provides original technical analysis based on the sources listed below. This article does not claim facts beyond the cited source material.