TLS (Transport Layer Security) is a cryptographic protocol that provides encrypted communication over a network connection, typically with endpoint authentication. It is the standardized evolution of SSL 3.0 and is widely used to secure TCP-based channels such as HTTPS and MQTT over TLS in embedded and IoT systems. (CoAP commonly uses DTLS, the UDP-based adaptation of TLS, rather than TLS directly.)
In practice
In embedded systems, TLS appears most commonly when a device must communicate securely with a cloud backend, an MQTT broker, or a REST API. Libraries such as Mbed TLS (formerly PolarSSL), wolfSSL, and BearSSL are designed with constrained targets in mind and can run on Cortex-M class devices, though RAM and flash requirements vary significantly by configuration. A minimal Mbed TLS build for TLS 1.2 with a single cipher suite can fit in roughly 50-100 KB of flash, but a full-featured build can exceed 300 KB, making library configuration a critical step on resource-constrained hardware.
The TLS handshake is computationally expensive relative to the steady-state data transfer. On MCUs without hardware crypto acceleration, an RSA-2048 or ECDHE key exchange can take several seconds on slower or more constrained targets, though actual duration is highly dependent on clock speed, implementation, and configuration. Choosing elliptic-curve cipher suites (ECDHE-ECDSA, or ECDHE-RSA which retains RSA for authentication) over pure RSA key exchange typically reduces handshake time and code size on many stacks, since ECC offers comparable security at much shorter key lengths, though gains vary by configuration. The blog post "Elliptic Curve Cryptography - Security Considerations" covers relevant tradeoffs in more depth.
Certificate management is a common operational pitfall. Embedded devices must validate the server certificate against a trusted root CA, which means storing one or more CA certificates in flash. Skipping certificate verification to save flash or simplify development is a serious security mistake that leaves the device open to man-in-the-middle attacks. Devices also need a reliable time source to check certificate validity windows; without accurate time, certificate expiry checks are unreliable or must be disabled.
Session resumption (via session IDs or session tickets) can dramatically reduce the cost of reconnection by avoiding a full handshake. On intermittently connected devices that drop and re-establish connections frequently, enabling session resumption is often more impactful than optimizing cipher selection. TLS 1.3, which has a simplified handshake and removes many legacy cipher suites, is now supported in several embedded TLS libraries but may not be available on all older or smaller targets.
Frequently asked
Which TLS library should I use on a constrained MCU?
The most common choices are Mbed TLS (Apache 2.0, used in Cortex-M ecosystems and integrated into a number of vendor SDKs), wolfSSL (dual-licensed, focuses on small footprint and hardware acceleration support), and BearSSL (small, constant-time implementation, no dynamic allocation). The best choice depends on your platform SDK, available hardware crypto, licensing constraints, and how much
RAM and
flash you can allocate. Avoid OpenSSL on bare-metal or small RTOS targets; it is not designed for constrained environments.
Does TLS require an RTOS?
No. TLS libraries like Mbed TLS and wolfSSL can run on bare-metal targets as long as you provide a suitable network socket abstraction, a source of entropy, and optionally a time source. The library itself does not mandate an RTOS, though many real-world deployments use one for networking
stack integration.
What is the difference between TLS and DTLS?
TLS runs over a reliable, ordered transport like TCP. DTLS (Datagram TLS) is an adaptation of TLS for unreliable, unordered transports like
UDP. DTLS is used in protocols such as
CoAP and in some LwM2M implementations where UDP is preferred for its lower overhead on constrained networks. The core cryptographic mechanisms are the same, but DTLS adds its own retransmission and ordering logic to handle packet loss.
How do I handle certificate verification on a device without accurate real-time clock?
Certificate validity is time-bounded, so without a reliable clock you cannot fully verify the notBefore/notAfter fields. Common approaches include: syncing time via SNTP before the TLS handshake, using a hardware
RTC backed by a coin cell, or configuring the TLS library to skip time validation as a deliberate and documented tradeoff (with awareness of the reduced security). Some deployments use certificate pinning instead of or in addition to CA-based validation, which avoids reliance on expiry checking but complicates certificate rotation.
What is mutual TLS (mTLS) and when is it used in embedded systems?
In standard TLS, only the server presents a certificate; the client authenticates the server. In mutual TLS, the client also presents a certificate that the server verifies. This is common in IoT device provisioning and cloud connectivity (AWS IoT Core and Azure IoT Hub, for example, support or require mTLS). It provides strong device identity without usernames or passwords, but requires each device to be provisioned with a unique client certificate and private key, which adds manufacturing and key management complexity.
Differentiators vs similar concepts
TLS is often conflated with SSL. SSL (versions 2.0 and 3.0) is the predecessor protocol developed by Netscape; all SSL versions are deprecated and considered cryptographically broken. TLS 1.0 and 1.1 are also deprecated. Current best practice is TLS 1.2 or TLS 1.3. The term "SSL" persists informally (as in "SSL certificate"), but any modern implementation should be using TLS. TLS should also be distinguished from lower-level primitives like AES or SHA-256: those are individual cryptographic algorithms, while TLS is a full protocol that negotiates algorithms, authenticates endpoints via certificates, and establishes session keys.
