When Trust Breaks: What the eMudhra CA Compromise Teaches Us About PKI Governance and Cryptographic Resilience

The recent compromise of eight eMudhra Intermediate Certificate Authorities raises two important questions for business leaders: how confident are you in the controls protecting your cryptographic infrastructure, and how prepared is your organisation to respond when the trust it depends upon is suddenly withdrawn?

While the incident concerns a specific Certificate Authority (CA), its implications extend far beyond eMudhra or the organisations directly affected. It exposes the importance of effective PKI governance and provides a valuable real-world example of the operational challenges businesses will face as cryptographic requirements evolve, particularly during the transition to Post-Quantum Cryptography (PQC).

What happened?

On 17 October 2026, a security researcher reported that the private keys associated with eight eMudhra Intermediate CAs could be recovered from their publicly available certificates. The issue originated during a Key Generation Ceremony on 30 April 2025. According to eMudhra's investigation, an additional step involving cryptographic key wrapping and unwrapping inadvertently created a second set of keys with extremely weak cryptographic properties.

These weak keys were subsequently used to generate the Intermediate CA certificates, rather than the correctly generated keys originally intended for use. Despite the use of certified Hardware Security Modules (HSMs), formal key-generation procedures and subsequent independent audits, the weakness remained undetected for approximately 18 months.

The affected intermediates reportedly issued no end-entity certificates. However, the incident prompted major browser vendors to block the compromised intermediates and remove trust in an associated root CA, creating a requirement to migrate approximately 30,000 legitimate certificates issued elsewhere in that hierarchy.

It is important to recognise that this was not a reported infrastructure intrusion or the result of quantum computing defeating an encryption algorithm. It was a failure in how cryptographic key material was generated, selected and assured. That distinction makes the incident particularly interesting.

Lesson 1: Governance is not an optional extra

When organisations commission a new PKI platform, there is often considerable attention on the underlying technology: selecting the Certificate Authority software, procuring HSMs, configuring infrastructure and integrating the service into existing systems.

However, the supporting governance activities, including Certificate Policies (CPs), Certification Practice Statements (CPSs), Key Signing Ceremonies and technical assurance, can sometimes be viewed as administrative overhead, adding time and cost to an implementation project. Consequently, there can be pressure to simplify them, reduce their scope or remove them altogether.

But what is the cost of getting it wrong?

As the eMudhra incident demonstrates, the consequences can extend well beyond the cost of technical remediation. They can include significant operational disruption, customer impact, contractual exposure and reputational damage.

A Key Signing Ceremony should not simply be a formal event where a series of documented steps are completed and witnessed. Its purpose is to provide demonstrable assurance that the cryptographic assets underpinning the PKI have been generated, configured and protected correctly.

That means validating not only that the required activities were performed, but that each activity produced the intended outcome. For example, when Unsung conducts Key Signing Ceremonies (KSCs), we employ technical segregation of duties, with one specialist executing the procedure and another independently overseeing and validating the activity, alongside customer representatives providing governance oversight.

Every step is documented, verified and evidenced. Before performing a production KSC, we dry-run the process in a representative environment to confirm the procedure, expected outcomes and evidence requirements. This matters because customer representatives attending a ceremony may be responsible for governance and approval without necessarily possessing the specialist technical knowledge required to detect subtle cryptographic defects.

Effective assurance therefore requires both governance oversight and sufficient technical expertise to validate what is actually happening. The same principle applies to audits.

Compliance does not always mean assurance

eMudhra has stated that the affected CA hierarchy underwent independent audits in consecutive years. It would be inappropriate to attribute responsibility to individual auditors without understanding their scope, technical expertise and the evidence presented to them. Nevertheless, the incident illustrates an important limitation of compliance-based assurance.

An audit may demonstrate that an organisation has established processes, implemented controls and retained the required documentation. That does not necessarily demonstrate that those controls have achieved their intended security outcomes. There is a substantial difference between confirming that a business system uses digital certificates and independently assessing whether the certificate, underlying key material, trust hierarchy and associated operational controls are cryptographically robust.

The level of specialist expertise required to perform the latter is considerably greater. This is why technical PKI assurance should complement broader information security audits, rather than simply be assumed to fall within their coverage.

Compliance should provide evidence that controls exist. Assurance should demonstrate that those controls are effective.

The importance of investigating the underlying cause

An additional detail makes this incident particularly noteworthy. In May and June 2025, eMudhra experienced a separate issue involving incorrectly signed Certificate Revocation Lists (CRLs) associated with the same intermediate CAs.

The subsequent disclosure indicates that the CRLs had initially been signed using the original, correctly generated keys. Because these did not correspond to the public keys in the issued CA certificates, the CRLs were subsequently re-signed using the weaker keys.

Questions have since been raised publicly about why that investigation did not lead to the underlying key-generation discrepancy being identified. We cannot know the full circumstances, priorities or internal constraints surrounding those decisions, and the investigation remains ongoing. However, it illustrates a familiar operational challenge.

IT operations teams are under increasing pressure to maintain growing numbers of business-critical systems, often without corresponding increases in headcount or specialist training. Restoring services becomes the immediate priority, and deeper investigation may be deferred, particularly where the required expertise is unavailable.

But restoring functionality and resolving the underlying security risk are not necessarily the same thing. As businesses become increasingly dependent on PKI, specialist operational knowledge and effective root-cause analysis become essential components of the overall assurance model.

Lesson 2: How prepared are businesses when trust must suddenly change?

