October 23, 2026

Compromise of eMudhra Intermediate Certificate Authority Signing Keys and the Impact on OT/ICS Trust Chains

Security Advisory Brief

On October 21, 2026, the Indian Computer Emergency Response Team (CERT-In) published advisory CIAD-2026-0050 disclosing the compromise of the private keys behind eight intermediate Certificate Authority (CA) certificates operated by eMudhra under its emSign global trust hierarchy. The affected set comprises six Transport Layer Security (TLS) issuing certificates and, of greater concern to operational technology environments, two code-signing issuing certificates. Because the keys can be mathematically reconstructed from information that is published in every certificate, any party in possession of a copy of the certificate can derive the matching private key and sign content that chains to a widely trusted root.

The root cause is not a theft or an intrusion. During a key generation ceremony conducted on April 30, 2025, a flawed script produced a second, weaker set of signing keys alongside the intended strong keys, and the weak keys were mistakenly selected for the intermediate certificates because their labels resembled those of the correctly generated keys. Public analysis reported to the browser root programs indicates the weak key material was small enough to be recovered by testing on the order of a few hundred candidate values, and researchers demonstrated recovery of a working private key from a public certificate in under one second. Six of the affected TLS intermediates chain to the emSign ECC Root CA-G3; the two code-signing intermediates, identified as EM OV CS CA-G3B and EM OV CS CA-G3C, are the elements most relevant to software and firmware trust.

Browser and operating-system vendors moved quickly, distributing revocation of the six TLS intermediates through mechanisms such as Mozilla OneCRL, CRLite, and the Chrome CRLSet, and Google has scheduled removal of the emSign ECC Root CA-G3 from the Chrome Root Store effective October 27, 2026. These fixes protect general-purpose browsers and frequently updated endpoints, but they do not reach the embedded trust stores, long-lived controllers, and air-gapped assets that characterize operational technology (OT) and industrial control system (ICS) environments. No CVE identifier or CVSS score is associated with this incident because it is a failure in the certificate issuance process rather than a software defect in a specific product; the risk must therefore be assessed in terms of trust, not a vulnerability score.

Threats and Vulnerabilities

The central threat is the ability of an attacker to produce a cryptographically valid signature that chains to a root certificate still trusted by many systems. For the six TLS intermediates, this means a forged server certificate could allow an adversary to impersonate a legitimate website or device endpoint and to intercept or manipulate encrypted traffic without triggering a certificate warning on any client that still trusts the emSign ECC Root CA-G3 and does not independently check revocation. CERT-In and eMudhra report that, as of disclosure, there is no confirmed evidence that the compromised keys were used to issue fraudulent certificates, and public Certificate Transparency logs showed no end-entity certificates chaining to the six website intermediates; however, because the weak keys have existed since April 2025, the absence of logged misuse cannot be read as a guarantee that no misuse occurred.

The two code-signing intermediates represent the sharpest edge for OT/ICS asset owners. Code-signing path validation is separate from TLS path validation, and the automatic browser remediation does not address it: Chrome, for example, declined to block the two code-signing certificates through its TLS revocation channel because its web verifier will not build a code-signing path. An adversary able to derive these intermediate keys could sign a malicious installer, driver, firmware image, or update package so that it appears to originate from a trusted publisher. In industrial environments, where asset owners routinely rely on a valid digital signature as the primary assurance that a firmware or software update is authentic, a forged signature chaining to a trusted intermediate undermines the exact control that protects engineering workstations, HMIs, historians, protocol gateways, and the controllers they program.

The exposure is compounded by how trust is distributed and updated. The browser and operating-system fixes assume a device that regularly retrieves current trust lists and revocation data. OT and ICS assets typically do not meet that assumption: controllers, remote terminal units, intelligent electronic devices, and protocol gateways carry trust stores baked into firmware; HMIs and historians frequently run end-of-life operating systems on infrequent maintenance cycles; and many segments are isolated from the internet, so Online Certificate Status Protocol and certificate revocation list lookups cannot complete. Where revocation checking is configured to fail open to preserve availability, as is common in OT, a client will silently accept a forged certificate rather than block it. Software built with libraries that embed their own trust store, including applications compiled in Go and tools bundling certifi, webpki-roots, or their own CA bundle, will continue to trust the compromised chain until the vendor rebuilds and redistributes them.

Client Impact

