Skip to content

Windows and Edge drop 7 eMudhra roots after CA key compromise

Microsoft released an out-of-band Windows update on 26 October 2026 and changed the Microsoft Edge trust list on 27 October to stop trusting seven eMudhra certificates, after eight eMudhra intermediate CA private keys were compromised. Endpoint and PKI admins must make sure these trust-list updates reach every device and replace any certificate that chains to the removed roots.

Runbook card

What changes: Windows and Edge no longer trust six eMudhra G3 roots and an AAA Certificate Services cross-sign. Certificates signed through the affected hierarchies stop validating.
Who: every organisation with Windows, Edge or WebView2; most work for those with disconnected or WSUS-isolated devices, Azure VMs built from older images, or certificates that chain to eMudhra.
By when: now. Microsoft's message gives general availability as "Beginning in late October 2026 and expected to complete by late October 2026".
Do this: 1. Confirm automatic certificate trust updates and Edge component updates reach devices. 2. Deliver the updated Disallowed Certificate Trust List to disconnected devices. 3. Find and replace certificates that chain to eMudhra.
Check: the certutil commands below on a sample of devices.
Source: MSRC blog (26 October, updated 27 October 2026) and MC1529467.

What Microsoft says

The issue involves "eight eMudhra intermediate certificate authority (CA) private keys, six associated with TLS and two with code signing". Because those keys could be recovered, Microsoft says they "could potentially be used to create certificates or sign content that appeared to come from a trusted CA". The issue "arose in eMudhra's certificate hierarchy and was not a compromise of Microsoft systems" (MC1529467).

The timeline, per the MSRC post:

  • 20 October 2026: Microsoft updated the Windows Disallowed Certificate Trust List to block the affected certificate authorities.
  • 26 October 2026: an out-of-band Windows update removed seven certificates from the Windows trust list: six eMudhra G3 roots and an AAA Certificate Services cross-sign.
  • 27 October 2026: Microsoft removed the same seven certificates from the Microsoft Edge trust list.
  • A separate CRLSet update blocks affected TLS certificates in Edge and WebView2. It arrives through Edge's component updates, so "Customers do not need to install a new browser version" (MC1529467). Microsoft gives no date for it.

Microsoft says it "is evaluating the remaining eMudhra roots separately". Expect more trust-list changes; we will update this page if Microsoft publishes them.

Eight keys and seven certificates are both correct: eight intermediate keys were compromised, and seven root or cross-sign certificates were removed.

Who needs to act

Most connected Windows devices get these changes automatically. The ones that don't:

  • devices that can't reach Windows Update for root and disallowed certificate updates (air-gapped networks, strict WSUS-only estates, proxies that block the certificate trust list download)
  • Azure VMs and Virtual Machine Scale Sets that run disconnected or from old images. Microsoft says "Updated images are available in Azure Marketplace".
  • any service or app whose TLS or code-signing certificate chains to one of the removed roots. It stops validating once the change reaches the client.

How to check (read-only)

On a Windows device, from an elevated prompt:

# Is any eMudhra certificate still in the trusted root store?
certutil -store Root | Select-String -Pattern "eMudhra" -Context 0,3

# When did this device last sync the disallowed list? (UTC)
$k = Get-ItemProperty 'HKLM:\SOFTWARE\Microsoft\SystemCertificates\AuthRoot\AutoUpdate'
[DateTime]::FromFileTimeUtc([BitConverter]::ToInt64($k.DisallowedCertLastSyncTime, 0))

# Which machine certificates were issued by eMudhra?
Get-ChildItem Cert:\LocalMachine\My | Where-Object { $_.Issuer -match 'eMudhra' } |
  Select-Object Subject, Issuer, NotAfter

For your own estate, search your certificate inventory (internal CA reports, load balancer and web server certificates, code-signing certificates from vendors) for issuers containing "eMudhra". Ask suppliers whose software is signed with eMudhra code-signing certificates whether they are re-signing.

What to do

  1. Keep updates flowing. Allow automatic Windows certificate trust updates and Edge component updates (Microsoft's first recommendation).
  2. Disconnected devices. Distribute the updated Disallowed Certificate Trust List through your own process, as described in Microsoft Learn's Configure trusted roots and disallowed certificates.
  3. Azure. Redeploy disconnected VMs and scale sets from the updated Marketplace images, and refresh your own golden images.
  4. Replace dependent certificates. For anything that chains to the removed roots, get a replacement certificate or another trusted chain before the change reaches the clients that use it.

How to verify

Re-run the certutil -store Root check: it should return no eMudhra G3 roots. The disallowed sync time should be on or after 20 October 2026. A test connection to any service you re-issued should validate without warnings.

Impact

A certificate that chains to a removed root fails validation: TLS warnings in Edge and apps that use the Windows store, and signature checks that fail for affected signed code. That is the intended result. Find those dependencies before your users do.

Related: our Defender for Endpoint and ASR Kit (keeping endpoint security updates current), every date we track on Microsoft 365 security deadlines, and more Endpoint & devices news.

Sources

Last reviewed: 31 October 2026. Runbook Lab is not affiliated with Microsoft.