What happened
The weak keys originated in an April 2025 key-generation ceremony that eMudhra says produced a second, weak key set during a wrap and unwrap step. According to Mozilla Security Blog, on 17 October 2026 at 20:06 UTC, Mozilla received a report that private keys for eight eMudhra intermediate certificates were compromised. Mozilla said private keys associated with eight eMudhra intermediate certificates were compromised and could be used to issue fraudulent HTTPS certificates.
By 22:59 UTC on 17 October 2026, Mozilla had distributed OneCRL protection to Firefox users with standard configurations. Mozilla released Firefox 158.0.1, Firefox ESR 115.43.1 and Firefox ESR 153.5.1, and updated NSS 3.131.1 to remove the signing root from its trusted certificate list. Cloudflare directed customers to cloudflared 2026.10.2 and Cloudflare desktop client version 2026.8.2115.0, with mobile versions varying by application and operating system.
On 22 October 2026, eMudhra’s board decided to withdraw from the global SSL/TLS certificate business. eMudhra said its G1 RSA roots would continue during the transition, replacement certificates would be offered through partners, and revocation and status services would run until issued certificates expire or are replaced. The company also committed to completing a root-cause report for browser root programmes.
eMudhra said no end-entity certificates were issued from the affected certificate authorities, its infrastructure was not compromised and no data was breached. Cloudflare said its review had not identified active exploitation on Cloudflare services. No actor responsible for exploiting or intentionally creating the weak keys was identified in the cited sources. Attribution posture: No actor attribution has been established; Mozilla and eMudhra describe a key-generation failure rather than a named adversary. The cited source did not publish the actor-attribution detail described as Actor identity.
Why this matters now
The board decision changes an incident-response task into a supplier transition. Enterprises must now plan certificate replacement and trust-store hygiene while eMudhra works with browser programmes and partners, rather than treating revocation of eight intermediates as the final operational event.
Browser users with standard configurations received rapid protection, but enterprises often maintain custom certificate bundles, pinned chains, containers, appliances and server-side trust stores. Those assets may not inherit browser controls and can experience either residual trust or unexpected breakage as roots and intermediates are removed.
Certificate transitions can disrupt authentication between services even when no fraudulent certificate was used. Organisations need to distinguish public browser trust, mutual TLS, origin validation, code signing and private PKI dependencies so that replacement work does not create outages or weaken authentication controls.
eMudhra says its other digital-signature, identity and enterprise-PKI businesses are separate and unaffected. Customers should test that boundary against their own contracts, certificate inventories and service dependencies rather than assuming product branding maps cleanly to technical separation.
The decision for security leaders
Establish a certificate-transition programme owned jointly by PKI engineering, network security and service owners. The inventory must cover public certificates, mutual TLS, origin validation, code-signing trust, appliances, containers and applications that bundle their own stores.
Prioritise systems that do not inherit browser or operating-system trust updates. Validate whether each dependency should distrust the affected chain, replace an issued certificate or migrate to a different provider, and test authentication paths before production changes.
Treat eMudhra’s exit as a supplier-continuity event. Procurement and risk teams should obtain transition schedules, replacement-provider responsibilities, status-service commitments and the final root-cause report before accepting long-term closure.
Evidence of closure
- Certificate inventory identifies every eMudhra dependency and accountable service owner.
- Managed and custom trust stores contain the approved distrust updates.
- Replacement certificates pass production-representative authentication testing.
- Supplier assurance documents the transition schedule and remaining limitations.
The Security.io assessment
The cited sources establish compromised intermediate private keys, rapid browser mitigation and the provider’s withdrawal decision. They do not establish observed fraudulent issuance or a successful interception campaign. The immediate enterprise risk is therefore a combination of residual trust exposure and migration-related service failure.
This event is not a weakness in TLS encryption. The problem is certificate authentication: possession of a trusted issuing key can enable forged identities, while distrust can cause legitimate chains to fail. Custom trust stores and pinned configurations are the assets most likely to diverge from browser-managed protection.
The board decision materially changes the time horizon. Organisations now need durable certificate and supplier migration evidence, not only proof that emergency browser updates were installed. Closure should depend on inventory reconciliation, tested replacement and explicit disposition of every custom trust relationship.
Questions for the morning meeting
- Does the organisation use eMudhra certificates, roots or intermediates in public, private or pinned trust stores?
- Which applications bundle certificate stores that do not inherit browser or operating-system updates?
- Who owns certificate replacement and outage prevention across internet-facing and machine-to-machine services?
- Can the organisation identify every dependency on eMudhra’s global SSL/TLS business?
- What assurance is required from replacement certificate providers and migration partners?