up:: In the Protocols MOC

Constrained-Device PQC

Constrained-device PQC is the practice of running post-quantum algorithms on resource-limited hardware such as IoT sensors, smart cards, secure elements, and embedded controllers, where the larger keys, ciphertexts, and signatures of the new standards press against tight memory, flash storage, radio bandwidth, and sometimes compute, so the migration turns into a question of what actually fits rather than what runs fastest.

The surprising part is that on modern 32-bit microcontrollers the new lattice algorithms are often as quick as the elliptic-curve code they replace, and occasionally quicker, so the binding limit is usually the size of the artifacts and not the speed of the math. That reframes constrained-device PQC as a memory-and-bandwidth engineering problem, worst for the largest signatures (SLH-DSA) and easiest for the compact ones, layered on top of the crypto-agility problem that field hardware often can’t be updated once it ships.

The short version:

1. Constrained devices are limited on four axes at once, which are RAM, flash storage, radio bandwidth, and compute or energy budget, and post-quantum artifacts strain the first three far more than the fourth.
2. Post-quantum keys and signatures are much larger than elliptic-curve ones, so a single SLH-DSA signature can run from about 7.9 KB to nearly 50 KB where an ECDSA signature is roughly 64 bytes, which is the core of the strain.
3. Speed is rarely the blocker. On an ESP32, ML-KEM-512 completed a handshake 35% faster than classical ECDHE, and ML-DSA-44 verification was roughly 12 times faster than ECDSA, while the same ML-DSA build was the dominant memory cost.
4. Algorithm choice is a fit decision. ML-KEM and compact signatures like FN-DSA suit tight links, SLH-DSA’s tiny public key suits rarely-signing firmware roots, and its large signature is heavy for transport.
5. Fixed firmware makes agility the deeper problem. A sensor with a 10-to-20-year field life that ships today has to still be trustworthy past NIST’s 2035 disallowment, and a device with no update path can’t be migrated later.

Picture mailing a contract through a set of tiny pneumatic tubes where each capsule holds only a couple of index cards. A classical elliptic-curve signature is a single card that drops straight in. A post-quantum signature is a thick booklet, so you have to split it across dozens or hundreds of capsules, and the receiving desk needs a big enough tray to hold every card before it can read the whole thing.

The tube system still works, and it moves each capsule quickly. What decides whether the contract arrives is whether the desk has the tray space and whether the tubes can carry that many capsules, which is exactly the memory-and-bandwidth bind a constrained device hits with post-quantum artifacts.

What makes a device “constrained”?

A device is constrained when one or more of its hardware budgets is small enough to shape the cryptographic design, and the four that matter for PQC are memory, storage, bandwidth, and compute. The community’s standard benchmarking platform for embedded PQC, pqm4, pins this down concretely: it targets the ARM Cortex-M4 on a reference board with 2 MB of flash and 640 KB of RAM, and it reports exactly the three metrics that decide fit, which are cycle counts, stack usage, and code size.

1. RAM (working memory). The scratch space an algorithm needs while it runs, plus room to hold a full key, ciphertext, or signature in memory at once. This is the budget post-quantum code stresses most.
2. Flash (code and storage). The program image plus any stored keys and certificates. Larger algorithm implementations and larger stored artifacts both eat into it.
3. Bandwidth (the link). How many bytes the device can move per message. Low-power radios are unusually tight here, and a large handshake fragments into many frames.
4. Compute and energy. Clock speed and, on battery or harvested power, the energy per operation. Modern 32-bit parts have more headroom here than the size story would suggest.

Source: pqm4, “Post-quantum crypto library for the ARM Cortex-M4,” github.com/mupq/pqm4.

The reason to name all four is that the binding constraint moves by device and by algorithm. A smart card is tightest on RAM and compute, a low-power mesh sensor is tightest on bandwidth, and a firmware image is tightest on flash and one-shot memory. The same algorithm can fit one and fail another.

