If you are a application engineer, or mostly activity in the tech industry, there is a fine chance that you heard concerning 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 assorted products that you use.
I won’t go through the complete backdrop of the circumstance as there are plentifulness of other posts, including the now community bug report from Mozilla, that describe the particulars of the compromise. However, I have had a figure of folks reach out concerning the effect on IoT devices, specifically microcontroller (MCU) category devices. Some of them may have been motivated by the discourse around the compromise, specified 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, additionally included a strong warning.
IoT, embedded and OT devices. Cameras, routers, cars, medicinal devices, smart appliances, fee terminals and manufacturing controllers phoning home for commands and updates. Their bundles are icy until 2039, which is the “cannot be contained” item made real.
IoT is a tricky moniker these days. If you regard a sole commission computer, like a Raspberry Pi (or really item operating Linux), to be an IoT device, then there is a fine chance that the aforementioned assertions are correct. You hopefully have an OTA update resolution for these devices, and you should update them as shortly as possible. On the another hand, if you have a fleet of MCUs, you probably are not (directly) affected by the compromise. In command to understand why, it is necessary to have at smallest a cursory understanding of community key infrastructure (PKI), and specifically web PKI.
On the equipment you are study this article on, there is a bundle of root certificate authority (CA) certificates. In fact, there are nearly certainly multiple CA certificate bundles since your phase (i.e. functioning system) ships a bundle, and your browser power as well. Mozilla has maintained a dedicated CA Certificate Program since the initial initiate of Firefox, and Chrome followed lawsuit whenever it announced its base program in 2022. These base certificates are “trust anchors” that authorize net services that you communicate alongside to demonstrate that they are who they say they are. Every website that you navigate to complete HTTPS in your browser is verifying its character by presenting one or additional certificates that can be traced rear to among the CA certificates in the client’s bundle. For example, whenever you visited this blog post, the server that hosts it presented your browser alongside 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 archetypal 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 famous Let’s Encrypt base CA certificate that is current in every major trust store. Because ISRG Root X1 is current in your rely shop and the server sent you the necessary set of certificates to established a sequence of rely to that trusted root, you can be assured that you are in fact talking to danielmangum.com. Let’s Encrypt has a helpful diagram describing this sequence of trust.
While establishing a safe association to this location specifically may not be critical, this scheme is what allows us to execute delicate operations, specified as sending personal messages, managing our financial institution accounts, and paying for items with a credit cardstock without fear of an attacker stealing the data. In the eMudhra compromise, eight intermediate CA certificates, akin to Root YR and YR1 above, had their personal keys accessible on the community internet. The private keys additionally happened to be extremely weak, alongside the top 376 bits of the P-384 keys being all zeroes. One of the personal keys was exactly the figure 4 (00000100). This method that person alongside equal average specialized capabilities could effortlessly matter themselves a leaf certificate (like danielmangum.com), then present the leaf and the intermediate, and it would be trusted by all trust store that included eMudhra’s base CA certificate. Unfortunately, that included all the identical important base programs.
Some clients, namely browsers, additionally necessitate that a leaf certificate be included in a certificate transparency (CT) log in command to be trusted. This has allowed for the important browsers to assert with relative confidence that users of their application were not impacted, whereas another application extremely fine may have been.
The personal keys for the intermediate certificates were incorrectly generated by the CA. This method that anyone can regain them from the certificates.
This would have been imaginable 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 exterior of the browser ecosystem do not enforce Certificate Transparency. We do not cognize if attackers exploited the flawed key generation to mark these clients.
The disclosure of this colony led to a mad dash throughout programming languages, developer tools, OS packages, and basically any application engaged alongside establishing a TLS connection, to either filter for these compromised intermediates, or refuse the eMudhra base CA certificate entirely. To say the matter is general would be an understatement.
So why are MCUs improbable to be impacted? In short, since of resource constraints. While including a bundle, or multiple bundles, of X.509 certificates on a server, desktop machine, or equal a sole commission device has trivial effect (what’s a few kilobytes among friends?), we have to be much additional judicious whenever targeting devices that frequently have small than, sometimes much small than, 1 MB of non-volatile storage. Furthermore, fairly than relying on an OS or browser vendor to go through the painstaking procedure of evaluating and monitoring candidate base CA certificates, we are typically liable for the entire system, either construction naked metal element applications or leveraging lightweight Real Time Operating Systems (RTOS).
For example, the HTTP GET sample in the Zephyr RTOS connects to google.com. Its rely sequence 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 base CA certificates that covers the majority of the internet, the example lone includes the single base 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 sequence can have a important effect on code size as well. Additionally, buffer sizes must be configured to modify the full chain; the longer the chain, the additional recollection that needs to be allocated.
These constraints can guide to frustrating errors and complex debugging sessions. However, there is item to be stated for construction a scheme that is only focused on accomplishing a fixed, fine defined set of tasks. When situations like the eMudhra colony arise, I discover myself appreciating the inherent limitations of these devices and the aim that goes into construction the firmware that runs on them. Perhaps this event is an chance for us to evaluate whether several of that aim can be applied in another domains.
Unless your MCU needs to nexus to a server that uses a sequence of rely rooted in an eMudhra base CA certificate, and you included it (or the Sectigo base CA certfificate used for cross-signing) in your firmware, your devices are apt harmless from this particular vulnerability. Now all you have to do is create certain that you place all of your CI environments, developer tooling, haze services, and efficiency software.
