Skip to content

Insights

When Trust Breaks: What 8 Compromised TLS Certificates Mean for Your Enterprise

Eight eMudhra CA certificates had keys recoverable in under a second. Browsers were fixed in days; the servers, pipelines and devices behind them were not.

7 min read

David Weiss, Field CTO, Office of the CISO, QuSecure / 21 October 2026

The internet’s trust layer just cracked

On October 17, 2026, a researcher reported that the private keys behind eight intermediate certificates from eMudhra, an Indian certificate authority (CA), were so weak they could be recovered on a laptop in under a second (Scott Helme). The internet had found out that eight of its trusted ID-issuers had been handing out IDs with locks anyone could pick.

Whoever holds those keys can mint a valid-looking certificate for any website: your bank, your cloud provider, your payroll vendor. Google, Mozilla, Apple and Microsoft moved fast to block the certificates in their browsers and operating systems within days (The Hacker News). Ars Technica called it the internet going “on high alert.”

The browser fix is the good news. The harder question for every enterprise is what happens everywhere else: the servers, pipelines, apps and devices that never got the memo.

Certificates in plain English: the passport office analogy

Think of a TLS certificate as a website’s passport. When your laptop connects to a site, the site shows its passport, and your laptop checks two things: is the name right, and was it issued by a passport office I trust?

  • Root CAs are the national governments. Your devices ship with a built-in list of the ones they trust.
  • Intermediate CAs are the regional passport offices. They do the day-to-day issuing on the government’s behalf.
  • The private key is the office’s official stamp. Only the real office should ever hold it.

In this case, eight regional offices had stamps that anyone could copy. A P-384 private key is meant to be a random 384-bit number, one of roughly 2^384 possibilities, which is a 4 followed by 115 zeros. The observable universe holds roughly 10^80 atoms, so the number of valid possibilities is about 35 orders of magnitude larger than the number of atoms in existence. By contrast, these eight keys had at most 255 possible values, and one of them was just the number 4 (Scott Helme). eMudhra has attributed it to a bug in its key-generation ceremony script.

This was not a hack of the encryption itself. As Cloudflare put it, it is a problem with authentication, not with TLS’s encryption algorithms. But authentication is the whole game: if an attacker can forge the passport, encryption only guarantees you have a private conversation with the impostor.

Why browsers are only half the story

Browsers got protected automatically, and most of your enterprise traffic does not come from browsers. Browsers receive revocation updates silently and require Certificate Transparency logs, so a forged certificate would struggle to pass there (The Hacker News).

The rest of the enterprise works differently. Most non-browser software trusts a CA bundle stored on disk and does not check revocation by default. In testing, a forged certificate for a major payments API was accepted with default settings by curl, Python and Node (Scott Helme). The places that matter most:

  • Server-to-server API calls that carry credentials and customer data
  • CI/CD pipelines holding cloud keys and code-signing keys
  • Containers and base images with baked-in trust stores that only change on rebuild
  • Installers and self-updaters that pull code over HTTPS
  • IoT, OT and embedded devices with frozen trust bundles. Devices that cannot be updated may keep trusting these certificates until they expire in July 2039.

The exposure window was roughly 17 months, and because the keys were never stolen, there is no break-in to investigate (Scott Helme). Cloudflare’s guidance boils down to one instruction: test the real TLS path, because a browser check passing does not prove a background service is safe (Cloudflare).

That leaves every CISO with one question they need answered today: is any of our live traffic touching these certificates right now? Patch lists and vendor advisories cannot answer it. Only visibility into your own network can.

The bigger lesson: this is a crypto-agility fire drill

The eMudhra incident is a preview of the post-quantum transition, compressed into one week. Every enterprise will eventually face the same three questions: where is this cryptography in use, what depends on it, and how fast can we change it?

The organizations that responded best this week were the ones that already knew where their certificates and trust stores lived, rather than the ones with the strongest algorithms. Chrome could push a fix in under two hours because it controls its own trust layer end to end (The Hacker News). Most enterprises do not have that kind of control over the cryptography running across their networks.

Quantum computing turns that same exercise from a one-time scramble into a full migration. When today’s RSA and elliptic-curve algorithms need to be replaced, the work will touch every certificate, every connection and every device at once. The teams that build cryptographic visibility now will treat that day as a planned upgrade. Everyone else will be running this week’s fire drill at enterprise scale. That is what crypto-agility means in practice.

How QuProtect Recon Sensor answers the question in near real time

QuProtect Recon Sensor shows, in near real time, whether any live enterprise traffic is reaching a site that uses a compromised CA certificate, and puts the answer on a dashboard. It does not rely on a spreadsheet of assets or on every team remembering to patch. It watches what your network is actually doing.

Why that is hard, and why it matters. In TLS 1.3, the modern standard, the server’s certificate is encrypted during the handshake. A traditional passive tool watching the wire can see that a connection happened, but often not which certificate chain sat behind it. That is exactly the detail you need during an event like this one.

