Most Windows PCs will never notice what Microsoft did to the eMudhra certificates this week. Windows refreshes its list of trusted and banned certificate authorities quietly in the background, and on a connected machine the change has probably landed already. The machines that worry security teams are the ones that never get those background updates: air-gapped networks, locked-down servers that can't reach Microsoft's certificate-update service, and fleets where an admin switched automatic updates off years ago and forgot about it.
On Oct. 26, Microsoft shipped an out-of-band (OOB) Windows update for those machines. KB5134133 carries the refreshed certificate trust list. It is a non-security release, according to The Register, and it delivers the same eMudhra distrust as a normal installable update rather than as a background download.
What happened with eMudhra?
eMudhra is a certificate authority (CA). Its emSign certificates sit in the chains Windows and browsers use to decide whether a TLS-protected website or service is real. On Oct. 26 at 19:00 PT, Microsoft's Windows release health message center announced a new MSRC blog post on "Microsoft's response to compromised eMudhra certificate authority keys." The entry says the post outlines Microsoft's response to compromised eMudhra intermediate certificate authority keys, "including changes to Windows and Microsoft Edge trust lists."
We could not read that MSRC post. It returned an access-denied error when we tried to fetch it. So this article does not cover how the keys were compromised, who did it, or how long it went on. Microsoft's message-center entry confirms two things: eMudhra intermediate CA keys were compromised, and Microsoft changed its trust lists in response. The Register adds that the Indian certification authority's private keys were compromised earlier this month, and quotes Microsoft as saying they "could potentially be used to create certificates or sign content that appeared to come from a trusted CA."
Microsoft's Azure App Service team explained why this matters. Compromised certificate authorities can allow an attacker to impersonate TLS endpoints when a client continues to trust the affected certificate chains. With a CA's signing keys, someone can issue a certificate for a site they don't own, and any machine that still trusts that CA would accept it as genuine.
What exactly gets removed?
The Register quotes Microsoft as saying the Oct. 26 OOB update removes seven certificates associated with the affected hierarchies from the Windows trust list:
- six eMudhra G3 root certificates, and
- one AAA Certificate Services cross-sign.
A cross-sign is a certificate in which one CA vouches for another, so the second CA's certificates are trusted by systems that only know the first. Removing the cross-sign is presumably meant to stop the affected chains from being trusted through that alternate route, though the sources do not spell out the reasoning.
According to The Register, Microsoft also updated the Windows Disallowed Certificate Trust List, which is the list of certificates Windows explicitly refuses to trust, and released a separate CRLSet for Edge and WebView2. A CRLSet is a compact list of revoked certificates that the browser checks itself, so Edge and apps that render web content through WebView2 get the block through that channel in addition to the operating system's store.
Why ship an out-of-band update at all?
CTL stands for certificate trust list. Windows keeps its root store current by downloading CTL updates from Microsoft automatically. The Register notes that many devices will not need this update because certificate list updates usually come down through the update service, so many fleets should already have the distrust without doing anything.
The KB5134133 support page says who the update is for: devices that do not receive current CTL updates, including updates to the list of untrusted certificates. Its examples are devices in disconnected environments, devices that cannot access Microsoft's certificate-update service, and devices where automatic CTL updates are disabled. Those machines would otherwise lack the updated trust list. The OOB package gives them the update through ordinary patch channels.
Which Windows versions are covered?
According to Microsoft's KB page, KB5134133 applies to Windows 11 versions 24H2, 25H2 and 26H2 and carries OS builds:
- 26300.9725
- 26200.9725
- 26100.9725
The Register reports that the OOB release applies to supported OSes ranging from Windows 11 and Windows Server 2025 to Windows 10. The Windows 11 update is available from the Microsoft Update Catalog. Microsoft notes a prerequisite for Windows 11 24H2 and 25H2: those systems must already have a Windows update released on or after June 10, 2025 (such as KB5060842) installed before KB5134133 will apply.
The catch: this update brings October's known issues with it
This is the part admins need to weigh before installing. According to The Register, the OOB release contains everything in Microsoft's Oct. 13 update. That means it also carries that update's known issues, and none of them are resolved in this patch. The Register lists them as:
- ongoing VPN issues,
- a change that could break on-premises Exchange Servers,
- oddities with Smart App Control,
- audio problems, and
- Remote Desktop connection problems for non-admin users.
A disconnected machine that skipped the Oct. 13 update gets all of those changes at once, along with the certificate fix. An organization that held off on the October update because of the Exchange or VPN issues now has to weigh staying without the updated trust list against taking on those known issues. The Register's advice is to get the OOB fix if the normal CTL service isn't available or being used, while keeping the known issues in mind, since problems can occur when verifying certificates used by applications or websites.
Cloud workloads: the OS fix isn't the whole fix
On Oct. 25, the Azure App Service team said the rollout of Windows operating-system certificate updates was complete on Azure App Service for Windows. The same post warns that application-managed certificate bundles and trust stores still require separate review. An app can use the Windows certificate store, a runtime-specific trust store, or a CA bundle supplied by a library, and the Windows OS patch does not replace certificates bundled with an application, runtime or dependency. Customer-provided container images must be updated by the customer.
The same logic applies beyond Azure. The Windows root store governs software that asks Windows to validate certificates. Software that carries its own list of trusted CAs keeps whatever that list contained, and that copy has to be updated separately.
What It Means for Defenders
Who is affected: Any organization whose Windows systems might trust the affected eMudhra/emSign hierarchies. The highest-priority group is the machines KB5134133 was built for: devices in disconnected environments, devices that cannot reach Microsoft's certificate-update service, and devices where automatic CTL updates are disabled. Federal contractors and CMMC environments with enclave networks or tightly restricted outbound traffic are likely to have such machines and are worth checking first.
What to patch:
- For Windows 11 machines that don't get automatic CTL updates, get KB5134133 from the Microsoft Update Catalog. It carries builds 26300.9725, 26200.9725 and 26100.9725. On 24H2 and 25H2, install a Windows update released on or after June 10, 2025 (such as KB5060842) first.
- Per The Register, the OOB release also applies to Windows Server 2025 and Windows 10. Include those systems in the same review.
- Connected devices that receive CTL updates normally should already have the changes, since The Register says the certificate list usually comes down through the update service. Confirm that automatic CTL updates are actually working rather than assuming it.
What to test first: Because KB5134133 includes the Oct. 13 update, test it against the known issues before rolling it out widely. Check VPN clients, on-premises Exchange servers, Smart App Control, audio, and Remote Desktop access for non-admin users. None of these are resolved in this release.
What to check beyond Windows:
- Application trust stores. As Microsoft's App Service team says, bundled CA files and app-specific trust stores still need a separate review. List the runtimes and appliances that ship their own CA lists and confirm they no longer trust the affected eMudhra chains.
- Edge and WebView2. Microsoft released a separate CRLSet for these. Make sure Edge and the WebView2 runtime are allowed to update on managed machines.
- Your own certificates. If your organization uses certificates that chain to eMudhra/emSign roots, expect clients that have received the distrust to reject them. Plan to replace those certificates with ones from another CA, and test outbound TLS connections to services that rely on those chains.
What not to assume: Microsoft's public message-center entry confirms the compromise of eMudhra intermediate CA keys and the trust-list changes. It does not say who was responsible or whether any fraudulent certificates were used against real targets. Until Microsoft or eMudhra says more, treat any claims about either as unverified.
