If you are a software engineer, or generally work in the tech industry, there is a good chance that you heard about the eMudhra Intermediate CA Compromise that was disclosed yesterday (October 20, 2026). If you don’t, you may have noticed an uptick in software updates for various products that you use.

I won’t go through the entire background of the situation as there are plenty of other posts, including the now public bug report from Mozilla, that describe the details of the compromise. However, I have had a number of folks reach out regarding the impact on IoT devices, specifically microcontroller (MCU) class devices. Some of them may have been motivated by the discourse around the compromise, such as Russ Cox’s Bluesky post, which included the following sentence.

IOT boxes that can’t or don’t update are now trivially MITM’able forever.

Scott Helme’s post, which is at the top of Hacker News as of writing, also included a strong warning.

IoT, embedded and OT devices. Cameras, routers, cars, medical devices, smart appliances, payment terminals and industrial controllers phoning home for commands and updates. Their bundles are frozen until 2039, which is the “cannot be contained” point made real.

IoT is a tricky moniker these days. If you consider a single board computer, like a Raspberry Pi (or really anything running Linux), to be an IoT device, then there is a good chance that the aforementioned assertions are correct. You hopefully have an OTA update solution for these devices, and you should update them as soon as possible. On the other hand, if you have a fleet of MCUs, you probably are not (directly) impacted by the compromise. In order to understand why, it is necessary to have at least a cursory understanding of public key infrastructure (PKI), and specifically web PKI.

On the device you are reading this post on, there is a bundle of root certificate authority (CA) certificates. In fact, there are almost certainly multiple CA certificate bundles because your platform (i.e. operating system) ships a bundle, and your browser might as well. Mozilla has maintained a dedicated CA Certificate Program since the initial launch of Firefox, and Chrome followed suit when it announced its root program in 2022. These root certificates are “trust anchors” that allow internet services that you communicate with to prove that they are who they say they are. Every website that you navigate to over HTTPS in your browser is verifying its identity by presenting one or more certificates that can be traced back to one of the CA certificates in the client’s bundle. For example, when you visited this blog post, the server that hosts it presented your browser with the following certificate chain.

Certificate chain
 0 s:CN=danielmangum.com
   i:C=US, O=Let's Encrypt, CN=YR1
   a:PKEY: RSA, 2048 (bit); sigalg: sha256WithRSAEncryption
   v:NotBefore: Aug 24 08:02:52 2026 GMT; NotAfter: Nov 22 08:02:51 2026 GMT
 1 s:C=US, O=Let's Encrypt, CN=YR1
   i:C=US, O=ISRG, CN=Root YR
   a:PKEY: RSA, 2048 (bit); sigalg: sha256WithRSAEncryption
   v:NotBefore: Sep  3 00:00:00 2025 GMT; NotAfter: Sep  2 23:59:59 2028 GMT
 2 s:C=US, O=ISRG, CN=Root YR
   i:C=US, O=Internet Security Research Group, CN=ISRG Root X1
   a:PKEY: RSA, 4096 (bit); sigalg: sha256WithRSAEncryption
   v:NotBefore: May 13 00:00:00 2026 GMT; NotAfter: Sep  2 23:59:59 2032 GMT

You can use openssl s_client -showcerts -verify 5 -connect danielmangum.com:443 to see it for yourself.

The first certificate (danielmangum.com) specifies that it is signed by the second (YR1), and the second by the third (Root YR). The third specifies its issuer as ISRG Root X1, which is the very popular Let’s Encrypt root CA certificate that is present in every major trust store. Because ISRG Root X1 is present in your trust store and the server sent you the necessary set of certificates to establish a chain of trust to that trusted root, you can be confident that you are in fact talking to danielmangum.com. Let’s Encrypt has a helpful diagram describing this chain of trust.

While establishing a secure connection to this site specifically may not be critical, this system is what allows us to perform sensitive operations, such as sending private messages, managing our bank accounts, and paying for items with a credit card without fear of an attacker stealing the data. In the eMudhra compromise, eight intermediate CA certificates, similar to Root YR and YR1 above, had their private keys accessible on the public internet. The private keys also happened to be extremely weak, with the top 376 bits of the P-384 keys being all zeroes. One of the private keys was literally the number 4 (00000100). This means that someone with even moderate technical capabilities could easily issue themselves a leaf certificate (like danielmangum.com), then present the leaf and the intermediate, and it would be trusted by every trust store that included eMudhra’s root CA certificate. Unfortunately, that included all the same major root programs.

