Post-Quantum Cryptography on Embedded and IoT Devices

The post-quantum migration is an inconvenience for servers and a genuine architectural problem for embedded devices. Servers get patched. A water meter installed in 2026 with a twenty-year service life will still be running its original firmware in 2046, long after the algorithms it depends on have been formally disallowed.

Why the constraints bite so hard

Signature size against radio budgets. Low-power wide-area protocols work with payloads measured in tens of bytes. An ML-DSA signature is measured in thousands. On duty-cycle-limited radio, a signature that must be split across many transmissions may not fit within regulatory airtime limits at all. This is not a performance concern; it is a feasibility one.

Memory. Microcontrollers with tens of kilobytes of RAM cannot hold the working state some post-quantum operations require, let alone two implementations during a transition.

Energy. A battery-powered sensor budgeted for a decade has a fixed energy allowance per operation. Larger keys mean more computation and considerably more radio time, and radio dominates the power budget. A scheme that verifies quickly but triples transmission length can halve device lifetime.

Update capability. Many deployed devices cannot be updated remotely at all. For those, whatever ships is final. Crypto-agility is not an option you can retrofit; it either exists at manufacture or the device is a fixed liability.

Which primitives fit

The picture is more encouraging for key establishment than for signatures. ML-KEM’s key and ciphertext sizes, while larger than elliptic curve equivalents, remain in the low kilobytes and are workable on many platforms.

Signatures are where it hurts. ML-DSA at several kilobytes is difficult on constrained radio. SLH-DSA, at up to tens of kilobytes, is out of the question for routine use — though it remains attractive for infrequent, high-value operations such as firmware verification, where the signature is checked once at boot rather than transmitted repeatedly.

That asymmetry suggests a split architecture: post-quantum key establishment for the session, symmetric authentication within it, and heavyweight post-quantum signatures reserved for firmware and provisioning.

Symmetric cryptography is your friend

The most useful observation for embedded work is that symmetric cryptography is largely fine. Grover’s algorithm gives a quadratic speedup, which is addressed by doubling key length — AES-256 remains sound.

So designs that lean on pre-shared symmetric keys, with public-key operations used only for provisioning and rekeying, face a far smaller migration than designs that use public-key cryptography for every message. For a closed system where you control both endpoints, this is a legitimate architecture rather than a compromise.

What to require when buying

Most organisations deploying embedded devices are purchasing rather than designing them, which makes procurement the real control point. Four questions to put in writing:

• Can firmware be updated in the field, authenticated, and is the update mechanism itself quantum-resistant?
• Is the cryptographic implementation replaceable, or is it fixed in hardware?
• Is there sufficient headroom in memory and energy budget for larger keys?
• What is the vendor’s stated migration plan, and does it extend to the devices you are buying now?

A vendor without answers is telling you their product has a defined end of life, whether or not they have said so.

The realistic position

Some deployed device populations will not be migrated. They will be replaced when they fail, or they will operate with cryptography that no longer provides its stated guarantee.

That is an uncomfortable thing to plan around and better than pretending otherwise. The useful work is knowing which populations they are, what those devices actually protect, and what compensating controls exist — network segmentation, monitoring, limiting what a compromised device can reach. For the fleet you are buying today, the leverage is entirely in the specification.