Mbed TLS is the small TLS library that runs in places other libraries cannot fit. Microcontrollers with 64 KB of flash. Sensor nodes with 8 KB of RAM. Industrial gateways. Medical devices. Connected cars. Anything that hits the hard ceiling of "not enough memory for OpenSSL" is a candidate for Mbed TLS, which used to be branded PolarSSL before ARM acquired the project in 2014. The library is now stewarded by Trusted Firmware under the Linux Foundation, with the public repository at github.com/Mbed-TLS/mbedtls.
Embedded TLS sets a hard constraint on every algorithm in scope. ROM, RAM, and stack budgets matter as much as cryptographic strength. Post-quantum cryptography is not naturally embedded-friendly. ML-KEM-768 keys and ciphertexts are around a kilobyte each, ML-DSA-65 signatures cross three kilobytes, and SLH-DSA signatures are tens of kilobytes. That collision between PQC sizes and embedded budgets is the tension that defines the Mbed TLS roadmap.
This article walks through what Mbed TLS currently supports for post-quantum cryptography, what the project is working toward, and which embedded use cases are realistic in 2026.
What Mbed TLS Targets
Mbed TLS has a different reader than OpenSSL. The library is engineered to be cross-compiled for ARM Cortex-M devices, RISC-V microcontrollers, and other constrained platforms. Common deployments include:
- Cortex-M0 and Cortex-M4 microcontrollers in IoT sensors
- ARM TrustZone secure-world software inside smartphones
- IoT operating systems like Zephyr, NuttX, FreeRTOS
- Industrial PLCs and HMIs
- Vehicle electronic control units running secure boot and OTA update firmware
The library is designed so that you can compile in only the cipher suites you need, the elliptic curves you need, the certificate parsing you need, and nothing else. A typical embedded build of Mbed TLS for an IoT sensor might come in around 50 KB of flash. That number sets the planning constraint for any post-quantum algorithm that wants to land here.
For background on classical algorithms in TLS, see openssl PQC status 2026.
Where Mbed TLS Stands on Post-Quantum
Mbed TLS post-quantum support is incremental and in motion. Here is the snapshot for 2026.
| Algorithm | Status in Mbed TLS |
|---|---|
| ML-KEM (FIPS 203) | Reference implementation work in progress |
| Hybrid TLS groups (X25519MLKEM768) | Engineering ongoing |
| ML-DSA | Roadmap item, not landed |
| SLH-DSA | Not in roadmap for default builds |
| FN-DSA / Falcon | Not present |
| HQC | Not present |
| Hardware-accelerated PQC | Future work, vendor-dependent |
The realism here is that embedded TLS adoption of post-quantum lags Chrome and Firefox by a year or more. The reasons are structural: smaller engineering teams, longer device lifetimes, and vendor procurement cycles that approve a single TLS library version for years before swapping it.
How Mbed TLS Approaches the Memory Problem
ML-KEM-768 alone needs about 2.4 KB of RAM for the key generation working buffer if naively implemented. That is an entire microcontroller's RAM budget on the smallest Cortex-M0 devices. Mbed TLS contributors have experimented with stack-friendly variants that reuse buffers and serialize state to flash, but the trade-offs are real.
For the largest constrained-device class (sensors with under 32 KB RAM), the consensus answer is "post-quantum is not feasible in a TLS handshake on those devices." The class above (Cortex-M4 with 256 KB flash and 64 KB RAM) is where ML-KEM becomes possible, with care.
Mbed TLS uses several techniques to cope:
- Stack budgeting via dedicated assembly routines for NTT and polynomial arithmetic
- Optional ROM-based constant tables that trade flash for RAM
- Configurable build flags so that integrators can include only one ML-KEM parameter set
- Profile-based mbedtls_config.h files that pre-populate sensible builds for common device classes
For comparison with desktop and server libraries, see BoringSSL PQ status.
Trusted Firmware and the PQC Pathway
The Trusted Firmware project owns several reference implementations for ARM secure boot and trusted execution. Mbed TLS is one piece. Trusted Firmware-A (TF-A) and Trusted Firmware-M (TF-M) are sister projects.
TF-M targets Cortex-M devices and ships a Platform Security Architecture (PSA) crypto API. PSA is a vendor-neutral crypto interface defined by ARM. As post-quantum cryptography lands in PSA, Mbed TLS will adopt the PSA interface to call into ML-KEM and ML-DSA. The PSA Cryptography 1.2 specification expanded the API to include identifiers for post-quantum primitives.
This matters for developers because it means embedded post-quantum support is being designed at the API layer first. When silicon vendors add PQC accelerators (NTT cores, Keccak engines), the PSA API exposes them to Mbed TLS without ABI breakage.
What Embedded Use Cases Look Like
A practical embedded PQC deployment in 2026 looks something like this: a vehicle telematics gateway negotiates TLS with a cloud backend using a hybrid X25519MLKEM768 key exchange. The gateway has an ARM Cortex-A53 application processor with 256 MB of RAM. It can afford ML-KEM in software. The gateway boots from a Cortex-M4 secure element that holds device identity keys. Those identity keys are still ECDSA, because ML-DSA signatures and certificates are too large for the secure element's flash budget.
That hybrid posture is normal for the next several years. Application-class devices get post-quantum TLS. Microcontroller-class devices keep classical algorithms for identity but inherit PQC at the gateway layer.
For more on enterprise migration patterns, see hybrid encryption.
Test Vectors and Interoperability
Mbed TLS validates its post-quantum implementations against:
- NIST CAVP test vectors for FIPS 203 and FIPS 204
- Reference implementations from PQClean
- Cross-test results with OpenSSL oqs-provider and BoringSSL
The Mbed TLS test framework runs these vectors as part of CI on platforms ranging from x86_64 Linux to ARM emulators. Vendor branches occasionally add hardware-accelerated implementations and feed those back upstream after correctness verification.
Stateful Hash-Based Signatures: A Special Case
LMS and HSS, defined in NIST SP 800-208, are stateful hash-based signatures. They are not part of the FIPS 204 or FIPS 205 standards but are approved for specific use cases like firmware signing. Mbed TLS landed LMS support earlier than ML-DSA because:
- Embedded firmware update workflows need post-quantum signatures urgently
- LMS is mathematically simple compared to ML-DSA
- LMS verification is fast and small enough to fit in a Cortex-M boot loader
- The state-management problem is on the signer side, where a server with reliable storage handles it
For a vendor signing an Over-The-Air firmware update, LMS today is the most practical post-quantum signature. Mbed TLS provides verification primitives. The signing infrastructure typically lives in HSMs at the vendor's release engineering build server.
For a comparison of signature algorithms, see ML-DSA vs SLH-DSA.
What Is Specifically Not Supported
To set realistic expectations:
- No SLH-DSA: Too large for typical Cortex-M devices to verify in reasonable time
- No FN-DSA: The floating-point arithmetic is dangerous on devices without proper FPU support and without precise rounding control
- No HQC, BIKE, FrodoKEM: Not in the active roadmap
- No hybrid certificates (carrying both classical and PQ signatures): Awaiting IETF stabilization
The Mbed TLS team has been explicit that supporting every NIST candidate is not the goal. Focused, well-tested coverage of ML-KEM and ML-DSA is the priority.
How to Plan Embedded Migrations
Engineering teams looking at embedded PQC migration should think in three layers:
- Application-class devices (Linux, Android Things, ARM Cortex-A): Treat them like servers. Use Mbed TLS or OpenSSL with PQC. ML-KEM in TLS is realistic now.
- High-end microcontrollers (Cortex-M4F, Cortex-M7, RISC-V mid-range): Plan for ML-KEM in TLS over the next 1-2 years. ML-DSA verification possible. ML-DSA signing on-device unlikely.
- Low-end microcontrollers (Cortex-M0, Cortex-M0+, very small RISC-V): Continue with classical algorithms for direct connections. Use a gateway pattern: PQC at the gateway, classical to the leaf.
This guidance changes as silicon vendors ship dedicated PQC accelerators. Several IP cores are commercially available now for NTT and Keccak operations. Devices using them can move down the size hierarchy while keeping PQC.
Vendor Hardware Accelerators
Several silicon vendors have started shipping or announcing PQC accelerator IP for their MCU products:
- ARM has discussed CMSIS-PQC primitives that vendor MCUs can implement
- STMicroelectronics has announced post-quantum accelerator IP in select STM32 product lines
- NXP has demonstrated PQC accelerators in some i.MX RT and S32 lines
- Renesas has discussed PQC plans for selected RA and RX MCU families
- RISC-V vendors are exploring extension instructions and coprocessors for NTT operations
Each of these will plug into Mbed TLS through the PSA Cryptography API driver model. Once PSA drivers are written, applications using Mbed TLS gain hardware-accelerated PQC operations transparently. The application-level code does not change.
For background on hardware-software cryptographic boundary, see hybrid encryption.
Memory Profiles for ML-KEM-768 in Mbed TLS
A rough memory profile for ML-KEM-768 implemented in software in Mbed TLS:
| Resource | Approximate cost |
|---|---|
| Code size (flash) | 15-30 KB depending on optimizations |
| Static data (ROM) | A few KB for constant tables |
| Stack at peak | 6-12 KB during NTT operations |
| Heap | Minimal, configurable |
These numbers fit comfortably on a Cortex-M4 with 256 KB flash. They are tight on a Cortex-M3 with 64 KB flash and almost no headroom for application code. They do not fit on a Cortex-M0 with 32 KB flash.
For ML-DSA-65, the memory profile is roughly twice the cost of ML-KEM-768 in code size, with similar stack peaks. SLH-DSA is several times larger again.
Roadmap Items in Mbed TLS
The Mbed TLS roadmap, as discussed in their GitHub issues and Trusted Firmware planning, includes:
- Stable ML-KEM API in PSA Crypto
- ML-DSA implementation
- Verification-only mode for ML-DSA on the smallest microcontrollers (verification is cheaper than signing)
- LMS optimizations for fast firmware verification
- Hardware accelerator driver scaffolding for PSA
These items are sequenced by available engineering capacity and by ecosystem priority. Firmware-signing use cases get priority because they have the strongest case for early adoption.
Frequently Asked Questions
Is Mbed TLS production-ready for post-quantum cryptography?
Production-ready depends on what you mean. For application-class devices, ML-KEM in Mbed TLS is being deployed and tested. For microcontroller-class devices, the answer is "soon for ML-KEM, much later for ML-DSA on-device signing." The library is ready when integrators are ready.
What replaces Mbed TLS for embedded if PQC sizes are too large?
There is no easy replacement. The size problem is a property of the algorithms, not the library. Some teams move to gateway architectures where the constrained device speaks classical TLS to a less-constrained gateway, and the gateway speaks PQC TLS to the cloud.
Does Mbed TLS work with hardware accelerators for PQC?
Through the PSA Crypto API, yes. Vendors that ship PQC silicon (NTT engines, Keccak cores) can plug into Mbed TLS via PSA driver interfaces. Several silicon vendors are at various stages of providing these drivers.
Are LMS and HSS available in Mbed TLS for firmware signing?
LMS verification primitives are available. Signing infrastructure is normally hosted on HSMs and not on the device, because state management for stateful signatures is critical to security.
Where can I read more about the Mbed TLS roadmap?
The Mbed TLS GitHub repository at github.com/Mbed-TLS/mbedtls publishes roadmap issues. The Trusted Firmware project at trustedfirmware.org coordinates the broader embedded security stack, including Mbed TLS and TF-M.
Can a vehicle-grade ECU use post-quantum TLS?
For modern vehicle-grade ECUs running ARM Cortex-A or Cortex-R class processors with multi-megabyte flash and substantial RAM, yes. ML-KEM in Mbed TLS or equivalent libraries is feasible. For ECUs running Cortex-M class processors with tighter constraints, gateway architectures (PQC at the central gateway, classical to the leaf ECUs) are the practical pattern.
Does Mbed TLS support post-quantum certificate parsing?
Mbed TLS's X.509 module is being updated as IETF stabilizes the post-quantum certificate formats. Initial parsing support for ML-DSA SubjectPublicKeyInfo entries is on the roadmap.
Sources
- Mbed TLS repository, github.com/Mbed-TLS/mbedtls
- Trusted Firmware project, trustedfirmware.org
- NIST FIPS 203 (Module-Lattice-Based Key-Encapsulation Mechanism), August 2024
- NIST SP 800-208 (Stateful Hash-Based Signature Schemes)
- PSA Cryptography API specification, ARM
- PQClean reference implementations, github.com/PQClean/PQClean
Related Articles
- What is post-quantum cryptography
- ML-KEM explained
- Hybrid encryption
- ML-DSA vs SLH-DSA
- OpenSSL PQC status 2026
Protect Your Data Before Q-Day Arrives
QNSQY's NIST-standardized post-quantum encryption protects files against both current and quantum-era threats.