Microsoft Ends Trust in 10 eMudhra Roots on November 16: Windows and Edge Impact

What changes on November 16​

Microsoft's MSRC incident page lists three separate actions for the same date:

• Windows: Microsoft will remove the remaining 10 eMudhra roots from the Windows trusted root certificate list through the HTTP endpoint that Windows devices use for automatic certificate trust updates.
• Edge and WebView2: An update will be released for Microsoft Edge and WebView2, delivered via the PKI Metadata component, which will fully remove default trust for the remaining roots (emSign Root CA - G1, emSign Root CA - C1, emSign ECC Root CA, and emSign Root TLS CA - G1).
• Azure Linux: Microsoft will remove the affected root certificates and refresh Azure Linux VM and container images.

The Microsoft Build of OpenJDK follows a different schedule. Because it bundles the Mozilla root store, its update depends on Mozilla's release timing. The Edge note in Message Center item MC1529467 names only four roots, while the Trusted Root Program announcement lists all ten for both Windows and Edge. Microsoft hasn't explained the difference.

These are the ten roots Microsoft listed. The values below are copied exactly from Microsoft's table:

One practical detail: Microsoft labels this column "SHA-256 Thumbprint", but every value has 40 hex characters. That is the length of a SHA-1 thumbprint, which is the format Windows shows in the certificate Thumbprint field and in PowerShell's Thumbprint property. If you search a certificate store for these strings, compare them against the SHA-1 thumbprint, not a SHA-256 hash.

The list covers TLS, S/MIME, client authentication, code signing and timestamping roots. Websites are only one of the things that could be affected.

Summary: On November 16, ten emSign roots lose default trust in Windows and Edge/WebView2. Azure Linux images are refreshed the same day, and OpenJDK follows Mozilla's schedule.

How we got here​

The trigger was a key-generation failure, not a breach at Microsoft. On November 10, Microsoft said it was removing the remaining eMudhra root certificates across its products and services, starting November 16, 2026. That followed an earlier set of emergency steps:

• October 20: Microsoft updated the Windows Disallowed Certificate Trust List to block the eight compromised CA keys (six TLS, two code signing) by their public key. An emergency CRLSet update did the same job for Edge and WebView2.
• October 26: An out-of-band Windows update (KB5134133 for Windows 11 24H2/25H2/26H2, plus KB5134137 for Windows Server 2025, among others) removed six eMudhra G3 roots and one Sectigo "AAA Certificate Services" cross-sign from the Windows trust list.
• October 27: Microsoft removed the same seven certificates from Edge through PKI Metadata component version 72.0.0.0.

Reporting doesn't fully agree on these dates. Neowin says the most recent one Microsoft released on Windows was at the end of last month, October 28, 2026, under KB5134133 and KB5134134, with Edge following a day later. Microsoft's own Trusted Root Program announcement says October 26 for Windows and October 27 for Edge. We're going with Microsoft's dates. The October batch also wasn't "seven eMudhra certificates": six were eMudhra roots and the seventh was Sectigo's cross-sign.

The situation then got worse. As reported by BleepingComputer, on November 7 the company revoked eight RSA intermediate certificates, in addition to the eight compromised in October. According to The Hacker News, eMudhra revoked 8 more certificate authorities after finding its Python script exposed RSA private keys to process memory during an HSM transfer. Cybersecurity News reports that Mozilla's bug thread lists the new batch, including intermediates named EM DV TLS CA – G2B and G2C, which sit under emSign Root TLS CA – G1. That root is on Microsoft's November list.

Other root programs are moving at different speeds. Mozilla and Chrome also moved to remove trust in emSign ECC Root CA – G3. Meteora Web reports that Apple will remove trust from all G1 certificates on November 30. In its Azure Linux tracking issue, Microsoft gives a blunt reason for going further than the others: since eMudhra is exiting the certificate business, we are deleting these keys out of an abundance of caution.

