What makes TLS challenging on a constrained embedded device?

TLS is usually the heaviest workload an MCU runs, and it strains every resource. Flash: a crypto library like mbedTLS or wolfSSL adds tens of kilobytes of code. RAM: the handshake and TLS records need sizable buffers, a single TLS record can be up to ~16 KB, and handshake state adds more, frequently making TLS the largest RAM consumer on the device and sometimes not fitting the smallest parts at all. CPU and energy: the asymmetric handshake math (key exchange, signature verification) is computationally expensive and, on a battery device, a real energy event, which is why you prefer ECC (smaller keys and faster than RSA at equivalent security) and use hardware crypto accelerators where available. Correct time is a subtle but critical requirement: certificate validity is date-based, so a device with a wrong or unset clock will see valid certificates as expired or not-yet-valid and fail the handshake, a very common field failure that requires provisioning time via an RTC, NTP, or a build-time anchor before connecting. Key storage: the device's private key must be protected from extraction, so it belongs in a secure element, TrustZone, or protected flash rather than plaintext firmware. And lifecycle: certificates and roots expire, so a device deployed for years needs a plan to renew its cert and update its trust store as CAs rotate, or it silently stops connecting. Mitigations include session resumption (skip the full handshake on reconnect), lean cipher-suite selection, ECC, hardware acceleration, and careful buffer sizing. The cardinal sin, born of these constraints, is "fixing" TLS problems by disabling certificate validation, which removes authentication entirely and leaves the device open to machine-in-the-middle attacks.