While being touted as one of the more robust ways to prevent Adversary in the Middle (AitM) attacks against TLS-protected resources, for some admins, the Enterprise Certificate Pinning feature in Windows may lock out their entire organization.

However, Enterprise Certificate Pinning is not advised for domain names outside of your organization, when their certificates are issued by a public Certification Authority (CA).

For some admins, this will become painfully clear this week. Not because they underestimated the validity period for a pinned certificate, but because a major change in the certificate chain for important resources in their Hybrid Identity setup is occurring.

How Enterprise Certificate Pinning works

Although risky, the Enterprise Certificate Pinning Windows feature can be hugely advantageous to admins preventing resources being spoofed.

Enterprise certificate pinning offers remembering (pinning) a root issuing Certification Authority (CA), or end-entity certificate, to a domain name for an end-user Windows device. Any resource that triggers a mismatch from the remembered (pinned) certificate, than the Windows device treats its certificate as invalid or revoked (depending on the settings set by an admin).

To take advantage of this feature, an admin can create a a pin rules certificate trust list with pinned certificates per domain name. From that moment on, only that certificate and/or the certificate for that Root CA is trusted for usage.

Enterprise Certificate Pinning leverages the Windows Registry to offer a pin rules certificate trust list in the PinRules binary value underneath HKLM\SOFTWARE\Microsoft\Cryptography\OID\EncodingType0\CertDllCreateCertificateChainEngine\Config

How Hybrid Identity admins may have used Enterprise Certificate Pinning

Because some TLS-protected resources are considered high-risk, even though they are managed outside of your organization, Enterprise Certificate Pinning might sound like a great security idea to ensure that only a specific certificate is considered valid for that particular resource.

A few high-risk external resources that might that bill:

• microsoftonline.com
• live.com
• windows.net
• microsoftazuread-sso.com
• windows.net

All of these domains have in common that the DigiCert Root Certification Authority (CA) is the top-level certificate in their certificate chain. For the four latter domains however, Microsoft set January 7th, 2026 as the date that they switch their certificate chain from DigiCert’s G1 infrastructure to its G2 infrastructure.

This is communicated as part of Microsoft Message Center item MC1193408.

Microsoft switches to DigiCert’s newer infrastructure for improved security and compliance. Note, that DigiCert’s G1 Root CA has a certificate that is still valid until November 10th, 2030.

If the DigiCert Root CA is pinned for these domain names – from the moment of the switch – the certificates for these domains will be treated as invalid or revoked. After all, the certificate chain for the certificate changes and no longer features the pinned certificate at the top-level certificate in the certificate chain. This applies to:

• login.live.com (used for Personal Accounts)
• login.windows.net (Primarily used by the decommissioned ADAL and for v1 application integration with Entra)
• autologon.microsoftazuread-sso.com (used for Seamless Single Sign-on)
• graph.windows.net (endpoint for the decommissioned Azure AD Graph)

Remove Enterprise Certificate Pinning rules

Enterprise Certificate Pinning is not advised for domain names outside of your organization, when their certificates are issued by a public Certification Authority (CA).

Admins hoping to find the contents of the pin rules certificate trust list in either of these locations are sadly mistaken:

• The Registry of the Windows devices these rules were deployed to
• The Group Policy object and/or the MDM policy that deploys the certificate trust list

The above locations merely contain the binary encoded representation of the *.stl file, that was created from the *.xml file containing the pin rules.

To remove the pin rules, locate the *.xml file with the pin rules and remove the pins for the above domain names. If not present anymore, create a new *.xml file containing merely internal domains that use certificates issued by internally managed Certification Authorities (CAs). The, roll out the new pin rules using Group Policy or your MDM solution.

If Enterprise Certificate Pinning is no longer needed in the organization, change the policy rules to delete the PinRules registry value.

How things may go sideways fast for Hybrid Identity admins

As login.windows.net is still leveraged intensively throughout Entra, with the certificate pin rules list in place, your MDM solution may not even be able to overwrite previously configured Pin Rules on your managed end-user devices as the MDM infrastructure is no longer trusted…

Act now!

If you have previously managed the Enterprise Certificate Pinning feature, or if you find PinRules registry value on a typical end-user Windows device in your organization, act now to make sure you’ve only applied it to internal resources using certificates that are issued by internal certification authorities (CAs).