Some clients, namely browsers, also require that a leaf certificate be included in a certificate transparency (CT) log in order to be trusted. This has allowed for the major browsers to assert with relative confidence that users of their software were not impacted, whereas other software very well may have been.

The private keys for the intermediate certificates were incorrectly generated by the CA. This means that anyone can recover them from the certificates.

This would have been possible since the certificates were created in April 2025. There are no entries in the certificate transparency logs for these intermediates in that period, indicating that CT-enforcing clients like Firefox, Chrome, Edge and Safari could not have been attacked.

However, many clients outside of the browser ecosystem do not enforce Certificate Transparency. We do not know if attackers exploited the flawed key generation to target these clients.

The disclosure of this compromise led to a mad dash across programming languages, developer tools, OS packages, and essentially any software involved with establishing a TLS connection, to either filter for these compromised intermediates, or reject the eMudhra root CA certificate entirely. To say the issue is widespread would be an understatement.

So why are MCUs unlikely to be impacted? In short, because of resource constraints. While including a bundle, or multiple bundles, of X.509 certificates on a server, desktop machine, or even a single board computer has trivial impact (what’s a few kilobytes among friends?), we have to be much more judicious when targeting devices that often have less than, sometimes much less than, 1 MB of non-volatile storage. Furthermore, rather than relying on an OS or browser vendor to go through the painstaking process of evaluating and monitoring candidate root CA certificates, we are typically responsible for the entire system, either building bare metal applications or leveraging lightweight Real Time Operating Systems (RTOS).

For example, the HTTP GET sample in the Zephyr RTOS connects to google.com. Its trust chain looks as follows.

Certificate chain
 0 s:CN=*.google.com
   i:C=US, O=Google Trust Services, CN=WE2
   a:PKEY: EC, (prime256v1); sigalg: ecdsa-with-SHA256
   v:NotBefore: Sep 28 18:38:33 2026 GMT; NotAfter: Dec 21 18:38:32 2026 GMT
 1 s:C=US, O=Google Trust Services, CN=WE2
   i:C=US, O=Google Trust Services LLC, CN=GTS Root R4
   a:PKEY: EC, (prime256v1); sigalg: ecdsa-with-SHA384
   v:NotBefore: Dec 13 09:00:00 2023 GMT; NotAfter: Feb 20 14:00:00 2029 GMT
 2 s:C=US, O=Google Trust Services LLC, CN=GTS Root R4
   i:C=BE, O=GlobalSign nv-sa, OU=Root CA, CN=GlobalSign Root CA
   a:PKEY: EC, (secp384r1); sigalg: sha256WithRSAEncryption
   v:NotBefore: Nov 15 03:43:21 2023 GMT; NotAfter: Jan 28 00:00:42 2028 GMT

Rather than having a generic set of root CA certificates that covers the majority of the internet, the sample only includes the single root CA certificate (GlobalSign R1) that is needed to verify google.com. It is nearly 1 KB (DER encoded) on its own, but the size of the certificate is not the only consideration. Enabling all signing algorithms, curves, and hashing algorithms used throughout the certificate chain can have a significant impact on code size as well. Additionally, buffer sizes must be configured to accommodate the full chain; the longer the chain, the more memory that needs to be allocated.

These constraints can lead to frustrating errors and complex debugging sessions. However, there is something to be said for building a system that is only focused on accomplishing a fixed, well defined set of tasks. When situations like the eMudhra compromise arise, I find myself appreciating the inherent limitations of these devices and the intention that goes into building the firmware that runs on them. Perhaps this event is an opportunity for us to evaluate whether some of that intention can be applied in other domains.

Unless your MCU needs to connect to a server that uses a chain of trust rooted in an eMudhra root CA certificate, and you included it (or the Sectigo root CA certfificate used for cross-signing) in your firmware, your devices are likely safe from this specific vulnerability. Now all you have to do is make sure that you patch all of your CI environments, developer tooling, cloud services, and productivity software.