Achieving sub-millisecond post-quantum TLS 1.3 handshakes on ARM Cortex-M85 IoT edge devices

We have been talking about post-quantum cryptography for years. The standard industry line is that migrating to quantum-resistant algorithms will crush edge device performance. I spend a lot of time looking at IoT architectures and the compute overhead for lattice-based cryptography usually introduces unacceptable latency for deterministic systems. But recent developments in silicon and compiler optimization are changing the math.

Hardware meets mathematical optimization

Let us look at the hardware first. In early 2026 STMicroelectronics dropped the STM32V8. This is the first Cortex-M85 flagship microcontroller built on an 18nm FD-SOI process. It clocks at 800 MHz with 4 MB of phase-change memory. What really matters for engineers is the Helium MVE (M-Profile Vector Extension). Helium is purpose-built to accelerate the complex vector processing that post-quantum algorithms require.

NIST finalized the ML-KEM standard as FIPS 203 in August 2024. That gave silicon vendors and compiler engineers a stable cryptographic target. No one wants to commit to silicon or deep assembly optimization if the underlying algorithm might change.

To actually use that hardware efficiency we are seeing fascinating work on the software side. The SLOTHY superoptimizer is a massive step forward for embedded developers. SLOTHY uses a constraint solver called Google OR-Tools CP-SAT to automatically discover mathematically optimal instruction scheduling and register allocation. It transforms clean assembly code into highly optimized routines tailored for specific microarchitectures.

For ML-KEM this means drastically accelerating the Number Theoretic Transform (NTT) which is the most computationally expensive part of the algorithm. By perfectly scheduling 128-bit vector instructions for the Cortex-M85 pipeline the cryptographic compute time drops to under one millisecond.

Implementing hybrid TLS 1.3 at the edge

Compute speed is only half the architecture. The network layer is where things get complicated. A recent April 2026 preprint introduced the Hybrid Quantum-Resistant Resumption for TLS 1.3 framework (HQRT). This framework embeds hybrid X25519 and ML-KEM-768 into TLS 1.3 session tickets.

The implementation data is compelling. Compared to classical 0-RTT resumption on IoT platforms the HQRT framework incurs only a 4 to 9 percent latency overhead. Maintaining sub-millisecond tail latencies means the cryptographic overhead is essentially invisible against standard network round-trip times. You can now build deterministic real-time industrial automation systems that are quantum-secure.

Major open-source repositories are already on board. Projects like pqmx (a modern fork of pqm4) and the mlkem-native C90 implementation have integrated Armv8.1-M backends. These production-ready integrations utilize the Helium MVE with assembly routines auto-generated by SLOTHY. It lowers the barrier to entry for teams building secure embedded systems.

The MTU fragmentation bottleneck

I always look for the catch when reviewing new performance metrics. While the silicon and software maturity is impressive we still have a massive network architecture problem.

The issue lies in the payload size. ML-KEM key shares are large. A single ML-KEM-768 key share is 1,184 bytes. When you add TLS record headers and standard TCP/IP overhead you frequently exceed the standard 1,500-byte Maximum Transmission Unit (MTU) limit found in most legacy infrastructure.

Exceeding the MTU guarantees IP fragmentation. In constrained IoT networks fragmentation leads to dropped packets and connection timeouts. A sub-millisecond compute time is useless if the network stack drops the handshake packet at the edge router.

We have solved the local compute problem for post-quantum edge devices. The Cortex-M85 and SLOTHY prove that lattice-based cryptography can run beautifully on microcontrollers. Now network engineers need to figure out how to handle the realities of post-quantum packet sizes across legacy infrastructure.

References

• https://expiring.at/blog/optimizing-tls-handshakes-and-certificate-chains-for-maximum-performance/
• https://www.techinsights.com/blog/stm32v8-bridges-mpu-gap-18nm-fd-soi-pcm
• https://github.com/slothy-optimizer/pqmx
• https://www.allaboutcircuits.com/news/stmicro-unveils-first-18-nm-mcu-for-high-performance-designs/
• https://slothy-optimizer.github.io/slothy/
• https://quantumsecuritydefence.com/quantum-news/tls-handshake-performance-pqc-real-world/
• https://www.preprints.org/frontend/manuscript/a9167e30bc5c6f5d6f3f18ef604b4d3c/download_pub
• https://blog.st.com/embedded-world-2026/
• https://github.com/pq-code-package/mlkem-native
• https://dev.to/kevinzhang109/stm32v8-a-new-era-of-high-performance-mcus-built-on-18nm-and-cortex-m85-15bm
• https://sigdelsushil.com.np/blog/the-fragmented-reality-of-post-quantum-cryptography-why-ml-kem-is-breaking-real-world-networks-in-2026.html
• https://www.researchgate.net/publication/403032967_Benchmarking_Post-Quantum_Cryptography_on_Resource-Constrained_IoT_Devices_ML-KEM_and_ML-DSA_on_ARM_Cortex-M0
• https://blog.st.com/stm32v8/