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?
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.
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
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?