How do you make IoT devices quantum safe?

Making IoT devices quantum safe means planning for devices that will still be deployed when large quantum computers exist: know which cryptography each device uses, make sure it can be updated, and move key exchange and signatures to NIST's post-quantum standards where the hardware allows. Start with an inventory, because you cannot migrate what you have not listed.

Why is IoT a special case?

CISA's post-quantum page says that once quantum computers are sufficiently powerful they will be able to break many widely used encryption and digital signature algorithms, and that technology capable of breaking modern public-key encryption does not yet exist. The agency still tells operators to begin preparing now.

IoT sharpens that advice for three reasons that follow from how these devices are built. They stay in the field for years. Many cannot be updated easily or at all. And their crypto is often fixed in firmware or in a chip. A web server can swap a library in an afternoon. A sensor sealed in a pump housing cannot.

What has NIST standardized that applies?

For key establishment, FIPS 203 specifies ML-KEM, a key encapsulation mechanism whose security rests on the Module Learning with Errors problem. NIST states that ML-KEM is currently believed to be secure even against adversaries with quantum computers. It defines three parameter sets, ML-KEM-512, ML-KEM-768 and ML-KEM-1024, in order of increasing security strength and decreasing performance. FIPS 204 and FIPS 205 cover digital signatures.

NIST's transition report, IR 8547, describes the expected approach to moving from quantum vulnerable algorithms to post-quantum signatures and key establishment, and identifies the standards that products and services will need to move away from.

What about tiny, battery powered devices?

Public key algorithms are only half of a device's cryptography. The data it sends is protected by symmetric cryptography. NIST's SP 800-232 standardizes the Ascon family: authenticated encryption, a hash function and extendable output functions, designed for resource constrained environments such as IoT devices, embedded systems and low power sensors. Note what this is and is not. Ascon is aimed at efficiency on small hardware. It does not replace the key exchange question. Be careful not to treat the two as the same migration.

A constructed example

A water utility has 4,000 field sensors that report over a cellular link. Each sensor ships with a factory certificate signed with an elliptic curve algorithm and the device checks signed firmware with the same family. The utility's inventory shows three hardware generations. Generation one cannot take a firmware update at all. Generation two can, but has 64 KB of free flash. Generation three has a secure element that supports new algorithms by vendor update. The plan splits cleanly: replace generation one on the normal asset cycle, ask the vendor for a post-quantum signature roadmap for generation two, and test ML-KEM based key exchange in the gateway that sits in front of all three.

How to check or apply this

1. Inventory every device model, with firmware version, expected end of life, and who can update it.
2. Record which algorithms each device uses for key exchange, signatures, firmware verification and data protection.
3. Mark the devices that cannot be updated over the air. Those need a replacement date.
4. Put post-quantum support in procurement requirements, and ask vendors for dated roadmaps in writing.
5. Prefer designs where a gateway terminates the device protocol, so you can upgrade the gateway first.
6. Test the cost of larger keys and signatures on real hardware, for memory, bandwidth and battery.
7. Plan crypto agility: signed firmware that can change algorithms without a hardware swap.
8. Track NIST and CISA guidance, as it is still moving.

Safeguard's SBOM and dependency scanning can help with the software half of this inventory, by listing the cryptographic libraries inside the firmware and services you build.

Quick check

Sources

• CISA: Post-Quantum Cryptography Initiative
• NIST FIPS 203: Module-Lattice-Based Key-Encapsulation Mechanism Standard
• NIST SP 800-232: Ascon-Based Lightweight Cryptography Standards
• NIST IR 8547 (initial public draft): Transition to Post-Quantum Cryptography Standards

Last reviewed: 18 October 2026.