Microsoft Issues Out-of-Band Windows Update to Remove 7 eMudhra Certificates From Trust List

On October 26, 2026, Microsoft released an out-of-band update for Windows devices that cannot automatically receive certificate trust information. The update follows the discovery of a problem with private keys belonging to the certificate authority eMudhra, and it removes the related certificates from Windows' default trust list. It is aimed at devices whose certificate trust data is not updated automatically, such as those in air-gapped environments with no direct internet connection.

Windows already blocked the affected intermediate certificate authorities on October 20. This update also removes the root certificates and other higher-level certificates above them from the trust list. In environments that cannot use automatic updates, administrators need to confirm that both the intermediate CA block and the removal of trust for the higher-level certificates have taken effect, and verify that connections to legitimate services are not affected.

Eight Private Keys and Seven Certificates Are Different Things

The issue began with flaws found in eight private keys for intermediate certificate authorities operated by eMudhra. According to the Microsoft Security Response Center (MSRC), six of the keys belonged to intermediate CAs that issue TLS certificates, and the other two belonged to CAs that issue code-signing certificates. Microsoft's own systems were not compromised.

Mozilla's investigation reported that the private key values for the P-384 keys used by the eight intermediate CAs were below 256. Private keys are supposed to be generated securely, but values this small are easy to guess. The problem stems from how the individual keys were generated, however, not from a break in the P-384 cryptographic scheme itself. If a private key can be guessed, an attacker could potentially impersonate the CA and sign certificates, so trust in certificates based on the affected keys needs to be removed.

Microsoft's response, in chronological order: on October 20 it blocked the problematic intermediate CAs, and on October 26 it removed six higher-level root certificates and one cross-signed certificate from the trust list.

It is important to note that the eight compromised private keys and the seven certificates being removed from the trust list are not the same set of items counted two different ways. An intermediate CA links a root CA to end-entity certificates, while a cross-signed certificate builds a trust path through signing by another CA. Removing a higher-level certificate from the trust list affects certificate chain validation differently, and over a different range, than blocking the problematic intermediate CAs individually.

MSRC also explained that it separately updated the CRLSet for Microsoft Edge and WebView2 to block TLS certificates signed by the affected CAs. For the seven certificates removed from the Windows trust list on October 26, trust was scheduled to be revoked on the Edge side on October 27. However, the exact time that process was completed has not been confirmed, and there is no confirmation that the compromised keys were abused.

In addition, changes to Windows' default trust settings take effect only once the update information reaches each device. Trust settings that administrators added themselves, and certificate stores managed individually by applications, must be checked separately from Windows updates.

Which Windows Versions Are Covered and What Conditions Apply

The out-of-band update targets Windows devices that cannot automatically receive certificate trust lists. KB5134133 for Windows 11 is provided as a cumulative non-security update for versions 24H2, 25H2, and 26H2, and is available from the Microsoft Update Catalog.

Even for updates under the same KB number, the conditions vary by Windows version. For 24H2 and 25H2, updates from June 10, 2025 or later must already be installed. In environments involving multiple MSU packages or checkpoint cumulative updates, administrators must also confirm the installation order described in the KB. In air-gapped environments in particular, simply bringing this update package onto a device does not guarantee that it can be applied to every device.

The main target products and updates Microsoft released are as follows.

For Windows 10, the version number alone is not enough to determine whether a device is covered. In addition to the device's edition, administrators must check the conditions for Extended Security Updates (ESU) and Long-Term Servicing Channel (LTSC) against the relevant KB. For Windows Server 2025 as well, it is important to confirm the target device conditions and the update installation order.

One operational point needs particular care: the effect on Hotpatch, which applies updates while minimizing reboots. According to KB5134133, if this update is applied to a target device enrolled in Hotpatch, the device will not receive new Hotpatch updates until the January 2027 baseline update is installed. The KB for Windows Server 2025 also lists conditions related to Hotpatch.

Administrators therefore need to consider not only the need to update certificate trust settings, but also the effect on subsequent update operations. The Hotpatch restriction does not, however, mean that all Windows devices stop receiving updates.

Air-Gapped Environments Require Checking Two Certificate Lists

In Windows certificate trust management, trusted and untrusted certificates are managed in separate lists. In this case, the October 20 block of the intermediate CAs and the October 26 removal of trust for the higher-level certificates involve different lists. Confirming that one list has been updated therefore does not mean the change to the other has reached the device.

Microsoft's documentation for administrators explains how to distribute lists of trusted and untrusted certificates in environments with no direct internet access. Specifically, certificate information obtained externally is placed on an internal file server, and devices are pointed to it using Group Policy (GPO). Administrators should distinguish between devices that can receive certificate lists automatically and those that cannot, and check the distribution settings and actual application status for the latter.

The same documentation also describes commands for verifying certificate lists. Different commands are used to check the trusted list and the untrusted list.

# 信頼済み証明書リストの検証
certutil -verifyCTL AuthRoot

# 信頼されない証明書リストの検証
certutil -verifyCTL Disallowed

The first command verifies the trusted certificate list, and the second verifies the untrusted certificate list. Running them alone, however, does not prove that this change was distributed properly. Administrators should also check the last synchronization time and the status of the target certificates to confirm that the necessary changes have actually been applied.

Even when the Windows certificate lists are updated, not every application on a device necessarily uses the same trust settings. Successful list distribution and an application's ability to validate certificates correctly are separate matters, and actual connection testing is needed.

Watch for Connection Failures Caused by Removing Trust

When problematic certificates are removed from the trust list, administrators must also confirm that connections to legitimate services keep working. If the certificate chain presented by a server includes a root or cross-signed certificate that has now been removed, certificate validation may fail even for a legitimate service unless another valid trust path exists. On the other hand, results may differ if an alternative certificate chain is available or if an application validates certificates in a different way. The impact of this trust removal therefore cannot be treated as a connection failure common to every environment.

Administrators should first check the certificate chains of the services their organization provides and uses, and look for any dependency on the affected root or cross-signed certificates. Where there is one, they should proceed with migrating the necessary certificates and then test connections from the devices and applications actually in use. Even if a page loads normally in a browser, it does not follow that other business applications connecting to the same destination will work correctly.

Cloudflare's technical explanation likewise points out that some applications use certificate validation mechanisms different from the OS, or their own trust stores. Updating Windows certificate lists does not necessarily change the trust settings of such applications. Conversely, if a problematic certificate remains in an application's own trust store, validation results may differ from Windows even after Microsoft changes its default trust settings.

What administrators need to confirm for this out-of-band update is not just whether the update installed successfully. They need to check whether both the trusted and untrusted certificate lists have been applied to the device, whether the destination's certificate chain is sound, and which trust settings each application uses. Verifying these points shows whether the countermeasures against the problematic private keys are working properly and whether connections to legitimate services are being maintained.