Why do post-quantum keys and signatures strain constrained devices?

Because the post-quantum artifacts are much bigger than the classical ones they replace, and size is what a constrained device has the least of. A classical elliptic-curve public key is 32 bytes and an ECDSA signature is about 64 bytes, so both fit in a single small radio frame with room to spare. The post-quantum equivalents run from roughly a kilobyte to tens of kilobytes, so they overflow frames, fill RAM, and enlarge the stored image. The table maps each constraint to the demand and the strain, with cited artifact sizes.

Constraint	Concrete reference budget	What PQC demands	The strain
RAM (working memory)	640 KB on the pqm4 Cortex-M4 board; far less on smart cards and secure elements	Hold a full key, ciphertext, or signature plus scratch space in memory at once	An SLH-DSA-256f signature is 49,856 bytes; on an ESP32, ML-DSA-44 added about 28 KB of peak heap over the ECDSA build
Flash (code + storage)	2 MB on the pqm4 board; kilobytes on the smallest parts	Larger algorithm code plus larger stored keys and certificates	ML-DSA-44 adds several kilobytes of code over ECDSA, and stored certificates grow with the keys inside them
Bandwidth (the link)	An IEEE 802.15.4 radio frame is 127 octets at the physical layer, about 102 at the MAC layer	Move the full handshake and certificate chain across the link	An ML-KEM-768 public key of 1,184 bytes spans about 12 such frames; an SLH-DSA-128s signature of 7,856 bytes spans roughly 77
Compute and energy	Tens of MHz on a typical microcontroller	Run key generation, encapsulation, signing, or verification	Usually the least binding axis; the lattice schemes are fast on 32-bit parts, so cycles rarely decide the outcome

Source: NIST FIPS 203 §7, FIPS 204 Table 2, and FIPS 205 Table 2, August 2024, FIPS 203, FIPS 204, FIPS 205.

Source: J. Blanco-Romero et al., “Post-Quantum Entropy as a Service for Embedded Systems,” arXiv:2603.10274, 2026, Tables 1 and 5, arXiv:2603.10274.

Source: G. Montenegro, N. Kushalnagar, J. Hui, D. Culler, “Transmission of IPv6 Packets over IEEE 802.15.4 Networks,” RFC 4944, September 2007, RFC 4944.

The pattern to hold onto is that signatures are the hard part and key establishment is the manageable part. ML-KEM’s largest ciphertext is 1,568 bytes, which most links can carry, while the conservative hash-based signatures run an order of magnitude larger and are where a constrained design usually breaks.

Which PQC algorithms fit on a constrained device?

The ones that fit are chosen by artifact size and by implementation safety, not by raw speed, and the answer differs for key establishment and for signatures. For key establishment ML-KEM fits comfortably at every parameter set. For signatures the choice is a real tradeoff between signature size, public-key size, and how dangerous the implementation is on small hardware. The table gives the sizes that drive the decision, verbatim from the NIST standards, with a fit note for each.

Algorithm (set)	Public key	Signature or ciphertext	Constrained-device fit
ML-KEM-512	800 bytes	768-byte ciphertext	Smallest PQ KEM; on an ESP32 it was the fastest key exchange measured, so it fits most devices
ML-KEM-768	1,184 bytes	1,088-byte ciphertext	NIST’s default; fits, but fragments across low-power radio frames
FN-DSA (FALCON-512)	897 bytes	666-byte signature	Smallest PQ signature, ideal for thin links, but its floating-point sampler is hard to make constant-time on embedded parts
ML-DSA-44	1,312 bytes	2,420-byte signature	Fast to verify on a microcontroller, but memory-hungry; heap is the binding cost
SLH-DSA-128s	32 bytes	7,856-byte signature	Tiny public key suits a rarely-signing firmware root; the signature is heavy to transport
SLH-DSA-256f	64 bytes	49,856-byte signature	Generally too large to move or buffer on a constrained link

