A Certified Process
A company’s security keys passed two independent audits until an external researcher found them to be weak and could have been worked out by anyone with the right skills. The eMudhra incident raises a critical question: what can an audit establish about a system, and what does it leave untested? eMudhra, a Bengaluru-based certificate authority that issues the TLS certificates behind the padlock in a browser, the digital IDs that confirm a website is genuine. On April 30, 2025, it held a key generation ceremony for a set of intermediate certificates under its emSign ECC Root CA-G3. The ritual was meant to be exacting: scripted, witnessed and performed on FIPS 140-2 Level 3 hardware security modules. By mid-2025, the resulting certificates sat in a browser trust list. Over the following year and a half, they successfully passed two consecutive independent audits.
The Discovery
On October 17, 2026, an independent researcher exposed what none of these audits had caught. He had recovered the private keys behind eight intermediate certificates, which had been generated with insufficient randomness. Google, Mozilla, Apple and Microsoft moved within days after the news. Chrome began removing the root on October 27. India’s IT ministry formed a special investigation team, and eMudhra announced it would exit the global TLS certification business. The company’s account is narrow, stating the production of a second, weaker set of keys alongside the stronger ones, and the weak set was the one published. It reports no breach, no end-user certificates issued from the affected intermediates and no evidence of exploitation. However, what it hasn’t confirmed is the root cause, the specific auditors and the scope of their work.
What Audits Miss
The uncomfortable question isn’t how a mistake occurred, but how a mistake of this magnitude survived every layer built to catch it. The answer may lie in what each layer truly certifies. Hardware certification speaks to the device and not the choreography around it. An audit tests whether documented controls existed and were being followed at a given point in time. Neither step asks the most basic question of a key: is it sound? If a ceremony can be performed exactly as scripted and still emit a second, weaker key pair, then the process compliance and cryptographic quality are separable. In such a case, an audit can verify the first while the second fails. Whether the published keys fell within the auditors’ scope is precisely the detail that hasn’t been disclosed yet.
The Outside Catch
These are alleged explanations and not solid findings. However, the pattern of detection is itself instructive. The flaw was caught by an external researcher and contained by root programs that acted swiftly on his report. That is the open ecosystem working as designed, and it is a quiet rebuke to any assumption that a clean audit can be guaranteed. It comes as an attestation, and attestations carry their fair share of limits.
Who Answers?
Accountability remains on the null. The ministry has clarified that it wasn’t a part of the audits, which leaves the question of who answers for an assurance regime that missed this fault: the auditors, the authority or the browser programs that accepted the audits as satisfactory grounds for trust. The promised root-cause report is the real test. If it publishes the audit scope, the auditor’s findings and the exact point of failure, then the industry can learn whether it was an isolated lapse or a blind spot built into the verification process. If it does not, then the paradox will outlast the incident.
