For roughly eighteen months, eight intermediate certificate authorities operated by the Indian CA eMudhra were signed with private keys that anyone could have recovered almost instantly. As BleepingComputer reported on October 20, the P-384 keys generated in April 2025 were so weak that recovering one required testing only 256 possible values. Mozilla, Google, Apple and Microsoft have now blocked the certificates, but the incident exposes a structural problem that no single revocation can fix: in a hierarchical trust model, one organization's mistake becomes every relying party's exposure.
What happened at eMudhra?
A security researcher scanning public certificate data spotted the weakness on October 17, and another researcher published one of the recovered private keys on GitHub. Mozilla cryptography engineer Dennis Jackson described the keys as "effectively all-zeroes apart from the last byte." Google attributed the failure to insufficient randomness during key generation, which allowed anyone to forge trusted HTTPS certificates against clients that still trusted these CAs.
According to eMudhra, a flaw in the script used during its key generation ceremony produced a second, weaker key pair, and because its labels resembled those of the correct keys, it was mistakenly used to create the certificate signing requests. The company acknowledged "human errors in multiple steps of the process" and said it will reverify every key ceremony it has performed. Some of the affected certificates had also been submitted to Sectigo for cross-signing, extending the chain of parties exposed to the mistake.
How fast did the ecosystem respond?
By browser standards, the response was fast. Mozilla blocked the certificates through OneCRL on October 17 and shipped Firefox 158.0.1 on October 20 for users whose configurations had blocked the revocation update. Google blocked the six intermediates authorized to issue TLS certificates in Chrome the same day, Apple followed on October 19, and Microsoft on October 20. The Go project released patched versions under CVE-2026-111943.
Fast for browsers is not the same as fast for everything. Jackson's tracking site listed software still pending updates when the story broke, including the Debian and FreeBSD ca-certificates packages, Node.js and Bun. He also warned that the curl bundled with macOS may keep trusting the certificates because its bundle does not check revocation information.
Why is this a design problem, not just a vendor problem?
It would be easy to file this as one CA's operational failure. eMudhra says it found no evidence of misuse in Certificate Transparency logs, and that only one of the intermediates ever went into production. However, as SecurityWeek noted, not every client enforces Certificate Transparency, so the logs cannot prove the keys were never used against those clients during an exposure window that ran from April 2025 to October 2026.
The deeper issue is that PKI concentrates trust by design. Every relying party delegates its security to the key-generation discipline of every CA in its trust store, and to every CA those authorities cross-sign with. A single faulty script in one key ceremony created a forgery capability against any client that trusted the chain, and none of those clients had any way to detect the weakness on their own. They were protected only once a third party noticed the problem and their software vendor shipped an update.
What happens to devices that never get the update?
Browsers recover quickly because they are updated constantly. Industrial and embedded systems are not. PLCs, RTUs, HMIs, gateways and building controllers often ship with a fixed certificate bundle and run for a decade or more without a trust-store refresh, and many never check revocation at all, because CRL and OCSP checks assume reliable connectivity to the CA that air-gapped and segmented OT networks deliberately lack.
For those devices, revocation is effectively theoretical, and a compromised intermediate stays trusted for as long as the device stays in service. This is why PKI was never a viable foundation for encryption across most OT environments, and incidents like this one show why it will not become one.
What does trust look like without a certificate authority?
Autonomous Key Management™ removes the third-party CA from the trust equation entirely. Instead of inheriting trust from a hierarchy of signing keys held by outside organizations, AKM provisions devices once and then generates quantum-resilient symmetric session keys autonomously, with every session independently verified and refreshed. There is no intermediate certificate to compromise, no revocation list to distribute, and no dependency on a browser vendor's update schedule.
In enterprise IT, that means AKM replaces PKI and the certificate lifecycle work that comes with it, at roughly 10% of PKI's total cost of ownership. In OT, AKM delivers authenticated encryption to the endpoints PKI could never reach, including air-gapped networks and constrained devices, because its sub-1MB footprint and lack of CA dependency fit environments where certificates never could.
What should security leaders take from this?
The eMudhra incident ended reasonably well for most browser users, because a handful of large vendors acted within days. The more useful question for security leaders is what would happen if a CA their own devices trust made the same mistake tomorrow, and how many of their systems would still be trusting the bad keys a year later. For most organizations running OT or embedded infrastructure, the answer is that they would not know, and that uncertainty is the real cost of outsourcing trust to a hierarchy you cannot verify.
About AKMSecure
AKMSecure delivers a patented Autonomous Key Management™ protocol built to replace outdated PKI approaches with a dynamic, quantum-secure, air-gapped-capable architecture. Instead of relying on persistent credentials that can be stolen, reused, or abused, AKM enables independently verified sessions with no standing privileges left behind. The result is a model that better aligns with Zero Trust principles, reduces certificate-based risk, and supports resilient operations across enterprise IT, OT and Tactical Edge environments. Built to NSA-grade security standards and deployable as a lightweight SDK, AKMSecure helps organizations modernize trust at the protocol layer without rebuilding everything around it.
