What happened
Google says eight subordinate CA private keys were generated with insufficient randomness, enabling forgery of trusted HTTPS certificates against clients that still trust those CAs. Google says the Chrome Root Program received the report on October 17, 2026 at 18:05 UTC and completed corroboration and a CRLSet block at 19:45 UTC. The SPKI-based block protects Chrome users against certificates sharing the affected keys without requiring a browser restart. Mozilla says it received the report at 20:06 UTC and completed OneCRL distribution by 22:59 UTC.
On October 20, 2026, Mozilla released Firefox 158.0.1, Firefox ESR 115.43.1, Firefox ESR 153.5.1 and NSS 3.131.1. Mozilla said the Firefox releases cover users whose custom configurations may have prevented normal OneCRL delivery, while the NSS update removes the root that signed the affected intermediates for other consumers of Mozilla’s trust store. Google says removal of emSign ECC Root CA - G3 from the Chrome Root Store is expected across dependent devices on October 27, 2026 PDT. Google warned that legitimate certificates chaining to that root may cease working.
eMudhra says the affected intermediates came from an April 2025 key generation ceremony; one entered production, none issued end-entity certificates, and its root CA private keys were not affected. The company says it revoked and contained the affected certificates and is investigating the key-generation process. The cited sources did not identify fraudulent certificates issued with the compromised keys or malicious use against an enterprise. Attribution posture: No malicious actor or fraudulent-certificate use has been established in the cited sources. The cited source did not publish the specific indicators described as Evidence of malicious certificate use.
Why this matters now
Managed browsers moved quickly, but enterprise trust is distributed across operating systems, application runtimes, appliances, containers, TLS inspection platforms and embedded devices. A browser CRLSet or OneCRL response does not prove that every enterprise workload has stopped trusting the affected hierarchy. Systems using private bundles, frozen images or infrequent update cycles may retain a certificate path capable of accepting a forged certificate, even when ordinary desktop browsing is already protected.
The operational decision is therefore broader than updating Firefox. Security teams must identify where emSign ECC Root CA - G3 or the affected intermediates remain trusted, determine whether legitimate enterprise services chain to that hierarchy, and sequence distrust without causing avoidable outages. eMudhra’s statement that no end-entity certificates were issued reduces observed impact, but the weakness was at intermediate-authority level and root-store operators are taking ecosystem-wide action.
The decision for security leaders
Assign PKI engineering and platform owners to build a decision-grade inventory of trust-store consumers. Separate managed browsers, which received rapid revocation controls, from runtimes and appliances that depend on static bundles or delayed operating-system updates. Identify legitimate internal or supplier certificates chaining to the affected root before enforcing distrust, then migrate those chains under controlled change.
Treat trust removal and business continuity as one coordinated decision. Internet-facing clients, TLS inspection infrastructure and privileged administrative paths should receive the earliest validation. Systems that cannot be updated need an explicit owner, compensating controls and an expiry date. Closure requires measured trust-store state and successful connection tests, not confirmation that desktop browsers auto-updated.
Evidence of closure
- Trust-store inventory identifies every system retaining the affected root or intermediates.
- Managed endpoints report the required Firefox, Firefox ESR or NSS versions.
- Connection tests confirm legitimate services operate after affected trust is removed.
- Approved exceptions identify compensating controls, accountable owners and expiry dates.
The Security.io assessment
The incident demonstrates why certificate-authority response cannot be evaluated solely through mainstream browser status. The affected keys held intermediate-authority power, while enterprise software consumes multiple trust distributions with different revocation behaviour. Rapid Chrome and Firefox controls materially reduce common browsing exposure, but residual risk concentrates in custom stores, embedded devices and software that does not consume online revocation or current root programmes.
eMudhra’s assertion that no affected intermediate issued end-entity certificates is important and should constrain claims of realised harm. It does not remove the need to distrust recoverable keys or test root-removal consequences. Our assessment changes if root programmes find additional weak keys, Certificate Transparency evidence contradicts the current issuance statement, or enterprises identify essential services that cannot migrate from the hierarchy without disruption.
Questions for the morning meeting
- Which enterprise systems rely on static, custom or infrequently updated certificate stores?
- Could root removal break customer-facing services, inspection platforms or internal applications?
- Who owns emergency PKI distrust decisions outside managed browsers?