What happened
On 20 October 2026, Microsoft updated the Windows Disallowed Certificate Trust List and Edge/WebView2 CRLSet to block the affected certificate authorities and TLS certificates. On 26 October 2026, Microsoft released out-of-band Windows updates that removed six eMudhra G3 roots and one AAA Certificate Services cross-sign from the Windows trust list. On 27 October 2026, Microsoft removed the same seven certificates from the Microsoft Edge trust list. The later removals represent a broader default-trust decision than the initial blocking of known compromised intermediates.
Windows 11 update KB5134133 covers OS builds 26300.9725, 26200.9725 and 26100.9725 for versions 26H2, 25H2 and 24H2. Windows 10 update KB5134125 covers OS builds 19045.7811 and 19044.7811 for versions 22H2 and 21H2. Microsoft says the out-of-band packages are intended for devices that cannot reach its certificate-update service or have automatic Certificate Trust List updates disabled.
Microsoft distinguishes revoking compromised intermediate certificate authorities from the broader decision to remove their roots from default trust. Administrators can technically restore local trust for compatibility, but Microsoft says they should understand the associated risk before doing so. The cited sources did not establish a malicious actor, a confirmed forged-certificate campaign or a count of enterprises that accepted fraudulent certificates. Attribution posture: Microsoft attributed the trust action to compromised eMudhra certificate authority keys but named no malicious actor. The cited source did not publish the actor-attribution detail described as Observed malicious certificate use.
Why this matters now
The operational change is broader than revoking known intermediate certificates. Microsoft removed six eMudhra G3 roots and an AAA Certificate Services cross-sign from default Windows and Edge trust, changing how certificates under those hierarchies validate even when an application does not consult revocation data reliably.
The highest-risk systems are the ones least likely to receive automatic trust-list changes: disconnected servers, restricted administrative networks, laboratory systems, manufacturing environments and devices with automatic CTL updates disabled. Those estates can preserve trust in affected hierarchies after internet-connected systems have moved on.
Trust removal also creates availability pressure. Applications, identity providers, signed components or private integrations that depend on an affected chain may fail. That can prompt administrators to restore trust locally. Without explicit exception governance, an emergency compatibility workaround can silently reverse the security decision across a privileged environment.
The decision for security leaders
Assign PKI, endpoint engineering and identity owners to distinguish security-update deployment from application compatibility. The closure objective is not simply installing a package; it is proving that critical services no longer depend on a removed hierarchy or have a bounded exception.
Prioritise disconnected and restricted networks because their trust stores may remain stale indefinitely. Validate update applicability and installed build numbers locally rather than assuming central internet-connected management has propagated the change.
Do not permit administrators to restore trust ad hoc when a service fails. Any local trust decision should identify the exact certificate chain, business owner, compensating monitoring, replacement plan and expiry, with CISO approval for privileged or externally exposed services.
Evidence of closure
- Endpoint evidence confirms applicable out-of-band update installation and expected OS builds.
- Certificate-chain scans show no unapproved dependency on the seven removed certificates.
- The exception register records owner, scope, compensating control and expiry for every local re-trust.
- Application monitoring shows affected authentication and signing paths operate with replacement certificates.
The Security.io assessment
This is a control-plane trust event rather than an ordinary operating-system patch. Certificate stores decide which identities, websites and signed objects systems accept as valid. A weakly governed compatibility exception can therefore undermine protections across authentication, software execution and encrypted communications.
Microsoft’s evidence supports a broader precautionary trust decision, but it does not establish that a named threat actor forged certificates or that a specific enterprise accepted one. Security teams should avoid turning potential abuse into a confirmed incident while still removing affected trust where Microsoft directs.
The operational risk is asymmetric. Internet-connected devices may receive trust changes automatically, while isolated systems can remain exposed and invisible. Conversely, removing trust without chain discovery can cause outages. Mature closure requires both security-state validation and documented application impact.
Questions for the morning meeting
- Which disconnected or restricted Windows devices cannot receive automatic Certificate Trust List updates?
- Which business applications chain to the removed eMudhra or AAA Certificate Services certificates?
- Can affected certificates be replaced before trust removal disrupts authentication or signing?
- Who can approve local re-trust, and what evidence and expiry does that exception require?
- Are non-Windows trust stores and embedded applications covered by the same certificate review?