Planning a Post-Quantum Migration for Constrained Devices

Post-quantum cryptography stopped being a research topic when NIST finalised FIPS 203, 204 and 205. For most software the migration is a library upgrade on a schedule. For embedded devices it is something else, because the constraint that matters is not the algorithm — it is that the hardware was specified years ago and will still be installed years from now.

The overhead is the first thing to measure rather than assume. Post-quantum key encapsulation and signatures are larger than their elliptic-curve equivalents, sometimes by more than an order of magnitude in key or signature size. On a device with kilobytes of RAM that lands in three places at once: the stack during the handshake, the flash holding embedded public keys, and the airtime spent transmitting a larger handshake on a radio with a duty cycle limit. Any one of those can be the binding constraint, and which one it is differs per product.

The part that cannot be deferred is the signature on your firmware update path. Everything else in a device's cryptography protects data in flight, and an attacker who breaks it later gets the traffic. The update signature is different: an attacker who can forge it owns the fleet. It is also the hardest thing to change afterwards, because the bootloader that verifies signatures is frequently the one component that cannot be updated in the field. A device shipping today with only a classical signature on its bootloader has made a decision for the rest of its life.

Harvest-now-decrypt-later reframes the timeline for anything with long-lived confidentiality. Traffic captured today can be stored and decrypted once the capability exists, so the question is not when quantum computers arrive but how long your data must stay secret. Telemetry that is worthless in a week does not need urgency. Medical readings, utility consumption patterns and location histories do.

Hybrid modes are the practical route through the transition, and they exist precisely because nobody wants to bet a decade on a young algorithm. A hybrid key exchange runs a classical and a post-quantum algorithm together and derives a key from both, so the result is secure unless both are broken. The cost is more bytes on the wire, which returns to the airtime constraint. It is the right default for anything being designed now.

Where to start is unglamorous: build the inventory. Most organisations cannot answer which algorithms are in which products, which are hardcoded in a vendor SDK, and which are in silicon and therefore unchangeable. That inventory takes weeks and is the input to every other decision, including the ones you make with your silicon vendor about parts that do not exist yet. Ask for their post-quantum roadmap in writing before selecting a component, because a part with no answer commits your product to whatever the answer turns out to be.