Post-Quantum Cryptography Has to Fit on Devices That Have No Room.

The post-quantum standards are a genuine achievement. After years of public analysis, the world has lattice-based and hash-based schemes it can reason about with confidence. For anyone running a server, adopting them is mostly a library upgrade. For anyone shipping a microcontroller, it is a different conversation, because the thing that makes these schemes safe also makes them large, and large is the one property an embedded device cannot absorb.

A small device has tens of kilobytes of RAM, a flash budget already crowded with application code, a handful of one-time-programmable fuses for its trust anchor, and a service life measured in years during which it may never be physically reachable again. Post-quantum keys and signatures are measured in kilobytes. The mismatch is not a tuning problem. It is structural, and it has to be confronted in the hardware design, not patched afterward.

The standards don't care about your RAM budget

The selection process that produced the post-quantum standards weighed security first and performance second; artifact size was a real but subordinate constraint. That is the correct priority for a standard meant to protect everything from browsers to backbones. The consequence for embedded engineers is that lattice schemes such as ML-KEM and ML-DSA, and the hash-based SLH-DSA, all carry public keys and signatures that dwarf their elliptic-curve predecessors. On a server with gigabytes of memory, the difference between a few dozen bytes and a few thousand disappears into the noise. On a part specified with a fixed, small RAM region and a flash layout planned to the sector, those same bytes can exceed the space that was allocated for the whole cryptographic subsystem. The algorithm did not get harder to run; it got bigger to hold, and holding is what a constrained device is worst at.

Where the bytes hurt

There is no single number that decides whether a scheme fits. The constraint is the simultaneous peak — the moment at which keys, code, working memory, and link capacity are all demanded at once. It is worth naming where each kind of pressure lands, because they are paid out of different budgets and an engineer who solves one often forgets another.

• Flash for keys and code — larger public keys and the verification routine itself both compete for a fixed flash budget that is already mostly application firmware.
• RAM for the working set — a signature that must be held in memory while it is checked, together with the scheme's internal verification state, can exceed the RAM a small part was specified with.
• OTP for the anchor — the root public key, or its hash, lives in one-time-programmable fuses measured in bits; a larger anchor means more fuses, and that allocation is decided before the chip is made.
• Airtime on the link — on a constrained radio every extra kilobyte is energy spent, airtime occupied, and a wider window in which a packet can be lost and the exchange restarted.

Boot-time verification cost

Size is not the only tax; verification takes time, and on a constrained part that time is visible. On a server-class processor with hardware acceleration, verifying a post-quantum signature is a matter of microseconds and no one notices. On a low-clock microcontroller with no accelerator, verifying a large signature at every boot is measurable wall-clock latency and measurable energy. For a device that boots frequently, or that must wake, verify, and respond inside a tight power envelope, that latency is a product characteristic the user will feel, not an implementation detail. The verification code path also grows, and it grows in the most sensitive place — the early boot stage that runs before most of the system's defenses exist. A heavier, more complex verifier at the root of trust is more code to get exactly right in the environment least forgiving of mistakes.

The fielded-root problem

This is the constraint that turns an inconvenience into a design emergency. A device's trust anchor — the root public key or hash that its secure-boot chain is built on — is typically burned into one-time-programmable fuses at manufacture, precisely so that an attacker cannot change it. That permanence is a security feature and a migration trap at the same time. If a device left the factory anchored only to a classical key, with no provisioned space or logic for a post-quantum successor, then post-quantum verification cannot be added to that device later. There is no field path to re-provision a fuse that was never allocated. The same discipline that makes a secure-boot root defensible against a physical attacker — immutability, anchored in silicon — is what makes a short-sighted anchor permanent. Agility at the root is therefore not a firmware feature you can ship in an update; it is a silicon decision that has to be made before the design is taped out, in the same conversation as the secure-boot chain and the provisioning flow that programs those fuses.

On a server the size of a post-quantum signature is a rounding error; on a microcontroller it is a design constraint that has to be settled before the silicon is taped out.

Hybrid and the size tax on constrained links

Hybrid schemes — carrying a classical and a post-quantum component together, so security holds unless both break — are the sensible default for the transition on the open internet. On a constrained device the same conservatism costs double in the worst possible place. A hybrid key exchange means two key shares on the wire; a device that authenticates with both a classical and a post-quantum signature carries both footprints in flash and in the air. For a part on a low-power radio with a small frame size, that doubling is paid in airtime and battery, and it interacts badly with links that fragment anything larger than a small packet. The cruel part is the correlation: the devices that most need the belt-and-braces safety of a hybrid — long-lived, unreachable, impossible to re-provision — are frequently the ones on the thinnest links, least able to afford the bytes. There is no universal answer. There is only an honest accounting of shelf life against link budget, made per product.

Designing embedded PQC agility

None of this argues against post-quantum cryptography on small devices. It argues for deciding the hardware envelope deliberately rather than discovering it after tape-out. That means allocating OTP space for at least one successor anchor and the logic to prefer it; reserving flash headroom for a second verification routine so the device can run both the algorithm it ships with and the one it will need; keeping the cryptographic calls behind an internal interface so a provider can be swapped without rewriting the application; and sizing the RAM working set against the largest signature the device could plausibly be asked to verify, not the one it happens to use today. These are not exotic techniques. They are the embedded expression of crypto-agility, and like all agility they are cheap to design in and nearly impossible to retrofit.

What to plan now

The practical stance is to treat size, boot-time cost, and anchor agility as first-class requirements in the hardware specification, alongside power and unit cost, for any product whose service life reaches toward the quantum horizon. A device designed today with no headroom for larger keys, no OTP space for a new anchor, and no abstraction over its cryptographic primitives has quietly decided that it will never migrate — and for a part that lives a decade in the field and cannot be recalled, that decision is being made for everyone who will depend on it.

When 6QURE reviews an embedded design for the post-quantum transition, the question is rarely whether the algorithm is strong enough; the standards settle that. It is whether this specific device has the flash, the RAM, the OTP allocation, the boot-time budget, and the anchor agility to run post-quantum verification in the tenth year of a service life that was committed to in the first. That review happens best before tape-out, because afterward the fuses are the shape they are, and the most important decisions have already been made in silicon that no update can reach.