tl;dr: MCUs are space-constrained and often don't include root certs that aren't used by the one host they talk to.
In my experience it's equally likely they just don't do validation to begin with. For example, my Elk M1XEP (physical security system's Ethernet expander) runs a configuration server with and without TLS. They recommend with, but it uses a self-signed certificate, and the crappy VB.NET configuration program doesn't validate the cert in any way, so it can be trivially MITMed. The Elk M1XEP also can connect to a user-chosen alarm monitoring service ("central station") over the Internet. I don't think it uses TLS at all for this. I think there's optional shared secret auth/encryption?
Over a decade ago, I created an AWS ELB to serve a production API. It was HTTPS-only, using an Amazon-signed certificate served from ACM for my employer's domain. Right after deployment, logs showed a regular pattern of 404s trying to POST/PUT to my API at paths I didn't support. Thousands of requests per hour, and they continued for days. It didn't look like a DoS--the paths looked like someone else's API.
I got curious what all the traffic was, so I added a route to the API that saved some of the uploaded data. It was live home surveillance video and photos! Indoors, outdoors, baby monitors, living rooms, etc. It was pretty easy to find which vendor's hardware was doing this (from headers, paths, watermarks) and I reached out to their security contact to let them know what I found. They responded generically but didn't seem to care that much.
In short, because HTTPS was required, and an ELB gets assigned IPv4 addresses arbitrarily, I can only conclude that a whole fleet of home security cameras were sold across the US that hard-coded the IP address of their cloud server and had certificate validation disabled.
This is unfortunately accurate, sometimes due to real constraints and more often due to loose threat models. I am hopeful that more open source firmware options (e.g. Zephyr RTOS) and more software investment from silicon vendors is helping to change the status quo. That being said, we are still a long way away from a "Let's Encrypt movement" for embedded devices.
Your device would also have to be pretty recent to ship any of these certs in a frozen cert store as they were only generated in April/May of 2025.
Related:
https://news.ycombinator.com/item?id=50166579 - “eMudhra intermediate CA compromise” - 947 points | 19 hours ago | 408 comments
https://news.ycombinator.com/item?id=50177916 - "Eight Bits of Trust; eMudhra's CA keys cracked in milliseconds" - 604 points | 7 hours ago | 270 comments
tl;dr: MCUs are space-constrained and often don't include root certs that aren't used by the one host they talk to.
In my experience it's equally likely they just don't do validation to begin with. For example, my Elk M1XEP (physical security system's Ethernet expander) runs a configuration server with and without TLS. They recommend with, but it uses a self-signed certificate, and the crappy VB.NET configuration program doesn't validate the cert in any way, so it can be trivially MITMed. The Elk M1XEP also can connect to a user-chosen alarm monitoring service ("central station") over the Internet. I don't think it uses TLS at all for this. I think there's optional shared secret auth/encryption?
Over a decade ago, I created an AWS ELB to serve a production API. It was HTTPS-only, using an Amazon-signed certificate served from ACM for my employer's domain. Right after deployment, logs showed a regular pattern of 404s trying to POST/PUT to my API at paths I didn't support. Thousands of requests per hour, and they continued for days. It didn't look like a DoS--the paths looked like someone else's API.
I got curious what all the traffic was, so I added a route to the API that saved some of the uploaded data. It was live home surveillance video and photos! Indoors, outdoors, baby monitors, living rooms, etc. It was pretty easy to find which vendor's hardware was doing this (from headers, paths, watermarks) and I reached out to their security contact to let them know what I found. They responded generically but didn't seem to care that much.
In short, because HTTPS was required, and an ELB gets assigned IPv4 addresses arbitrarily, I can only conclude that a whole fleet of home security cameras were sold across the US that hard-coded the IP address of their cloud server and had certificate validation disabled.
> physical security system
> can be trivially MITMed
Crazy how poor security can be even from a purported security vendor.
This is unfortunately accurate, sometimes due to real constraints and more often due to loose threat models. I am hopeful that more open source firmware options (e.g. Zephyr RTOS) and more software investment from silicon vendors is helping to change the status quo. That being said, we are still a long way away from a "Let's Encrypt movement" for embedded devices.