The private key of a certificate authority (CA) should be one of the most secure secrets in digital infrastructure. In eMudhra’s case, eight CA private keys turned out to not be very secret. In fact, they were so weak that security researchers could derive them from their corresponding public keys almost instantly. Security researcher Scott Helme found private-key values as small as 4, 56, and 115.

That is a significant lapse in the process and workflow for certificate generation. But the bigger takeaway for security leaders is that organizations cannot treat public key infrastructure (PKI) certificate trust as static infrastructure.

What Happened?

A security researcher notified eMudhra, Apple, Google, Microsoft, and Mozilla that the private keys associated with eight eMudhra intermediate CA certificates were cryptographically weak. An intermediate CA is authorized by a trusted root CA to issue certificates to entities such as web servers, forming a certificate chain that establishes cryptographic trust. Six intermediates were associated with TLS issuance and two with code signing. The certificates had been created during a key-generation ceremony on April 30, 2025.

According to eMudhra, its keys were generated using FIPS 140-2 Level 3-certified hardware security modules, but a key wrap/unwrap step created a second set of weak keys alongside the intended strong keys. The weak keys were subsequently used for the certificates published into the trust ecosystem. eMudhra is investigating the exact root cause, and its final forensic analysis will help clarify things. But regardless of the root cause, the incident creates some clear and urgent next steps for organizations to take.

What Are The Security Implications?

The immediate theoretical consequence of possessing a CA’s private key is severe: An attacker could create fraudulent certificates chaining through that intermediate. For TLS, that creates the potential to impersonate legitimate services and intercept or modify communications where a client continues to trust the affected chain.

Major browser and platform providers moved quickly this week to block or remove the affected eMudhra CAs from their trust stores, but many nonbrowser and/or nonpatchable TLS clients (e.g., OT/IoT devices) depend on locally installed CA bundles and may not automatically consume browser-style revocation mechanisms or support Certificate Transparency (a framework designed to protect against and monitor for certificate misissuances). CI/CD runners, application runtimes, containers, server-to-server APIs, package-management infrastructure, OT and IoT systems, and embedded devices therefore deserve as much (or more) scrutiny as employee browsers.

What Should Organizations Do?

Security and risk leaders should use the eMudhra incident as an opportunity to ask a fundamental question: If a trusted CA or certificate hierarchy became untrustworthy today, could we find everywhere we depend on it, enforce certificate status-checking, and change that trust quickly?

Forrester recommends that security and risk leaders take the following actions:

  • Discover your certificate and trust dependencies. Use certificate lifecycle management and asset discovery capabilities to identify certificates, issuing CAs, and certificate chains across your environment. Solutions from AppViewX, Keyfactor, Sectigo, and Palo Alto Networks can help here. Inventory CA trust stores across operating systems, containers, Java runtimes, application frameworks, CI/CD systems, network appliances, IoT/OT devices, and internally developed material. Pay particular attention to systems with static or infrequently updated CA bundles. Identify independently maintained or stale trust stores, instead of assuming that updating browsers protects the environment. In this instance, organizations should focus on VPNs, security networking infrastructure, CI/CD pipelines, software supply chains, and IoT and embedded systems.
  • Accelerate trust-store and software updates. Update operating-system CA packages and application-specific trust stores, rebuild container images when corrected base images are available, and identify systems that cannot readily receive trust-store updates. Prioritize vendor fixes addressing the affected intermediates. Include application runtimes and cloud-native workloads, not only endpoints. For applications built with Go, a widely used programming language and runtime for cloud-native software, that includes the fixes provided in Go 1.27.3 and 1.26.10 for CVE-2026-111943. For systems that can’t readily be updated, determine the appropriate vendor update or compensating control based on how that system actually validates certificates.
  • Treat cryptoagility as a PKI resilience requirement. CA redundancy should become a resilience requirement, not an emergency response. Organizations should understand how quickly they could replace certificates, remove trust in a CA or hierarchy, and migrate critical services to an alternative provider. That means integrating certificate lifecycle management with asset discovery, policy, automation, and cryptoagility planning rather than managing certificates as isolated expiration dates.
  • Use the incident as a springboard to get PQS/PQC funding. As 2029/2030 deadlines for post-quantum migrations loom, organizations should treat this incident as a wake-up call to start the process of discovering and prioritizing not only compromised/compromisable certificates but generally all quantum-vulnerable (RSA, DH, ECC) asymmetrical cryptography technologies and certificates. Upgrading to hybrid certificates serves two purposes: mitigating the current exposure in the wake of the eMudhra CA compromise and, more importantly, ensuring cryptoagility and migration to PQC certificates.
  • Demand better certificate status-checking. Don’t assume that every system will recognize when certificate trust should end. Identify products with weak or inconsistent revocation and distrust mechanisms, mitigate those gaps, and press vendors to make timely certificate status-checking and rapid distrust capabilities standard.

If you would like to discuss how the recommendations above apply to your environment or have any additional questions on this topic, schedule an inquiry or guidance session with us.

Share