The second lesson is more relevant to organisations that do not operate their own Certificate Authorities. Following the eMudhra disclosure, browser vendors took action to prevent compromised certificates from being trusted.

Google has announced the removal of the affected root from the Chrome Root Store, with the change expected to reach devices on 27 October 2026. This creates an immediate challenge for organisations holding legitimate certificates that chain to the affected root, even though those certificates were not issued by the compromised intermediates.

They need to identify affected certificates, obtain replacements from a trusted hierarchy, deploy them and ensure dependent services continue to function correctly. Approximately 30,000 certificates were initially estimated to require migration, with eMudhra indicating that around 97% had been issued through ACME automation. That last point is significant.

Certificate automation does not automatically equal cryptographic resilience.

Automation can accelerate issuance, renewal and deployment. However, an unscheduled change to a certificate's trust hierarchy is not necessarily handled by an existing automated renewal process, and deploying a new certificate is only one element of managing the business risk.

Changing certificates can alter the approved configuration baseline of critical services. That creates dependencies on change management, configuration control, testing, release management and service ownership. For organisations delivering services to external customers, there may also be contractual considerations:

• Can certificates be replaced unilaterally?
• Does the change require customer approval?
• What happens if the change causes an outage and triggers service credits or financial penalties?
• Who owns the decision to proceed when the immediate security risk of retaining a certificate must be balanced against the operational risk of replacing it?

These are not technical questions. They are business governance and operational resilience questions. Organisations increasingly need to manage cryptographic assets with the same discipline applied to security patching and vulnerability remediation. This means having clear asset ownership, risk-based prioritisation, established change procedures, appropriate operational authority and the capability to execute necessary changes within an acceptable timeframe.

Not every organisation will achieve this level of maturity immediately. There will always be competing investment priorities, but the important point is understanding the current level of exposure and having a credible, risk-based plan to improve it.

A real-world rehearsal for Post-Quantum Cryptography

This is where the eMudhra incident becomes particularly relevant to the emerging quantum threat.

A cryptographically relevant quantum computer will threaten the security of widely deployed public-key algorithms, including RSA and elliptic-curve cryptography.

The transition to PQC will require organisations to identify cryptographic dependencies, assess their exposure and migrate affected systems and services to appropriate replacement algorithms and technologies. Importantly, PQC migration is substantially broader than certificate replacement alone. It may also require changes to cryptographic protocols, software, hardware, trust hierarchies and applications.

However, many of the operational challenges are similar. An organisation will need to understand what cryptography it uses, where it is deployed, which business services depend upon it, who owns those services and how changes can be implemented safely.

Having products capable of supporting PQC is not the same as being operationally ready to migrate.

For me, compliance is meeting the bar; resilience is being able to remain compliant when the bar moves. That distinction is important.

A business could invest in PQC-capable infrastructure yet remain poorly prepared for cryptographic change because its certificates are not fully inventoried, its operational processes are fragmented or it lacks the authority and expertise to execute changes at scale. The eMudhra incident provides an opportunity to examine these weaknesses today, rather than discovering them during a future cryptographic transition.

A practical test for business leaders

A useful starting point for any CIO, COO or CISO would be to ask their security and operational teams a simple question:

If a CA or cryptographic algorithm underpinning our critical services became untrusted tomorrow, how would we respond?

Could you identify the affected certificates and their trust chains? Would you know which applications, devices and business services depend upon them? Could you coordinate replacement across infrastructure teams, suppliers and customers?

More importantly, could those changes be executed through established operational processes without an extended and potentially damaging approvals cycle?

These questions could form the basis of a relatively straightforward tabletop exercise, perhaps incorporated into existing Business Continuity or Disaster Recovery planning.

The purpose would not be to demonstrate that every certificate could be replaced overnight. It would be to understand current capabilities, identify operational constraints and establish what improvements would have the greatest benefit.

This is an approach that organisations already recognise when testing their response to major cyber incidents. Cryptographic trust should be treated with similar importance.

How Unsung can help

At Unsung, we see PKI as more than a collection of technical components. Effective digital trust requires technology, process, governance and specialist operational capability working together.

Our PKI Health Check examines the architecture, configuration, security controls and operational governance supporting an organisation's PKI, helping to identify weaknesses that may not be visible through broader security audits.

Our consultancy, design and delivery teams support organisations in establishing assured PKI foundations, including CP/CPS development, HSM implementation, Key Signing Ceremonies and controlled PKI migrations.

Through our specialist PKI Support and Managed Services, we provide the expertise needed to maintain those controls, investigate complex issues and manage certificates and cryptographic services throughout their operational lifecycle.

We also help organisations establish Certificate Lifecycle Management capabilities and prepare for PQC through cryptographic discovery, risk assessment and practical migration planning.

The eMudhra incident is a reminder that even established trust infrastructures can experience fundamental failures.

The objective should not be to assume that every future incident can be prevented, but to ensure that governance reduces the likelihood of failure and operational resilience limits its consequences.

The question every business leader should be asking is not simply whether their cryptography is secure today, but whether their organisation is prepared to respond when tomorrow's requirements make today's trust arrangements unacceptable.

References

• Original incident disclosure and technical evidence — affected intermediates, recoverable private keys and trust-store responses.
• eMudhra official statement, 21 October 2026 — ceremony failure, audits, key material and company response.
• Mozilla's public incident investigation — technical explanation, previous CRL issue and estimated certificate migration volumes.
• Google's Chrome and Android security response — root-store removal and the 27 October deadline.
• NCSC post-quantum migration guidance — the wider cryptographic discovery, migration and resilience requirements.