Source: NIST FIPS 203, FIPS 204, and FIPS 205, August 2024; FALCON-512 sizes per the FALCON specification feeding FIPS 206, FIPS 204, FIPS 205.

Two judgment calls sit underneath the table. The first is that FN-DSA’s compactness is tempting for tight links, and its Gaussian sampler relies on high-precision floating-point that can leak the private key if a build cuts a corner, so NIST names ML-DSA the primary signature and FN-DSA a second option for roles where the size saving earns the extra engineering care. The second is that SLH-DSA’s 32-byte public key and conservative hash-only security make it attractive for a firmware root of trust that signs rarely and verifies rarely, as long as the multi-kilobyte signature has somewhere to live.

Is post-quantum cryptography too slow for small devices?

Usually no, and this is the most common wrong assumption about constrained-device PQC. On modern 32-bit microcontrollers the lattice algorithms are competitive with or faster than the elliptic-curve code they replace, so cycles are rarely what stops a deployment. A 2026 study on an ESP32 running DTLS 1.3 over CoAP measured the whole handshake and found the post-quantum path faster end to end.

1. Key exchange got faster. An ML-KEM-512 handshake averaged 313 ms without certificate verification, about 35% faster than ECDHE P-256.
2. Verification got much faster. Certificate verification added roughly 194 ms for ECDSA against about 17 ms for ML-DSA-44, so the fully post-quantum configuration stayed around 63% faster than classical ECDHE with ECDSA even under full verification.
3. Memory was the real cost. That same ML-DSA-44 build was the dominant memory consumer, adding about 28 KB of peak heap over the ECDSA build, which is where a small device actually runs out of room.

Source: J. Blanco-Romero et al., “Post-Quantum Entropy as a Service for Embedded Systems,” arXiv:2603.10274, 2026, arXiv:2603.10274.

So the honest framing of the challenge is memory and bandwidth first, compute a distant concern. When a constrained-device PQC project stalls, the cause is almost always a signature that won’t fit in RAM, a handshake that won’t fit across the radio, or a heap that overflows under load, rather than a device that can’t do the arithmetic in time.

Why is crypto-agility harder on fixed firmware?

Because crypto-agility depends on being able to change the algorithm after deployment, and a large share of constrained devices ship with fixed firmware and no update path, so the choice made at manufacture is frozen for the life of the device. On a server, swapping an algorithm is a library upgrade and a config change. On a sensor welded into a pipeline or a card already in a wallet, there may be no way to push new code at all, which turns algorithm selection into a decision that has to be right for a decade or more.

1. Field lifetimes outrun the deadline. Industrial and operational-technology hardware routinely stays in service 10 to 20 years. A device manufactured today can outlive NIST’s 2035 disallowment of classical public-key algorithms, so it needs a post-quantum algorithm baked in now, before the standard forces the issue.
2. No over-the-air path means no later migration. A device with no way to receive a firmware update stays on whatever cryptography it left the factory with, so it can’t be moved to a new algorithm after the fact. That makes the up-front choice load-bearing in a way it rarely is on general-purpose computers.
3. Hardcoded primitives are structurally non-agile. A primitive compiled straight into firmware, whether asymmetric or symmetric, carries the same multi-year replacement window as any other field-hardware change, which is to say a physical swap rather than a settings change.

Source: NIST IR 8547 (Initial Public Draft), “Transition to Post-Quantum Cryptography Standards,” November 2024, NIST IR 8547 ipd.

The practical consequence is that new constrained deployments earn their agility at design time by making the algorithm a configurable choice and, where the hardware allows, building in a secure update path. The devices that skip that step become the long tail of the migration, the ones that can only be fixed by replacing the hardware.

Common misconceptions