Operationally, the greatest risk for an industrial organization is a loss of assurance in the software and firmware supply chain and in the authenticity of encrypted OT connections. If any engineering software, device firmware, or update package in the environment was signed under the eMudhra code-signing hierarchy, the integrity guarantee that normally accompanies a valid signature can no longer be taken at face value until the vendor confirms re-signing under a clean hierarchy. Likewise, any OT web interface, OPC UA server, MQTT broker, remote-access gateway, or vendor cloud connector presenting a certificate under the affected roots could be impersonated by an attacker on a client that still trusts emSign and does not fail closed on revocation, enabling man-in-the-middle manipulation of commands or data. There is also a secondary availability risk from the remediation itself: once the emSign ECC Root CA-G3 is removed from major trust stores on October 27, 2026, any legitimate OT or enterprise service still presenting a certificate under that root may begin to fail connections or throw errors, which in an industrial setting can disrupt monitoring, remote access, or data historian collection.

From a compliance and governance standpoint, the incident implicates the software integrity, secure remote access, and system hardening expectations embedded in frameworks such as NIST SP 800-82, IEC 62443, and the NERC CIP standards, each of which assumes that digital signatures and certificate validation can be relied upon as controls. Organizations in regulated sectors should expect to document their exposure analysis, their vendor engagement, and their remediation decisions as evidence of due diligence, particularly where an affected certificate protected a system in scope for regulatory oversight. The event is also a reminder that certificate and trust-store inventory, long treated as an IT concern, is a material OT security control that belongs in the asset management and configuration management programs those frameworks require.

Mitigations

The objective of the following actions is to locate reliance on the affected eMudhra hierarchy within OT and ICS environments, to withhold unwarranted trust in code signed under the compromised intermediates, and to apply trust-store updates without causing an operational outage:

Inventory certificate trust across the OT environment and identify any certificate that chains to emSign ECC Root CA-G3, emSign Root TLS CA-G3, or the eight affected intermediates (the TLS set in the EM DV/OV/EV TLS CA-G3B and -G3C families, and the code-signing set EM OV CS CA-G3B and EM OV CS CA-G3C). Prioritize HMI and historian web portals, OPC UA and MQTT endpoints, device management consoles, remote-access and VPN gateways, and vendor cloud connectors.
Engage affected OT and ICS vendors in writing to confirm whether any device firmware or software distributed to your sites was code-signed under EM OV CS CA-G3B or EM OV CS CA-G3C, whether embedded device trust stores include the affected roots, and when re-signed firmware or updated trust bundles will be available; track the responses as part of the exposure record.
Treat code-signing validation as provisional: until a vendor confirms that its firmware and software have been re-signed under a clean hierarchy, do not install updates on the basis of a valid eMudhra-chained signature alone, and verify package integrity out of band using vendor-published cryptographic hashes delivered over an independent channel.
Apply trust-store and library updates to managed OT endpoints such as engineering workstations, jump hosts, and Windows or Linux historians, including the operating-system certificate updates (for example Debian DSA-6572-1 and Ubuntu USN-8944-1/-2, and the Apple and Microsoft platform updates), rebuilt Go applications on Go 1.27.3 or 1.26.10, updated Node.js (26.12.1, 24.22.1, or 22.23.4), and refreshed certifi, webpki-roots, and curl CA bundles.
Do not disable certificate checking or instruct operators to bypass certificate warnings; where an OT client is configured to fail open on revocation and cannot be changed without risking availability, apply compensating controls such as strict network segmentation, allowlisting of known-good certificate thumbprints, and heightened monitoring of the affected connections until the certificate can be replaced.

Validate each change in a test or maintenance window before production rollout, and sequence the removal of the affected roots so that any legitimate OT service still presenting a certificate under those roots is re-issued on a clean hierarchy before trust is withdrawn.

1898 & Co. Response

1898 & Co. works alongside industrial operators to translate incidents like the eMudhra certificate compromise into concrete, OT-specific action rather than a generic IT patch exercise. Our teams have experience supporting certificate and trust-store inventory across industrial environments, where the systems that rely on a given root are often undocumented and where a withdrawn root can disrupt operations if it is removed without a re-issuance plan. We help clients distinguish the assets that are genuinely exposed from those that are not, so remediation effort is directed where it reduces real risk.

Drawing on our Managed Threat Protection and Response capabilities, we assist clients in monitoring OT networks for the signs that a forged certificate or an improperly signed update is being used, including unexpected certificate presentations on control-system connections and firmware or software installations that do not match an authorized change. Where an organization needs to validate the integrity of software and firmware already deployed, our assessment teams can help structure an out-of-band verification approach that does not depend on the compromised signing hierarchy.

Our consultants also help asset owners align their response with the software integrity and secure-access expectations of NIST SP 800-82, IEC 62443, and NERC CIP, and document the analysis and vendor engagement that regulators increasingly expect to see. The goal throughout is to help reduce exposure while preserving the availability that industrial operations depend on, and to leave the client with a repeatable process for managing certificate trust as an OT security control going forward.

Sources

Cyberthreat