Post-quantum cryptography on embedded devices: what FIPS 203, 204 and 205 change

In August 2024 NIST published its first three post-quantum cryptography standards. For cloud services, adopting them is mostly a matter of updating libraries and protocols. For embedded devices, it’s a design problem.

This note is an overview for product and engineering leads, not a cryptography lesson. I’m not a cryptographer; at Shorium we have people who are. My job is to help make these choices understandable for the teams that have to live with them.

The three standards in one paragraph each

FIPS 203, ML-KEM (derived from CRYSTALS-Kyber). A key-encapsulation mechanism: it replaces the role of RSA or elliptic-curve Diffie-Hellman in establishing a shared secret. It’s fast, but public keys and ciphertexts are measured in kilobytes rather than tens of bytes.

FIPS 204, ML-DSA (derived from CRYSTALS-Dilithium). A general-purpose digital signature scheme, the most likely replacement for ECDSA and RSA signatures in most uses. Signatures are a few kilobytes.

FIPS 205, SLH-DSA (derived from SPHINCS+). A stateless hash-based signature scheme. Its security rests on well-understood hash functions, which makes it a conservative choice, at the cost of large signatures and slower signing.

There is also a fourth family worth knowing for firmware: the stateful hash-based signatures LMS and XMSS, specified in NIST SP 800-208. The US NSA’s CNSA 2.0 suite names them for software and firmware signing.

What changes on a constrained device

The algorithms work. The question is whether your device, your protocols and your supply chain can carry them.

Size. Keys and signatures are much larger than the ECC values most embedded systems were designed around. That affects flash and RAM budgets, certificate chains, and any protocol with tight message limits.

Bandwidth and radio time. On low-power networks, sending a few extra kilobytes during every handshake is not free. It costs energy, latency and sometimes airtime regulations.

Performance and memory peaks. Some operations are fast on paper but need working memory that small microcontrollers don’t have to spare.

Hardware acceleration. Many devices rely on crypto accelerators or secure elements built for RSA and ECC. If the new algorithms run in software, timing and side-channel protection need fresh attention.

State. LMS and XMSS are efficient and conservative, but each private key can sign only a limited number of messages, and the signer must never reuse a state. That’s manageable in a well-run signing infrastructure. It’s a serious risk anywhere state could be copied or rolled back.

Hybrid is a transition tool, not a destination

During the transition, many protocols combine a classical algorithm with a post-quantum one, so that the connection stays secure as long as either holds. Hybrid key exchange is already common in TLS.

For devices, hybrid modes buy time and reduce risk. They also add size and complexity. Treat them as a bridge you plan to cross, with a date on the other side.

Questions to ask before choosing

Before anyone picks an algorithm, I’d want clear answers to these:

• What does the device actually do with public-key cryptography? Secure boot, firmware updates, device identity, session keys? Each has a different best fit.
• How long will the device be supported, and can its root of trust be updated during that time?
• What are the real memory, flash, power and bandwidth margins on the current hardware revision, and on the next one?
• Which parts of the chain do we control, and which belong to suppliers: chip vendor, module maker, cloud platform, certificate authority?
• If we choose wrong, how would we change it?

The last question is the most important. The standards are new, implementations will improve, and guidance will evolve. The device that survives this decade is not the one that picked the perfect algorithm in 2026. It’s the one that was designed to change.

Where to start

Start with an inventory of where public-key cryptography is used in your products, and a frank assessment of the hardware margins of the devices you will still be shipping in 2030. Everything else, algorithm choice included, depends on those two answers.