eMudhra Statement on Recent Certificate Security Incident

Updates are listed in sequential order.

1. Update 1

   20 October 2026 Link to this update

   On 20 October 2026, Mozilla published a post on its Security Blog regarding eMudhra intermediate certificates. According to Mozilla:

   • On 17 October 2026 at 20:06 UTC, Mozilla received a report that private keys associated with eight eMudhra intermediate certificates had been compromised.
   • Mozilla blocked the affected certificates in Firefox through OneCRL, its centralised list of revoked certificates. By 22:59 UTC the same day, the update had reached all Firefox users with standard configurations, without requiring them to update or restart Firefox.
   • Mozilla released Firefox 158.0.1 (Desktop and Android), Firefox ESR 115.43.1 and Firefox ESR 153.5.1 to extend this protection to users whose custom settings may have prevented the OneCRL update.
   • Mozilla is updating the trusted certificate list in NSS (NSS 3.131.1) to remove the root certificate that signed the affected intermediates, to protect other applications that use Mozilla’s trust store but do not receive OneCRL updates.

2. Update 2

   20 October 2026 Link to this update

   eMudhra is actively investigating a security incident involving a specific set of intermediate CA certificates created as part of a Key Generation Ceremony (KGC) conducted in April 2025 within its public trust infrastructure.

   The incident is limited to these specific intermediate CA certificates and does not affect eMudhra's root CA private keys or other intermediate CAs.

   Importantly, none of the affected intermediate CAs were deployed in production, with the exception of one. Furthermore, none of these intermediate CAs, including the one deployed in production, have issued any end-entity certificates. This has been confirmed through our internal analysis and corroborated by publicly available Certificate Transparency records on crt.sh.

   Upon becoming aware of the incident, eMudhra initiated its incident response procedures, took measures to contain the affected certificates, and began working closely with browser and root-store operators to safeguard users and maintain the integrity of the broader WebPKI ecosystem.

   We are conducting a thorough investigation into the circumstances surrounding the incident and reviewing our security controls and operational procedures to identify and implement any necessary improvements.

   The security and integrity of our trust services remain our highest priority. We are committed to transparency, adherence to industry standards, and continued collaboration with the global WebPKI community.

   To avoid any misunderstanding, the removal of our Root CA’s C1 and C3 with Mozilla was a voluntary and planned activity and does not pertain to this security incident.

   We will provide further updates as our investigation progresses and additional findings are confirmed.

