The important distinction is between generating a secure key and certifying the right key. According to eMudhra’s incident account in Mozilla’s Bugzilla, the original hardware-generated keys were not the weak objects ultimately certified. That explanation remains the company’s account, rather than an independently established forensic conclusion.
How the workaround went wrong
The Register reports that delayed hardware security modules, or HSMs, pushed eMudhra toward an unusual migration plan: generate keys on Utimaco equipment, then transfer them to Crypto4A hardware. A looming cross-certification deadline added time pressure. The company used a custom Python script to support the transfer workflow during its April 30, 2025 key ceremony.
For eight ECDSA P-384 keys, eMudhra says a read-back operation retained only the leading byte of the private value. The resulting replacement objects had private scalars below 256 and were used to generate the certificate signing requests. Similar key labels contributed to selecting the wrong objects.
In other words, the expensive security hardware was not enough to protect the surrounding process. The analytical lesson is straightforward: protecting the original key accomplishes little if a workflow subsequently certifies a different, catastrophically weak one.
The RSA finding is different
The incident report also covers eight RSA-4096 keys. eMudhra says their mathematical integrity remained intact, but private-key components passed through the Python process’s memory. It therefore could not demonstrate compliance with its private-key-transfer requirements. That is a handling and compliance failure, not the same public-key-recovery finding affecting the ECDSA certificates.
The Windows connection is concrete. Mozilla’s initial incident record identifies six affected TLS intermediates trusted through the major root programs, including Microsoft’s, and two code-signing intermediates trusted by Microsoft.
What browser protection actually covered
Mozilla says Firefox blocked the affected certificates through OneCRL at 22:59 UTC on October 17, 2026, without requiring a browser update or restart. On October 20, it also announced an NSS trust-store change to protect downstream software without OneCRL protection.
Chrome’s Root Program separately reported blocking the six TLS intermediate public keys through CRLSet on October 17. That key-based block also covered Sectigo cross-certificates using the same keys. Chrome further said its default Certificate Transparency enforcement prevented unlogged fraudulent certificates from being trusted before that block.
Those are specific protections—not evidence that every Windows application, TLS library or certificate consumer received identical treatment.
What administrators should take away
Mozilla’s guidance distinguishes three situations:
- Clients that reliably check revocation and reject certificates when revocation information is absent need no additional action under that guidance.
- Trust-store operators able to block individual intermediates should distribute those blocks.
- Operators without that capability should evaluate whether removing trust in the signing roots is appropriate.
For enterprise administrators, the practical implication is to evaluate certificate consumers separately rather than treating “the browser is protected” as an estate-wide security verdict. Mozilla also warns that trust changes can interrupt access until affected servers move to replacement certificate chains.
The broader lesson is less exotic than the cryptography: a secure component does not guarantee a secure workflow. Hardware, scripts, object selection and validation must agree on which key is being trusted. Here, eMudhra’s explanation describes precisely where that agreement broke down.