The eMudhra Weak Certificates and How to Protect Your IoT Assets

You don’t know what certificate authorities you trust. Neither does your security team.

In October 2026, researchers discovered a critical flaw in eMudhra’s G3 root certificate authority. The flaw originated in April 2025, when a key generation failure produced eight intermediate CA certificates for the G3 root with weak cryptographic keys. The kind of weakness where an attacker holding the private key could impersonate any website, application, or service that trusted those intermediates.

G3 is only one of eMudhra’s certificate roots. At publication time, G1 and G2 versions remain unaffected and were not compromised. This discovery is specific to the G3 generation.

What Happened With eMudhra Certificates

Root Version	Status	Key Generation Period	Entropy Level	Action Required
eMudhra G1	Unaffected	Standard	Normal (Full)	None
eMudhra G2	Unaffected	Standard	Normal (Full)	None
eMudhra G3	Compromised (8 Intermediates)	April 2025	Depleted (3 to 8 bits)	Revoke and Reissue OR Segment Affected Devices

eMudhra, a certificate authority operating in India and elsewhere, experienced a key generation failure in its G3 root. The company generated eight intermediate CA certificates that were supposed to contain 384 bits of cryptographic entropy, the randomness that makes certificates mathematically infeasible to forge. Instead, these keys contained only 3 to 8 bits of entropy.

To put this in perspective: a 3-bit key has 2³ possible values, which means eight possibilities. An attacker could brute-force it on a smartphone in milliseconds. All eight compromised intermediates, six TLS certificates, and two code-signing certificates have since been revoked by browser vendors and Microsoft.

Cryptographic Weakness Isn’t New

Cryptographic weaknesses often persist in production systems long after discovery. DES (Data Encryption Standard) used S-boxes, cryptographic building blocks whose design criteria were kept secret until 1994, when designer Don Coppersmith confirmed they were shaped to resist differential cryptanalysis (https://people.clarkson.edu/class/cs456/CoppersmithDES.pdf). Dual EC DRBG, standardized by NIST, contained mathematical constants that researchers suspected could enable predictable random number generation for anyone holding the discrete logarithm (https://www.schneier.com/essays/archives/2007/11/did_nsa_put_a_secret.html). These weaknesses persisted ecosystem-wide because organizations lacked visibility into their supply chains. eMudhra follows the same pattern: weak intermediates exist in certificate chains without detection.

At publication time, no known active exploitation has surfaced in the wild.

Why This Matters To You About eMudhra

Most CISOs can inventory their TLS certificates. You have tools, processes, maybe even a dashboard. You know which domains your organization owns, which certificates are bound to them, and when they expire.

But the root version of the CAs?  Organizations rarely have visibility into the full certificate chain.

You may not be aware of eMudhra but might be using eMudhra’s G3 Root through:

• Legacy on-premises systems still running on older certificate hierarchies
• Mobile apps, IoT devices, and internal services with minimal certificate governance

Asimily had chosen not to expose this level of information on every Certificate Authority to users, to avoid overwhelming them, just as it does with many other data to keep the UX clean and usable.

But with this new vulnerability, we have decided to expose that for eMudhra.  You can see the eMudhra Certificate Authority with Root Version now under the “Security Capabilities” filters on the Assets page in your Asimily dashboard.

You can also set a Policy to look for future devices running eMudhra from our Anomaly Detection-> Alerts (Under Custom Policies). Note that we’ve always flagged expired certificates as anomalies in your environment. This capability uses the same data, certificate authority without overwhelming you with noise. 

What You Should Do To Better Protect IoT Assets and Your Network From Bad Certs

Check whether any of your organization’s chains are through eMudhra’s G3 root. If they do, mark them for reissuance if possible. Where not possible, segment them using Asimily’s segmentation orchestration capabilities.

At least every Asimily customer has visibility into the certificates used in the organization right down to the Root Version. Asimily measures every asset it can. That includes workloads, operating systems, certificate providers, PHP presence, applications, and much, much more. Not just devices. Using both passive and safe active (optional) techniques to get the best, richest data possible.

Moving Forward From eMudhra

Cryptographic vulnerabilities are inevitable. Standards get broken. Implementations fail. When certificate authorities fail, the question isn’t whether it will happen again—it’s whether you’ll have visibility into that failure before it matters.

Start building that visibility now. Check your certificate supply chain. Understand which CAs are backing your certificates. Make sure that when the next compromise surfaces, your security team is the first to know, not the last. To see how Asimily surfaces that visibility automatically, explore Asimily’s Inventory and Visibility capabilities, part of its overall platform.