1. “Post-quantum crypto is too slow for tiny devices.” On modern 32-bit microcontrollers the lattice schemes are often faster than the elliptic-curve code they replace. Memory footprint and link bandwidth are what bind, so the challenge is size, and cycles rarely decide it.
2. “Just pick the smallest parameter set and you’re fine.” Smallest artifact size and smallest overall footprint are different things. FN-DSA has the smallest signatures, and its floating-point sampler is genuinely hard to implement safely on embedded parts, so compactness can come with a side-channel hazard.
3. “Hash-based signatures are lightweight because a hash is simple.” SLH-DSA has a 32-byte public key and a multi-kilobyte signature. The signature size, running from about 7.9 KB to nearly 50 KB, is what strains a constrained link and buffer, so the primitive being simple doesn’t make the artifact small.
4. “If it compiles on the device, the crypto is done.” Constrained hardware still has to get constant-time sampling, correct decapsulation error handling, side-channel masking, and a good randomness source right. Each is easy to miss on a small part, and each can undo the security.
5. “Constrained devices are low-value, so they can wait.” Many field devices carry 10-to-20-year lifetimes and fixed firmware, so a unit shipped today outlives the 2035 disallowment and often can’t be updated later. That makes the up-front algorithm choice one of the most durable decisions in the whole migration.

Questions people ask

Can an ESP32 or a Cortex-M4 actually run ML-KEM and ML-DSA? Yes. A 2026 ESP32 study ran a full post-quantum DTLS 1.3 handshake faster than the classical one, and the pqm4 project maintains Cortex-M4 implementations of ML-KEM, ML-DSA, and SLH-DSA. The work is fitting the memory and bandwidth, not making the math run in time.

Which post-quantum signature is best for a bandwidth-limited device? For the thinnest links FN-DSA has the smallest signature at 666 bytes, but it carries real implementation risk on embedded hardware. For most constrained roles ML-DSA-44 at 2,420 bytes is the safer default, and a rarely-signing firmware root can use SLH-DSA-128s for its 32-byte public key.

Why is SLH-DSA a problem on small devices? Its signatures are the largest in the standardized set, from 7,856 bytes at the smallest parameter set to 49,856 at the largest. A constrained device has to buffer the whole signature in RAM to verify it and move it across a link that may only carry about 100 bytes per frame, so both memory and bandwidth are stressed at once.

How much extra memory does post-quantum crypto need on a microcontroller? It depends on the algorithm, and one concrete data point is that adding ML-DSA-44 to an ESP32 DTLS build raised peak heap by about 28 KB over the ECDSA version. That heap headroom, rather than clock speed, is usually the figure that decides whether an algorithm fits.

Do smart cards and secure elements support post-quantum crypto yet? Support is emerging rather than universal. Secure elements are among the tightest devices on RAM and compute and have strong side-channel requirements, so vendors are adding ML-KEM and ML-DSA carefully, and the large signature schemes remain the hardest fit for that class of hardware.

What about the random number generator on a constrained device? It’s a real constraint. Post-quantum key generation and signing need good randomness, and small devices often lack a strong entropy source, which is the specific problem the 2026 embedded-systems study set out to address with an entropy service for exactly these platforms.

How do I benchmark PQC on my own hardware? The pqm4 framework is the community standard for the ARM Cortex-M4, and it reports the three numbers that matter for fit, which are cycle counts, stack usage, and code size, across the standardized schemes. Those metrics tell you whether an algorithm fits before you commit to it.

Why can’t I just update the firmware to a post-quantum algorithm later? Many constrained devices have no secure over-the-air update path, so whatever cryptography ships at the factory is frozen for the device’s life. That’s why crypto-agility on constrained hardware is a design-time decision, and why a device with a long field life needs its post-quantum choice made up front.

---

Everything here is the map, given freely. When your team needs its own fleet of constrained devices inventoried, its algorithms sized to the memory and bandwidth each part actually has, and the fixed-firmware long tail sequenced before 2035, that’s the work I do. Request an alignment briefing.

Last verified 2026-07-09 · Maintained by Addie LaMarr, LaMarr Labs.