Post-Quantum Cryptography for IoT: ML-KEM, ML-DSA and SLH-DSA

Public-key cryptography protects most device identities, key exchanges and firmware signatures today. It rests on problems (RSA and elliptic curves) that a large, fault-tolerant quantum computer could solve with Shor's algorithm. No such machine exists yet. The reason to act now is the lifetime of IoT hardware: a device shipped today may still be in service in 2040, and traffic recorded today can be stored and decrypted later.

On 13 August 2024, NIST published the first three post-quantum standards: FIPS 203, FIPS 204 and FIPS 205.

The three algorithms

• ML-KEM (FIPS 203, derived from CRYSTALS-Kyber) is a key encapsulation mechanism. It replaces RSA and ECDH key exchange, and its security rests on module lattice problems.

• ML-DSA (FIPS 204, derived from CRYSTALS-Dilithium) is a general-purpose signature scheme, also lattice-based.

• SLH-DSA (FIPS 205, derived from SPHINCS+) is a stateless hash-based signature scheme. Its security depends only on hash functions, which makes it the conservative choice, at the cost of large signatures and slow signing.

Symmetric cryptography is affected far less. Grover's algorithm gives only a quadratic speed-up, so AES-256 and SHA-256 or larger remain appropriate.

What the sizes look like

Scheme	Public key	Ciphertext or signature
ML-KEM-768	1,184 B	1,088 B ciphertext
ML-DSA-65	1,952 B	3,309 B signature
SLH-DSA-128s	32 B	7,856 B signature
SLH-DSA-128f	32 B	17,088 B signature
ECDSA P-256 (for comparison)	64 B	about 64 B signature

| Scheme | Public key | Ciphertext or signature | |---|---|---| | ML-KEM-768 | 1,184 B | 1,088 B ciphertext | | ML-DSA-65 | 1,952 B | 3,309 B signature | | SLH-DSA-128s | 32 B | 7,856 B signature | | SLH-DSA-128f | 32 B | 17,088 B signature | | ECDSA P-256 (for comparison) | 64 B | about 64 B signature |

The sizes come from the FIPS documents and vary by parameter set. The pattern is clear: keys and signatures are tens to hundreds of times bigger than the elliptic-curve values they replace.

What that means on constrained devices

• Radio links. A LoRaWAN application payload is roughly 51 to 222 bytes in EU868, depending on data rate. A 1,088-byte ML-KEM-768 ciphertext would take 5 to 22 uplinks, which is not practical. Keep the LoRaWAN session on symmetric keys and do any post-quantum exchange over a different channel, for example at provisioning.

• Flash and RAM. Keys, signatures and the code itself take space, so check the footprint on your MCU. The open pqm4 project benchmarks these algorithms on Cortex-M4 and is a useful starting point.

• Time and energy. ML-KEM and ML-DSA are fast enough for many MCUs. SLH-DSA signing is slow, but verification is cheaper, and devices usually only verify.

Where to adopt it first

1. Firmware signing and secure boot. Devices only verify, signing happens on a secure server, and the lifetime is long. Hash-based schemes fit well here: SLH-DSA, or the stateful LMS and XMSS schemes standardized in NIST SP 800-208, which carry a key-state management burden. Decide early, because a first-stage verifier in ROM cannot be changed later.

2. Key exchange and provisioning over IP links. Use a hybrid such as X25519 combined with ML-KEM-768, the approach already used in TLS deployments, so security holds if either part fails.

3. Device identity and certificates. Larger certificates affect handshake size and storage. Plan the PKI side against your cloud provider's roadmap.

Design principles for PQC-ready devices

• Crypto agility. Put algorithm identifiers in manifests and protocols, and keep a secure update path for the code that does the verifying.

• Hybrid first. Combine classical and post-quantum schemes during the transition.

• Budget the bytes. Account for key, signature and certificate sizes in flash, RAM and link capacity.

• Check hardware support. Secure elements, HSMs and vendor crypto libraries are adding post-quantum support; confirm what your parts offer.

• Inventory your cryptography. List every place a device or backend uses RSA, ECDH or ECDSA, ranked by how long the protected data must stay secret.

• Follow the standards. NIST and the IETF are still publishing guidance on protocol integration.

Conclusion

Post-quantum migration for IoT is mostly an exercise in bytes and lifetimes. Start with long-lived devices and firmware signing, keep symmetric keys on constrained links, and design for algorithm change. The standards are final. The engineering work is fitting them into small devices.

Planning a long-lived connected product? Write to connect@eurthtech.com or see www.eurthtech.com/solutions.