Your Embedded Hardware Has a Quantum Problem Nobody Is Talking About
The chip in your car, your hospital’s infusion pump, your building’s security panel — may not be upgradeable. For a lot of deployed hardware, the path ends in physical replacement. Here’s the board-level reality nobody’s published yet.
Table of Contents
Post-quantum cryptography embedded systems have a problem the software world isn’t talking about — the algorithms don’t fit the hardware.
Let me start with the number that should end the “we’ll deal with it later” conversation.
584.2 milliseconds.
That’s the 99th-percentile signing time for ML-DSA-44 in the paper’s larger 10,000-signature campaign — the lowest-security ML-DSA parameter set — on an ARM Cortex-M0+ running at 125 MHz (per arXiv:2603.19340v6, August 2026). If your system has a 100 ms hard real-time deadline — a lot of industrial control loops do — that’s not a slow migration. That’s a failed migration. The benchmarked implementation can’t meet that deadline even at the lowest security level.
And that’s before we even get to whether it fits in RAM. It often doesn’t.
I think this is what most post-quantum cryptography embedded systems conversations miss entirely. Everyone’s focused on which algorithm to pick. The actual problem, in my experience, is whether your hardware can run it at all.
New to this? Start with Part 1: The Quantum Computer Is Coming: Why Today’s Encryption Could Soon Be Useless first. This piece is the hardware deep-dive.
Most quantum-encryption talk stays at the software layer. Change the algorithm. Patch the server. Ship it.
That works for cloud. It is dangerously wrong for most of the physical world.
Think about what actually runs quietly around you. The chip managing keyless entry in your car. The controller in a hospital infusion pump. A security module in a power substation that nobody opens for five years. A smart meter on the side of your house. None of these get patched on a Tuesday. They’re physical objects — chips on boards — built for a world where the crypto they run was assumed to be safe forever. If you want to see how deep that problem runs in automotive silicon specifically, self-driving car hardware security is where the same pattern plays out at its most complex.
That assumption is ending. For a big chunk of those devices, there’s no firmware update that fixes it. You hit silicon. For some that means a new chip on a new board. For others it means external secure element co-processors, gateway-assisted PQC termination, or documented risk acceptance while you wait out a replacement cycle.
None of those are fast. None are cheap.
I’ve had the meeting where someone from IT presents the NIST standards, legal asks about timelines, the CTO nods, everyone agrees migration matters, and it ends. What doesn’t happen: anyone walking down to the lab and asking the embedded engineers what it would actually take to run ML-KEM on the hardware shipping right now.
I’ve had that other conversation too. It goes differently.
Not an embedded engineer? Each specialist term — microcontrollers, TPMs, FPGAs — gets explained when it shows up. The core problem: small chips inside physical devices have such tight memory and speed limits that new quantum-safe algorithms don’t fit. Where there’s no upgrade path, that means physical replacement. Where there is one, it means external security chips, quantum-safe gateways, or accepted risk until you can swap the hardware.
Embedded engineer? Skip ahead. What follows is the board-level stuff the standards bodies haven’t put in writing yet.
Post-Quantum Cryptography Embedded Systems: The Memory Wall
(Why new quantum-safe algorithms won’t fit most existing chips)
Here’s the number that changes the conversation. 800 bytes.
That’s the public key size for ML-KEM-512 — the lowest security level in NIST’s FIPS 203 standard. The three parameter sets (ML-KEM-512, ML-KEM-768, ML-KEM-1024) produce public keys of 800, 1,184, and 1,568 bytes per NIST FIPS 203, Table 2. That’s before stack space for key generation, encapsulation, and decapsulation.
Here’s where the real number lives. Per arXiv:2603.19340v6 (August 2026), running ML-KEM on an ARM Cortex-M0+ at 125 MHz on an RP2040 needs a total RAM footprint — peak stack plus key material plus working buffers — of 12.6 KB for ML-KEM-512, rising to 26.2 KB for ML-KEM-1024. ML-DSA is far worse: 56.8 KB for ML-DSA-44, 86.7 KB for ML-DSA-65, and 131.5 KB for ML-DSA-87 — driven mainly by peak stack usage during signing, which alone reaches 119.6 KB for ML-DSA-87, consuming roughly 45% of the RP2040’s total SRAM. Code/flash footprint is much smaller and separate from this — 5.1–6.7 KB for ML-KEM, 8.4–8.9 KB for ML-DSA — but flash footprint isn’t the constraint that matters here. RAM is.
The RP2040 is not itself an RFC 7228 Class-1 device — it has 264 KB of SRAM — but its ARMv6-M architecture makes it a useful processor-class proxy for constrained embedded designs. The measured memory requirements can then be compared against the much smaller RAM budgets of RFC 7228 Class-1 devices, such as constrained sensors and field nodes. Devices with 8 KB or less of total RAM don’t have the headroom for any of these reference implementations natively — not even ML-KEM-512 at 12.6 KB, let alone ML-DSA’s 56-plus KB. Not natively.
On the other hand, maybe I’m being too harsh on the smaller devices — there are exits. External Secure Elements (SEs) via I2C or SPI can offload PQC operations. Gateway termination works for devices that only need network-boundary protection. But for anything that has to run PQC natively on-device? The silicon constraint is real. Software won’t fix it.
Here’s where the location of that computation stops being a footnote and becomes an actual design decision. Running the algorithm in software on the MCU keeps things flexible and field-updateable, but it eats directly into the same RAM and compute budget everything else on the chip is fighting over. Pushing it to an external secure element isolates the key material and offloads the arithmetic — but that SE now has to be wired in over I2C or SPI, initialized, and kept in sync with whatever secure boot chain trusts it, and its own algorithm support has the same upgradeability question as any other fixed silicon. Routing it to a gateway keeps the constrained endpoint simple, but it means the endpoint’s security now depends on a network path and a gateway that has to be online and trustworthy. None of these is universally correct. Which one is right depends on whether the device needs to authenticate itself independently, how often it talks to anything, and what happens if the network link is down when it needs to.
The capable end is the ARM Cortex-M4. WolfSSL’s published benchmarks on the STM32F4 Cortex-M4 (pqm4 framework, Kannwischer et al., NIST PQC Conference 2019) put ML-KEM-512 key generation at 4.566 ms and the full encapsulation/decapsulation cycle at 10.542 ms — 15.108 ms combined. Fine for most things. Still meaningful for latency-sensitive protocols.
Now. ML-DSA. This is where it gets ugly.
Per arXiv:2603.19340v6, ML-DSA signing has a coefficient of variation of 66.0–73.5% across its three security levels — caused by the rejection sampling step in FIPS 204. For ML-DSA-44, the paper’s larger 10,000-signature campaign puts the 99th-percentile signing latency at 584.2 ms. The fastest observed signature in that same campaign was 80.12 ms, putting the observed spread at approximately 7.3×. The smaller 100-signature campaign reported 489.4 ms at p99 and 70.14 ms for its fastest observed signature, but the larger campaign provides the better-resolved tail estimate. ML-DSA-65 reaches 952.8 ms at the 99th percentile, and ML-DSA-87 hits 1,124.5 ms. If you’ve got a 100 ms hard real-time deadline — industrial control loops — this reference implementation can’t demonstrate a 100 ms deadline at any ML-DSA security level.
That timing variance carries an energy consequence too, though the honest picture is more nuanced than “PQC drains your battery.” The same paper’s active-power model (RP2040 rated at 3.3V, 24mA active current, 79.2mW) puts a full ML-KEM-512 key exchange at an estimated 2.83 mJ — well below the estimated 48.9 mJ for a comparable ECDH P-256 key agreement on the same hardware. A full ML-DSA-44 key generation + signing + verification cycle comes in around an estimated 19.2 mJ, still lower than an estimated 39.4 mJ for a full ECDSA P-256 cycle. These are model-derived estimates, not direct instrumented measurements — the paper is explicit that they follow from the constant active-power assumption above, not from measured current draw. In other words: under this constant-power model, the benchmarked post-quantum operations do not appear to impose a higher per-operation energy cost than the classical baselines tested here. That conclusion is specific to this implementation and model; it is not a universal statement about PQC power consumption. Where energy does become a live concern is the tail: because the model treats active power as roughly constant, a longer worst-case signature also represents a larger energy draw for that one operation. On a device doing occasional authenticated reporting, that’s a small fraction of typical primary-cell budgets. On a device doing frequent signing under tight duty-cycle constraints, that tail — not the average — is what a power budget needs to be sized against.
SLH-DSA (FIPS 205) is worth looking at here. Stateless hash-based signature scheme. Deterministic signing time. No rejection sampling variance. For timing-constrained use cases, that matters a lot — and it also means a predictable, budgetable energy cost per operation, rather than the swing seen in ML-DSA.
In plain terms: the chip in your smart meter, car ECU, or hospital bedside monitor probably can’t run the new quantum-safe algorithms natively. Where native execution is off the table: external SE co-processor, gateway termination, or hardware replacement. None of it is free.
Is Your TPM Actually Ready for Post-Quantum Cryptography?
(TPM = Trusted Platform Module — the security chip acting as hardware root of trust)
To be honest, this is the part I find most frustrating. The vendor announcements sound good. The reality under them isn’t.
The Trusted Computing Group released TPM 2.0 Library Specification v1.85 in March 2026, adding formal support for ML-KEM (FIPS 203) and ML-DSA (FIPS 204). WolfSSL shipped firmware TPM support for v1.85 on Cortex-M33 and STM32 secure enclaves. STMicroelectronics shipped the ST33KTPM with field-upgrade capability for PQC algorithms — authenticated via LMS signatures per NIST SP 800-208. Real progress.
But here’s what those announcements don’t say.
v1.85 is from March 2026. The chips implementing it are new. The TPM 2.0 chips soldered onto motherboards, sitting inside industrial panels and medical enclosures around the world right now? Earlier specs. Fixed algorithm sets. Defined in silicon. ML-KEM and ML-DSA not included.
Field-upgradeable firmware TPMs exist — but only if the chip was built for it, if the OEM supports the signed update, and if the host secure boot chain can authenticate the new payload. Most TPMs shipped before v1.85 don’t meet those conditions. Some enterprise-grade TPMs on programmable secure elements can get firmware updates — but that depends on NVM capacity and ongoing manufacturer support, conditions that narrow fast. Many discrete TPM architectures were not designed for field-upgradeable algorithm agility.
I know what you’re thinking — “but our vendor said migration is supported.” Maybe. Ask them specifically: which TPM revision is on your boards, does their support cover your product’s replacement lifecycle, and what happens if they drop support. I’ve noticed those three questions change conversations quickly.
A post-quantum TPM spec doesn’t help a device that shipped with a pre-v1.85 chip and no upgrade path. Many of those devices may ultimately need hardware replacement for native PQC support.
For non-engineers: think of it like a safe with a lock that can never be changed. New technique breaks the lock? Can’t retrofit. Buy a new safe. Most deployed TPMs are exactly that safe.
That “agility versus fixed silicon” question is worth pulling apart, because it’s a real design trade-off, not just a TPM problem. Building crypto-agility into a device from the start — enough SRAM headroom for future algorithms, a firmware-updatable crypto module instead of hard-wired logic, configurable interfaces rather than one fixed protocol — costs something today: more memory, more silicon, more firmware complexity, more validation work before the product ships. Skipping all of that keeps the current design cheaper and simpler, but it locks in whatever algorithm shipped on day one, with no path off it except a hardware respin. The trade-off is straightforward once you say it plainly: pay more and design more carefully now, or accept a higher chance of the entire device becoming an unfixable liability the day its cryptography is deprecated. Given how the ML-KEM/ML-DSA memory numbers above look against an 8 KB device, that second outcome isn’t hypothetical.
One more consequence worth naming plainly: none of this stays purely cryptographic once you decide the fix is hardware. If the answer for a given product is “add an external secure element” or “swap the TPM for a v1.85-capable part,” that’s a bill-of-materials change, not just a firmware ticket. A new component means new board footprint and placement, new power and interface requirements to accommodate, and — depending on the industry — a qualification cycle before it can ship. It may also mean re-evaluating that part’s own supply-chain and lifecycle risk, since you’re now depending on a second vendor’s roadmap in addition to your own. None of this means every PQC migration forces a board redesign. It means that once native software migration is off the table, the decision stops being “which algorithm” and starts being a hardware sourcing and manufacturing decision with its own timeline.
FPGA Bitstream Security and the Post-Quantum Gap Nobody Discusses
(FPGA = Field-Programmable Gate Array — a reprogrammable chip in telecom, defence, industrial systems)
I’ve found FPGAs get walked past in almost every post-quantum cryptography embedded systems migration conversation. That’s a mistake.
FPGAs use bitstream encryption to keep configuration images from being read, copied, or reverse-engineered. Most vendors use AES-256 for this. AES-256 is quantum-resilient — drops to roughly 128-bit effective security under Grover’s Algorithm, which cryptographers still consider solid. So that part’s fine.
The problem is how the AES key gets loaded. Full stop.
AMD (Xilinx) and Intel (Altera) — the two main FPGA vendors — both use RSA-based authentication as part of their key delivery architecture. Per AMD’s app note XAPP1267 (Encrypting and Authenticating eFUSE Programming for UltraScale and UltraScale+ FPGAs), UltraScale devices store the AES-256 key in BBRAM or eFUSE, with RSA auth verifying the boot image. AMD’s Security Bulletin AMD-SB-8002 (CVE-2023-20570) confirms RSA is structural to the boot authentication chain. Intel’s Quartus Prime Pro security docs describe the same RSA-based auth for Agilex and Stratix 10.
RSA is exactly what Shor’s Algorithm breaks. That’s the problem.
One caveat — good news if you’re designing new hardware: some 2024 and 2025 FPGAs use Physically Unclonable Functions (PUFs) for root key derivation. PUFs derive the AES key from physical manufacturing variation rather than BBRAM or eFUSE. Different threat model. If you’re doing a new design, look at FPGA families with PUF-based secure boot. But most FPGAs in the field — automotive, industrial, defence — predate PUF adoption. Those carry the RSA-layer exposure.
The bitstream is protected by AES-256. RSA authentication wraps the chain that provisions and controls that AES key. When a quantum computer breaks RSA, the whole boot and key-delivery chain is compromised — not because AES-256 failed, but because the layer above it did.
Plain version: the safe is strong. The key to the safe is in a box a quantum computer can open. Once they have the key, the safe doesn’t matter.
Per Semiengineering’s analysis citing Flex Logix engineering leadership, automotive and industrial chipmakers need to plan for ten to twenty year device lifespans. Design quantum-safe key delivery before the first board spin. Not after. The EV cybersecurity vulnerabilities exposed at Pwn2Own show exactly what happens when hardware security assumptions break down in automotive silicon — and quantum computing makes that risk significantly worse.
What a Quantum-Aware Board Design Actually Takes
I’ve found NIST, NSA, and NCSC guidance is solid at the algorithm level. What’s missing is the translation down to the board. Here it is.
Inventory at the component level — not the software level. Every chip. Every TPM. Every secure element. Every FPGA. Mapped against silicon algorithm support and upgrade path. A Cortex-M0+ running ECDH for IoT auth is a completely different post-quantum cryptography embedded systems migration problem from a server-side TLS stack. Both need to move. Neither moves the same way. Do the inventory first.
SRAM budget before algorithm. ML-KEM-512 needs 12.6 KB total RAM (peak stack plus key material plus working buffers), rising to 26.2 KB at the highest security level, per arXiv:2603.19340v6. ML-DSA needs 56.8–131.5 KB. On a device with 8 KB total SRAM, none of these parameter sets fit — that’s not an optimization target, it’s a hard stop. If the chip can’t fit even ML-KEM-512, the path is hardware replacement, external offload, or gateway termination. That decision belongs on the plan now.
Secure boot is the critical path. The chain from hardware root of trust through bootloader through firmware is where transitions get ugly. Mask ROM is immutable. RSA-2048 verification burned into mask ROM means no patch — only a hardware respin. Know which layers are immutable before designing the migration timeline. That same requirement is now showing up outside IT entirely: IACS UR E27 requires a hardware root of trust for secure boot on autonomous cargo ship systems, without yet specifying which cryptographic primitives are expected to survive the transition this article is about.
Side-channel exposure in PQC implementations — don’t skip this. ML-KEM and ML-DSA introduce new side-channel surfaces: power analysis during NTT (Number Theoretic Transform) ops, EM leakage during polynomial multiplication, timing variance from ML-DSA rejection sampling. For medical devices, automotive ECUs, defence electronics — migrating without evaluating the side-channel profile is an incomplete migration. PSA Certified Level 2 and SESIP (Security Evaluation Standard for IoT Platforms) are the right frameworks to evaluate implementations against — note that certification under either scheme addresses secure development and evaluation practices broadly and isn’t a specific guarantee of PQC side-channel resistance on its own.
Crypto-agility on the next board spin. Devices shipping today will be in the field through the quantum transition. The next spin needs PQC as a first-class silicon requirement: SRAM headroom for ML-KEM and ML-DSA buffers, a TPM with a v1.85-capable upgrade path, FPGA key delivery built around ML-KEM transport, and a secure boot chain that authenticates ML-DSA or LMS-signed firmware per NIST SP 800-208. This is especially relevant for humanoid robots now entering factory floors — embedded systems shipping today that will be in operation well inside the quantum threat window.
The Hardest Part — What’s Already in the Field
I want to be direct about this. It’s uncomfortable.
Hundreds of millions of embedded devices are running right now — hospitals, power grids, factory floors, cars — on RSA and ECC hardware that can’t migrate to ML-KEM. Some have ten-year windows. Some fifteen. Some will outlast the 2035 federal migration planning horizon per NIST guidance, and the EU Cyber Resilience Act’s IoT security-update requirement. Implantable medical devices represent the most extreme version of this problem — hardware that lives inside patients, runs for decades, and cannot be recalled or field-upgraded on any timeline driven by cryptographic standards.
Per RAND Corporation’s 2023 assessment of quantum computing vulnerabilities in ICS and OT environments (RR-A2427-1): hardware replacement cycles are measured in decades, and operational constraints make taking critical infrastructure offline essentially impossible.
To be honest, the migration plan for those devices isn’t about algorithms. It’s end-of-life planning, network segmentation, and formally documented risk acceptance — in that order. The conversation isn’t just “which algorithm.” It’s “which devices are stuck, and what’s the risk posture until they can be replaced.”
That conversation needs someone who knows what’s actually on the board.
Not just what’s in the deck.
This is Part 2 of a two-part series. Read Part 1: The Quantum Computer Is Coming: Why Today’s Encryption Could Soon Be Useless for the foundational overview — RSA, ECC, HNDL attacks, and the NIST PQC standards.
About the Author
Imran Valiani | Sales Director, PCB Electronics Manufacturing
20+ years working with major Bay Area and global tech clients. Founder of Silicon to Software, where I write about the hardware layer — PCB fab, AI gear, autonomous systems, and cyber — the stuff most tech writers have never touched. Literally.
Follow: X @SiToSoftware | LinkedIn
This article was developed with AI assistance and edited, fact-checked, and reviewed by the author. See my full AI disclosure.
Sources & Further Reading
- NIST FIPS 203, Table 2, August 2024
- NIST FIPS 204, Table 1, August 2024
- NIST FIPS 205, August 2024
- Chhetri, “Benchmarking NIST-Standardised ML-KEM and ML-DSA on ARM Cortex-M0+: Latency, Rejection-Sampling Variance, and Memory on the RP2040,” arXiv:2603.19340v6, August 11, 2026
- Kannwischer et al., “pqm4: Testing and Benchmarking NIST PQC on ARM Cortex-M4,” NIST PQC Conference, 2019
- wolfSSL, “Benchmarks for Kyber Level 1 PQM4 Integration on STM32,” wolfssl.com
- AMD XAPP1267, Encrypting and Authenticating eFUSE Programming for UltraScale and UltraScale+ FPGAs
- AMD Security Bulletin AMD-SB-8002 (CVE-2023-20570)
- Intel Quartus Prime Pro Edition Security Overview for SDM-based FPGA Devices
- Trusted Computing Group, TPM 2.0 Library Specification v1.85, March 12, 2026
- wolfSSL, “The First Firmware TPM with Post-Quantum Cryptography,” 2026
- STMicroelectronics ST33KTPM product page
- NIST SP 800-208, October 2020
- NIST IR 8547, 2024 initial public draft
- NIST SP 800-56C Rev. 2
- NSA CNSA 2.0 Advisory, September 2022
- RAND Corporation RR-A2427-1, October 2023
- EU Cyber Resilience Act
- Flex Logix, cited in Semiengineering analysis
- PSA Certified
- GlobalPlatform SESIP
- STMicroelectronics STSAFE-A, Microchip ATECC, NXP SE050 product lines