3. Update 3

   21 October 2026 Link to this update

   An Update on Our Global TLS Intermediate CA Incident

   What happened, who is affected, and what we are doing about it

   On October 17, 2026, an independent security researcher reported that the keys of eight (out of several) eMudhra Global TLS intermediate Certificate Authorities (CAs) were cryptographically weak. We revoked all eight intermediates the following day. No certificates had been issued from any of them, our infrastructure was not compromised, and no data was breached.

   We take this incident seriously. We believe an organization's character is shown in how it responds when something goes wrong, so this post sets out plainly what happened, who is affected, and what we are doing about it.

   What happened

   Eight intermediate (issuing) CAs in our Global TLS business were revoked because their published keys were weak. These intermediates sit under eMudhra's ECC root. As a consequence of the incident, the browser root programs have also distrusted that one ECC root.

   To be clear about what was and was not affected:

   • Intermediate keys were revoked, not root keys. The weakness was in the keys of the eight intermediates.
   • The root was distrusted by the root programs as a precaution. To the best of our knowledge, no other roots or intermediates were generated using the flawed process.
   • Seven of the eight intermediates were never used in production. The one that was in production had not issued a single certificate.

   The key sequence of events:

   • April 30, 2025: The eight intermediates were created in a Key Generation Ceremony.
   • Mid-2025: The hierarchy was included in browser trust lists. It has since passed two independent audit cycles.
   • October 17, 2026 (late evening, India time): We were made aware of the issue. The researcher notified Apple, Google, Microsoft and Mozilla at the same time.
   • October 18, 2026: We revoked all eight intermediates.

   How it happened

   The keys were generated on FIPS 140-2 Level 3 certified Hardware Security Modules (HSMs). Suggestions that HSMs were not used are incorrect. The problem was a flaw in one step of the ceremony procedure, not the absence of HSMs.

   During the ceremony, a key wrap/unwrap step produced a second, weak set of keys alongside the original strong keys. The weak keys were the ones published to the browser root stores. The issue went undetected for about 18 months, through two independent audit cycles. The researcher was able to reverse-engineer the weak keys, reportedly with the help of AI-assisted tooling.

   We have not yet confirmed the exact root cause. We will publish it in full once our investigation is complete. We are not aware of any evidence that the weak keys were recovered or exploited by anyone before the issue was disclosed.

   What is the actual impact

   The impact is limited to TLS certificates chaining to the distrusted ECC root, and it is contained to a single customer ecosystem in the United States.

   • The revoked intermediates themselves have no customer impact. They never issued a certificate, so no certificate in use anywhere relied on them.
   • The distrust of the ECC root affects one customer ecosystem in the United States. Certificates from that hierarchy are being replaced, and we are working directly with this customer on a transition plan.
   • The majority of TLS certificates we have issued are unaffected, because they chain to other trusted hierarchies.

   There is no impact whatsoever on:

   • Our digital signature and eSign services, in India or anywhere else in the world
   • emSigner
   • CertiNext
   • emCA
   • Privatrust
   • SecurePass

   These products and services run on separate infrastructure and continue to operate normally. Customers using them do not need to take any action.

   How we are handling it

   Our first priority is making sure the affected customer's services keep running without disruption.

   • Replacement certificates. We are issuing fresh certificates to the affected customer ecosystem from an alternate, independently operated, publicly trusted CA hierarchy.
   • Working with the root programs. We are cooperating fully with Apple, Google, Microsoft and Mozilla.
   • Clear communication. We have notified affected customers and partners directly. We are also making sure every customer knows exactly what is and is not affected: all of our enterprise applications, the majority of our TLS certificates, and all of our digital signature and eSign services remain unaffected.

   What we are putting in place

   CA redundancy for all Enterprise TLS customers. We are offering every Enterprise TLS customer certificates from an additional publicly trusted CA. If one hierarchy ever has a problem, customers can switch without interrupting their business. Keeping our customers running is one of our top priorities.

   A full review of our key generation process. We are reviewing every step of our Key Generation Ceremonies, starting with the wrap/unwrap step that caused this incident. We intend to deeply study how we can enhance the governance around our processes, and adopt AI based tooling in addition to other conventional means available to mitigate such occurences.

   Our commitment

   We acknowledge this incident and take full responsibility for it. Trust is the foundation of everything we do, and we intend to earn it back through action.

   • Transparency with the WebPKI community. We will keep working in good faith with the root programs and the CA/Browser Forum, and publish our root cause and investigation findings openly.
   • Full support for the affected customer. We are working closely with the one affected customer ecosystem in the United States to make sure they receive our utmost support throughout the transition.
   • Reducing risk for every TLS customer. We will work proactively with our unaffected TLS customers to put measures such as CA redundancy in place, so that no single event can disrupt their business.

   We thank the independent researcher who reported this issue responsibly, and our customers and partners for their trust.

4. Update 4

   22 October 2026 Latest Link to this update

   Availability of Sectigo Certificates as an Alternate Option

   eMudhra is making certificates issued by Sectigo available as an alternate option to all of our customers.

   Our G1 root certificates remain active and continue to be fully supported. Despite this, we are offering Sectigo-issued certificates to give customers additional peace of mind and flexibility in managing their certificate deployments.

   How to request a Sectigo certificate

   • Existing CertiNext users: Submit your request directly through your CertiNext account.
   • All other customers: Contact eMudhra Support at support@emudhra.com.
   • Customers in the USA: Contact support@certinext.io.

   Our support team will guide you through the process and help ensure a smooth experience for your environment.

   We remain committed to the security, reliability, and continuity of the services our customers depend on.