The eMudhra Certificate Authority Incident Is A Wake-Up Call For Enterprise PKI
This incident matters less as a one-off vendor failure than as a governance test for enterprise trust management. Many organizations still treat PKI as a background utility owned by specialists, with limited executive visibility until certificates expire or an emergency occurs. That operating model is no longer sufficient. CIOs and CISOs should require clear accountability for certificate inventory, CA dependency mapping, revocation readiness, and decision rights for emergency trust changes across infrastructure, applications, devices, and third-party services.
The management challenge is operational, not just cryptographic. Browser vendors can move quickly, but enterprise environments often depend on slower-moving trust stores in containers, middleware, CI/CD tooling, appliances, OT, and embedded systems. That creates an uneven risk posture in which “patched” and “still trusting” systems coexist. Leaders should ask whether their teams can identify which business services rely on a compromised CA, how quickly they can push trust-store updates, and where compensating controls are needed when updates are impractical.
This also has portfolio implications. Certificate lifecycle management, asset discovery, software supply-chain controls, and cryptoagility are often funded separately, if at all. The better response is to treat them as one resilience capability with measurable outcomes: time to identify affected dependencies, time to remove trust, percentage of managed trust stores, and recovery time to reissue certificates through alternate providers.
Practical next questions:
- Who owns enterprise-wide CA dependency visibility and emergency distrust actions?
- Which critical services rely on static or independently maintained trust stores?
- Do vendor contracts and platform standards require rapid revocation and alternative CA support?
- Can current funding cover both immediate remediation and longer-term post-quantum migration readiness?
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.
Enjoyed this article? Sign up for our newsletter to receive regular insights and stay connected.