- On an ARM Cortex-M4 (STM32F407G), SPHINCS+ ran at execution times too slow for production, and the reference CRYSTALS-Dilithium implementation failed to run at all under the chip’s RAM and timing limits.
- Porting Dilithium to a Xilinx Zynq-7000 ZedBoard SoC with a purpose-built Number Theoretic Transform (NTT) accelerator restored key generation and signature generation to millisecond levels.
- If your post-quantum migration plan assumes a software-only firmware update on commodity microcontrollers, that plan has a hardware gap you need to close before deployment.
Why Software-Only PQC Breaks on Standard Microcontrollers
Picture the migration plan most embedded teams are drafting right now: when “harvest now, decrypt later” forces the switch to NIST-standardized signatures, ship a firmware update that swaps ECDSA for a quantum-resistant scheme like CRYSTALS-Dilithium or SPHINCS+. No new silicon, no BOM change, no recall. One over-the-air push and the fleet is quantum-safe.
New benchmarks published in arXiv:2606.15744v1 (June 2026) show that plan collapses on contact with real hardware. The researchers implemented both NIST-standardized signature schemes on an ARM Cortex-M4 — specifically the STM32F407G, a 32-bit core representative of the controllers running in industrial sensors, smart meters, and medical devices — and measured what software-only PQC actually costs. The Cortex-M4 was not chosen as a weak target; it was chosen because it is the kind of part already deployed by the millions and the kind your next product will likely use.
The verdict was blunt. SPHINCS+, the hash-based scheme prized for its conservative security assumptions, was practically unusable in a software-only environment, with execution times the authors describe as impractical. CRYSTALS-Dilithium fared worse:
The reference Dilithium implementation failed to execute entirely on the STM32F407G due to severe RAM and timing constraints. — arXiv:2606.15744v1
That is not “slow.” That is a scheme that does not run. For any organization whose attack-surface reduction strategy assumes a clean software swap, this is the finding that should reset the roadmap.
[IMAGE: macro photograph of an STM32 Cortex-M4 microcontroller on a dark circuit board with glowing cyan traces]
The Technical Deep-Dive: Where the Cycles Go
What the schemes demand
Both schemes are NIST-standardized, but they stress a microcontroller differently. SPHINCS+ is hash-based and stateless, trading large signatures and heavy computation for minimal cryptographic assumptions. Dilithium is lattice-based, and its performance hinges on polynomial multiplication — the operation accelerated by the Number Theoretic Transform (NTT). The NTT is to lattice cryptography what the FFT is to signal processing: the inner loop everything else waits on. On a Cortex-M4 with no dedicated unit for it, that loop becomes the bottleneck, and Dilithium’s working-set memory exceeds what the MCU can comfortably hold — which is why the reference build did not merely lag, it failed to execute.
Definition — hardware-software codesign for PQC: an implementation strategy that keeps protocol logic and control flow in software on a general-purpose core, while offloading the cryptographically expensive primitive (here, the NTT used in lattice polynomial multiplication) to dedicated hardware on the same chip. The goal is to hit production latency without committing to a full custom ASIC.
What the FPGA changed
To break the bottleneck, the team integrated a hardware-accelerated Dilithium core onto a Xilinx Zynq-7000 ZedBoard SoC and implemented a specialized NTT accelerator directly in the FPGA fabric. The processor runs the protocol; the fabric runs the math.
The result: successful execution with key generation and signature generation at millisecond levels — the difference between a scheme that cannot run and one that fits inside a practical authentication or firmware-signing window.
| Dimension | Software-only on STM32F407G (Cortex-M4) | Hardware-software codesign on Zynq-7000 SoC |
|---|---|---|
| SPHINCS+ execution | Impractical — practically unusable | Not the focus; codesign targeted Dilithium |
| Reference Dilithium | Failed to execute (RAM + timing limits) | Runs successfully |
| NTT polynomial math | Software, bottleneck | Dedicated FPGA accelerator |
| Key generation | Not viable | Millisecond level |
| Signature generation | Not viable | Millisecond level |
| Deployment verdict | Non-viable | Viable for embedded quantum resistance |
These results demonstrate that while pure software PQC is non-viable for standard microcontrollers, a hardware-software codesign approach provides the necessary efficiency for quantum-resistant embedded systems. — arXiv:2606.15744v1
A caveat worth carrying into procurement: the study reports the accelerated results as “millisecond level” without exact figures, and it measured key generation and signature generation — not verification, power draw, or FPGA resource utilization. Treat the direction as proven and the precise budget as something to benchmark on your own parameter set.
Industry Context: What This Means for Your Migration Path
The regulatory clock is the reason this matters now. NIST has finalized its first PQC standards and is pushing agencies and vendors toward migration this decade; signature schemes like Dilithium and SPHINCS+ are the ones embedded systems will be expected to support. The research exposes a gap between the policy timeline and the silicon reality: the standards are ready, but the commodity hardware in the field is not.
That gap reshapes three planning horizons:
- Near term (1–2 years): Any product built on a Cortex-M4-class MCU cannot assume a software-only PQC update. Teams must either select scheme parameters that fit the chip or commit to hardware acceleration before tape-out.
- Medium term (3–5 years): Quantum-resistant embedded systems will likely standardize on FPGA/SoC NTT accelerators. That shifts BOM cost and silicon selection — vendors of secure microcontrollers without dedicated PQC acceleration become harder to justify.
- Long term (5+ years): Purpose-built PQC acceleration — NTT cores in FPGA fabric or ASICs — becomes the default for constrained devices, because pure-software lattice and hash-based signatures have now been demonstrated non-viable on commodity parts.
Who moves, who lags
The organizations that will move first are the ones whose devices have long field lives and hard signing requirements — automotive, industrial control, medical, and metering — where a hardware refresh costs years and millions. The laggards will be teams that read “NIST standardized it” as “we can deploy it in firmware” and discover the gap only at integration. The economic framing for the boardroom is simple: the cost of inaction is not a slow device — it is a fielded fleet that physically cannot run the cryptography regulators will require, remediable only by hardware refresh. The cost of action is making silicon-level PQC acceleration a selection criterion today.
The BeQuantum Perspective
This research validates the architectural bet behind BeQuantum’s hardware strategy. We treat the NTT bottleneck not as an optimization problem to defer but as a design constraint to plan around — the same conclusion the Zynq-7000 results reach.
BeQuantum’s IceCase hardware is built on exactly this codesign principle: dedicated acceleration for the lattice primitives that strand general-purpose microcontrollers, so PQC signatures complete inside real authentication windows rather than failing to run. Our PQC Layer is parameter-aware — it selects scheme and security level against the target’s actual memory and timing budget, so a device never ships with a configuration that, like the reference Dilithium here, cannot execute. And our Digital Notary anchors firmware and update signatures to verifiable, quantum-resistant proofs — a guarantee that only holds if the signing operation can run on the device in the first place, which is precisely what hardware acceleration delivers.
The lesson we draw, in the authors’ own framing: efficiency for quantum-resistant embedded systems comes from codesign, not from waiting for software to catch up.
What You Should Do Next
- Within 90 days, inventory your embedded cryptographic footprint. List every fielded and in-design product running on Cortex-M-class MCUs and flag those expected to support PQC signatures. These are your highest-risk SKUs.
- Benchmark before you commit a parameter set. Run your candidate Dilithium and SPHINCS+ configurations on your actual target silicon — do not trust reference numbers. Measure key generation, signing, verification, RAM, and power, since the source quantified none of these.
- Make PQC acceleration a procurement gate. For any new silicon selection in the next design cycle, require dedicated NTT/lattice acceleration (FPGA fabric, SoC, or secure element) as a hard requirement, not a nice-to-have.
FAQ
Q: Can’t I just pick a smaller PQC parameter set to fit a microcontroller instead of adding hardware? A: Lighter parameter sets may help, but the study tested reference implementations and still saw Dilithium fail to run and SPHINCS+ become impractical on a Cortex-M4. Smaller parameters trade security margin for footprint and are not guaranteed to close the gap — benchmark on your target before assuming they will.
Q: Is this only a Dilithium problem, or does it affect SPHINCS+ too? A: Both. SPHINCS+ was practically unusable in software-only form on the STM32F407G, and the reference Dilithium implementation failed to execute entirely. The hardware-accelerated path was demonstrated for Dilithium via an FPGA NTT core.
Q: Does hardware-software codesign mean every IoT device needs an FPGA? A: Not necessarily. The research used a Zynq-7000 FPGA-SoC to prove the principle, but the same codesign approach can be realized in ASICs or secure elements with dedicated NTT acceleration. The takeaway is that the cryptographic primitive needs hardware support — the exact form depends on your volume and power budget.
Last updated: June 21, 2026. Category: post-quantum-cryptography. Source: Comparative Performance Analysis of NIST PQC Standards: From STM32 Software Limitations to FPGA-SoC Acceleration (arXiv:2606.15744).
