Microsoft released three non-security out-of-band Windows 11 updates on October 26, pushing offline certificate-trust data tied to the eMudhra key compromise. These packages target only disconnected, air-gapped, or locked-down machines, so most consumers will never even see them appear in Windows Update. They bundle fixes into KB5134133, KB5134134, and KB5134130 across Windows 11 versions from 23H2 through 26H2, and ship from the Microsoft Update Catalog only. The move follows the October 2026 breach of eight eMudhra intermediate CA private keys, which could let attackers forge TLS certificates for any domain.

Microsoft ships rare out-of-band Windows 11 updates over eMudhra key compromise

Microsoft's October 26 patches address the eMudhra key compromise, and most users will never even see them.

Microsoft rolled out three out-of-band Windows 11 updates on October 26, 2026. Each is a non-security cumulative update. Its headline change, if you can call it that, is a single word: certificates. Here's the catch. You almost certainly won't install any of them.

These are aimed at machines that can't reach Microsoft's certificate services. Think air-gapped networks, hardened enterprise environments, and anything where an admin has switched off automatic trust-list updates. If you're on a normal Windows 11 PC with internet, Microsoft already handled this for you.

The eMudhra compromise

On October 17, a security researcher going by "Wayne" reported to the major root programs that eight intermediate CA private keys from eMudhra Limited, an Indian issuer, looked cryptographically weak. Not "needs a firmware patch" weak. Recoverable-from-the-public-certificate weak.

That split second matters more than you'd expect. A private key is supposed to stay secret. But a flaw in one of eMudhra's key-generation ceremonies produced a weaker second pair of keys, so the public certificate alone was enough to work backward to the private one. With those keys, an attacker could sign fake TLS certificates for any domain, pull off man-in-the-middle interception, or hijack a session.

Eight intermediates were affected. Six issued TLS certificates, chaining to the emSign ECC Root CA - G3. Two handled code-signing, chaining to emSign Root CS CA - G3. Each also existed as a second certificate cross-signed by Sectigo under its AAA Certificate Services root, which is exactly why this bounced across the stores held by Microsoft, Apple, Mozilla, and Chrome.

Wayne didn't just file a report. He signed test messages with each of the eight private keys and handed over proof that anyone could verify with OpenSSL against the published certificates. A fairly textbook demonstration that the keys were no longer secret.

What Microsoft actually did

eMudhra fired back on October 20, insisting that only intermediate keys were compromised and that no certificates had actually been issued from the affected slots. No data breach. Infrastructure untouched. The weakness came from a software bug in a key-wrapping test path, not from the FIPS 140-2 Level 3 HSMs the keys were born in.

Microsoft's own moves tracked the timeline closely. On October 20 it pushed an update to the Windows Disallowed Certificate Trust List for connected devices, plus a separate CRLSet update for Edge and WebView2. Apple began blocking the six TLS intermediates that same week, and Chrome shipped its own CRLSet block. Then came the October 26 out-of-band trio, which pulled seven certificates off the Windows trust list: six eMudhra G3 roots and an AAA Certificate Services cross-sign.

Three KB numbers, three version groups. KB5134133 covers 24H2, 25H2, and 26H2 at builds 26300.9725, 26200.9725, and 26100.9725. KB5134134 targets 26H1 at build 28000.3237. KB5134130 handles 23H2 at build 22631.7654, bundling a separate servicing stack update, KB5126652. All three are non-security, all three are cumulative, and all three ship from the Microsoft Update Catalog only. They won't surface in Windows Update as an optional fix for most people.

The intended audience is narrow and explicit: disconnected machines, devices that can't reach the certificate service, and systems with automatic CTL updates disabled. Everyone else gets the trust data automatically and largely won't notice.

If you are the one deploying these anyway, watch the known issues. KB5134133 can block Smart App Control, break Remote Desktop for non-admin users (that's error 0xC000000D), and stop USB audio from starting. KB5134134 shares the Remote Desktop and USB audio problems. KB5134130 has, for now, no known issues.

There's also a deployment gotcha worth flagging. When you fold these into a Windows image, the boot.stl file has to be in your install media, or Secure Boot validation can fail with error 0xc0430001 and the device won't boot from it. Microsoft recommends the Update WinPE script, or you can copy boot.stl by hand from the Windows\Boot\EFI folder.

Separately, and only tangentially related, Windows 11 24H2 (Home and Pro) reaches end-of-support this October, so the 23H2 servicing line stays relevant for shops still on older feature updates. Not directly on point for this patch, but it's a reminder that not every machine in an enterprise is running the newest build.

Why this still matters

Microsoft drew a careful line. Removing a root from the trust list isn't the same as revoking the compromised intermediates. It's a broader, separate trust decision. Organizations with a specific compatibility need can still locally trust a certificate, but Microsoft warned against restoring trust in an affected hierarchy without understanding the risk. It says it's evaluating the remaining eMudhra roots on their own.

So the takeaway splits cleanly by audience. For the average reader: nothing to do. For IT admins of air-gapped or locked-down systems, it's real work, verify your offline servicing packages include the updated Disallowed CTL and the seven-certificate removal, and swap any certs chaining to the removed roots before the change lands.

The eMudhra episode is yet another reminder of how thin the internet's trust layer really is. One CA's key-management stumble can, in principle, let someone forge a certificate for any site. The quick, coordinated blocklist response across Apple, Google, Mozilla, and Microsoft kept it a near-miss. The offline path is what makes it a complete one.

Head here to the Microsoft Support pages for KB5134133, KB5134134, and KB5134130.