Recon Sensor closes that gap with Active Discovery, which supports scanning for TLS 1.3 certificates. Here is how it works:

  1. Observe real traffic. Recon Sensor uses network scanning to see the destinations your users, servers, pipelines and devices are actually connecting to.
  2. Retrieve the full chain. Active Discovery scans those endpoints, including TLS 1.3, to identify the certificate and the CA chain behind each one.
  3. Match against known-bad trust. Chains issued by compromised or distrusted CAs, such as the eight eMudhra intermediates, are flagged.
  4. Surface it on the dashboard. Security teams see which internal systems are touching affected sites, so they know where to act first.

What that means for a CISO this week:

  • An answer in hours. Instead of auditing every app, container and device, you see which ones are actually exposed.
  • Coverage beyond the browser. It sees the API calls, pipelines and machine-to-machine traffic that browser fixes do not protect.
  • Evidence you can show. You can show the board and auditors where you were exposed and when it was resolved.
  • Ready for the next one. The same visibility that finds a compromised CA today builds the cryptographic inventory you will need for the migration to post-quantum cryptography (PQC) tomorrow.

This is the core idea behind QuProtect: you cannot protect, rotate or upgrade cryptography you cannot see. Recon Sensor turns an internet-wide alert into a specific, actionable list for your environment.

What security leaders should do this week

  1. Find your exposure first. Identify which systems are actually connecting to sites that chain to the affected eMudhra intermediates.
  2. Update trust stores beyond the browser. That means OS ca-certificates packages, Python certifi, Go, Node and Homebrew, followed by rebuilding container images (Scott Helme).
  3. Do not “fix” errors by switching off verification. If certificate errors appear after patching, turning verification off removes the very protection the update restored (Cloudflare).
  4. Flag the devices you cannot patch. For IoT and OT with frozen trust bundles, monitoring their traffic is the practical control.
  5. Treat this as a rehearsal. Use it to build the cryptographic inventory your post-quantum roadmap will depend on.

The next certificate incident is a matter of when, and so is the quantum transition. QuSecure, a 2026 Gartner Cool Vendor and Cyber Defense Magazine Top InfoSec Innovator, built QuProtect so enterprises can see their cryptography, act on it in near real time and stay agile as the threats change.

Want to know if your traffic touched an affected certificate? Talk to QuSecure about a Recon Sensor assessment.

Sources

Frequently asked questions

See all questions

  • What happened with the eMudhra certificates?

    On October 17, 2026, a researcher reported that the private keys behind eight intermediate certificates from eMudhra, an Indian certificate authority, were weak enough to recover on a laptop in under a second. A normal key of that type has roughly 2^384 possible values; these had at most 255. Anyone holding the keys could mint a valid-looking certificate for any website. Google, Mozilla, Apple and Microsoft blocked the certificates within days. eMudhra attributed the fault to a bug in its key-generation ceremony script.

  • If browsers blocked the compromised certificates, is enterprise traffic safe?

    Only the browser half. Browsers receive revocation updates silently and require Certificate Transparency logs, so a forged certificate would struggle to pass there. Most non-browser software trusts a CA bundle stored on disk and does not check revocation by default: server-to-server API calls, CI/CD pipelines, containers with baked-in trust stores, self-updaters, and IoT or OT devices with frozen trust bundles. In testing, a forged certificate for a major payments API was accepted with default settings by curl, Python and Node.

  • How can an enterprise find which systems are connecting through a compromised certificate authority?

    By watching live traffic rather than an asset spreadsheet. In TLS 1.3 the server’s certificate is encrypted during the handshake, so a passive tool can see that a connection happened but often not which chain sat behind it. QuProtect Recon Sensor’s Active Discovery scans the endpoints the network is actually connecting to, retrieves each certificate and CA chain including TLS 1.3, flags chains issued by compromised or distrusted CAs, and shows which internal systems are touching affected sites on a dashboard.

  • Should certificate verification be switched off if errors appear after a trust-store update?

    No. Certificate errors after patching usually mean the update is doing its job and a connection is chaining to a certificate that is no longer trusted. Turning verification off removes the protection the update restored. Cloudflare’s guidance is to test the real TLS path each service uses, update the trust store it reads (the OS ca-certificates package, Python certifi, Go, Node, Homebrew), and rebuild container images that bake in their own bundle.

  • What does a compromised certificate authority have to do with post-quantum migration?

    The same three questions. A CA compromise asks where this cryptography is in use, what depends on it, and how fast it can be changed, for a handful of certificates over one week. The post-quantum migration asks the same of every certificate, connection and device at once, when RSA and elliptic-curve algorithms have to be replaced. The teams with cryptographic visibility treat the first as a drill for the second; the rest run the drill at enterprise scale.

Filed under

Ready to take command of your cryptography?

Get a personalized briefing from our team and see QuProtect R3 in action.