Summary: Microsoft first blocked the compromised keys, then pulled the G3 roots, and is now removing everything else. Its peers are acting on narrower, staggered timelines.

Will anything break?​

For most home users, probably not. eMudhra says it has already moved customers over. Cybersecurity News reports that eMudhra estimated about 30,000 certificates needed to move, and about 97 percent of them came through ACME, the automatic renewal system.

Microsoft's warning is about the certificate chain, not about eMudhra as a brand. Certificates that depend on these roots may stop validating unless another trusted certification path exists. Here's where you're most likely to see trouble:

• Internal or partner TLS endpoints still serving an emSign-issued certificate.
• Signed software and timestamps that chain to the CS or TSA roots. How these behave after removal depends on how each application validates signatures.
• S/MIME mail and client-certificate logins under the SMIME and Client Auth roots.
• Apps that ship their own trust store. Microsoft's October 30 MSRC guidance calls out Java keystores, Python certificate bundles and container images, which Windows updates don't touch. Microsoft says admins should search those stores for trusted intermediates and replace any certificates that chain to the removed roots.

Delivery: no cumulative update needed, but check it arrived​

Windows Report says the Windows change comes through the Automatic Root Certificates Update mechanism, which downloads updated Certificate Trust Lists from ctldl.windowsupdate.com. It also says Edge's PKI Metadata component checks for updates about every 10 hours and shortly after launch. Microsoft's announcement confirms the delivery channels but doesn't commit to a cadence, so treat the 10-hour figure as reported rather than official.

Disconnected networks need manual work. Neowin notes that for organizations operating disconnected environments, Microsoft provides an alternative. According to Windows Report, that means using Group Policy to point CTL retrieval at an internal server and using certutil -syncWithWU to download the trust files for redistribution. Neowin also warns that disabling automatic root certificate updates altogether could leave systems trusting certificates that Microsoft has already deemed unsafe.

A practical checklist before Sunday:

• Inventory your certificates. Scan public and internal endpoints, code-signing pipelines and mail gateways for chains ending in any of the ten roots above.
• Check your local stores. In PowerShell, compare Get-ChildItem Cert:\LocalMachine\Root (and CurrentUser\Root) against the thumbprints. Windows adds roots to these stores only when it needs them, so a missing root doesn't prove you aren't affected. Your endpoint scan is the stronger evidence.
• Confirm the earlier mitigation landed. Run certutil -f -verifyCTL DisallowedWU | findstr SequenceNumber and look for 01dd5f6ca45c9d86. In Edge, open edge://components and check that CRLSet is at 2026.10.20 or later. These checks confirm the October key block only, not the November 16 root removal.
• Update bundled trust stores. That includes Java, Python, container images and WSL distributions.
• Don't add trust back without thinking it through. Microsoft allows local trust for genuine compatibility needs, but only after your own risk assessment.

Summary: Connected Windows and Edge installs update themselves. Air-gapped systems and apps with their own trust stores won't, and that's where the real work is.

The bigger picture​

When a single scripting bug lets eight CA keys be recovered, every root program has to decide how much of that CA to keep trusting. Microsoft is removing all of eMudhra's roots in one go. Mozilla and Chrome have started with specific roots, and Apple is setting its own dates. You can argue Microsoft is overreacting, since there's no public evidence the newer batch of keys was misused. But the trust model only works if CAs prove they handle keys properly, and Microsoft clearly decided eMudhra hadn't. If you run a Windows fleet, finish the inventory before November 16 rather than waiting for help desk tickets to tell you which certificates you missed.

Correction (November 12, 2026): An earlier version of this article said Microsoft announced the removal of the remaining ten eMudhra roots on October 26. The announcement was published on November 10, 2026; Microsoft's October 26 announcement covered the removal of seven certificates (six eMudhra G3 roots and one Sectigo cross-sign) and said the remaining roots were still under evaluation.