ML-KEM performance on embedded ARM devices: what to expect

ML-KEM performance on embedded ARM devices means three things: the processor cycles, memory and energy that the FIPS 203 key-encapsulation mechanism uses on microcontrollers such as the Cortex-M0+, M4 and M7, and on Cortex-A industrial gateways. On this class of hardware the arithmetic is cheap. The constraints that matter more are message size, key buffers and radio airtime.

This matters for OT and critical infrastructure because the cryptography between substations, pumping stations, wind parks and control centres often has to run on hardware bought ten or fifteen years ago. CISA’s Post-Quantum Considerations for Operational Technology advises OT vendors, owners and operators to plan for emerging CRQC capabilities and to use mitigations such as strong OT network segmentation, quantum-resistant algorithms where appropriate, and crypto-agility in applications and protocols. To plan well, you need to know what ML-KEM actually costs on that hardware.

How much CPU and memory does ML-KEM need on an ARM Cortex-M or embedded gateway?

A full ML-KEM-512 handshake takes roughly 2.2 million cycles on a Cortex-M4 and about twice that on a Cortex-M0+, which comes to tens of milliseconds at typical clock speeds. Memory use is set mostly by key and ciphertext buffers of 0.8 to 3.2 KB per parameter set, plus a working stack.

Cycle counts from the pqm4 benchmarking project

Most published embedded figures come from the pqm4 benchmarking project. Since the first NIST PQC call it has become the de facto standard evaluation platform for PQC implementations targeting the Arm Cortex-M4 microcontroller. pqm4 reports cycle counts for key generation, encapsulation and decapsulation separately, so you can add them up for a full handshake. In NIST’s words during standardisation, “The pqm4 benchmark results show that both KYBER and Saber are suitable for use on constrained devices” (NIST IR 8413). Kyber is the algorithm that became ML-KEM.

A 2026 study compared reference C code on a Cortex-M0+ against pqm4’s Cortex-M4 numbers. To keep the comparison fair, the M4 figures were measured by the pqm4 project on a board running at 24 MHz to avoid flash wait states.

The paper reports these figures in its table of ML-KEM-512 handshakes: 35.7 ms and 4,464 kilocycles on the M0+, against 17.5 ms and 2,185 kilocycles on the M4, a 2.04x slowdown. Assembly-optimised M4 implementations in pqm4 run faster than the reference C shown here, so treat these figures as an upper bound for planning.

Where the cycles go

ML-KEM’s arithmetic is a Number Theoretic Transform over small polynomials, but hashing takes a large share of the work. According to a paper at NIST’s Fifth PQC Standardization Conference (2024), for ML-KEM and ML-DSA about half of the cycles are typically spent on Keccak computation. In practice, a gateway or microcontroller with a SHA-3/Keccak engine gains much more than one with only an AES engine. That is worth checking when you compare hardware platforms.

Memory: plan for the buffers, not only the stack

pqm4 measures stack, but its figures exclude something important. All key material and messages need to be stored on the stack, but since those need to be allocated outside of the actual scheme, pqm4 does not include them in the stack usage. Your RAM budget therefore has to cover the decapsulation key, the encapsulation key, the ciphertext and the shared secret, on top of the published stack figure. For ML-KEM-512 the IETF security considerations draft lists an 800-byte public key, 1,632-byte secret key and 768-byte ciphertext, and for ML-KEM-768 1,184, 2,400 and 1,088 bytes respectively. That fits comfortably on a modern Cortex-M4 or M7. On an older part with tens of kilobytes of RAM already used by a protocol stack, it becomes a real constraint.

Is ML-KEM faster than ECDH on embedded processors?

In raw computation, yes, often by an order of magnitude on small cores. In bytes on the wire, no: ML-KEM messages are much larger than elliptic-curve public keys, and on slow links that can cancel out the CPU advantage.

On the same Cortex-M0+ used for the handshake figures above, the 2026 benchmark measured ECDH P-256 key agreement at 617.0 ms, against 35.7 ms for a full ML-KEM-512 handshake. Keep in mind that this compares one implementation of P-256 with reference ML-KEM. Optimised Curve25519 code narrows the gap, but the direction is consistent: lattice arithmetic is cheap for 32-bit cores without large multipliers.

Size works the other way. A paper submitted to NIST’s 2025 Workshop on Guidance for KEMs warns that using ML-KEM instead of ECDH would in many cases increase the number of bytes with several thousand percent on very constrained radio networks. The same paper adds that because of duty cycles, the increase in “time to completion” is often even larger.

Can older RTUs and industrial gateways handle post-quantum key exchange without hardware upgrades?

Many can, provided someone can deliver new firmware and the device has a few kilobytes of free RAM. Where neither is true, the practical route is to move the key exchange onto a separate network device in front of the RTU rather than replacing the RTU.

Three realistic situations

IEC 62443-4-2 matters here because it defines technical security requirements for individual IACS components, including embedded devices and network devices, and includes requirements on the use of cryptography. Whether a component can meet such requirements with a new algorithm depends on its product lifecycle, not just its processor. That ties in with CISA’s advice to apply quantum mitigation considerations to platform update schedules and upgrade lifecycles.

Moving the key exchange off the field device

For frozen devices, a common architecture puts a gateway at each end of the connection. The gateway carries out the post-quantum key exchange and encrypts traffic in transit, while the RTU keeps speaking its usual protocol. Quantum Network’s QPN is one example: a Layer 3 gateway, in hardware or software, with a hybrid key agreement that combines a classical part with ML-KEM into one session key. Both handshakes renew every two minutes, and no software is installed on the equipment behind it. It runs on industry-standard x86 hardware, so the ML-KEM work happens on the gateway rather than on the constrained device. What it protects is data in transit, not the devices behind the gateway.

How does post-quantum key exchange affect power consumption of battery or solar powered field devices?

The computation itself can use less energy than ECDH, but every extra byte the radio sends costs energy. For battery and solar devices, rekey frequency and radio airtime matter more than the choice of algorithm.

The 2026 Cortex-M0+ study turned its timings into energy using a datasheet power model. It estimated that a complete ML-KEM-512 key exchange costs 2.83 mJ against 48.9 mJ for a full ECDH P-256 key agreement (17x). The authors note that these are estimates from a datasheet power model, not measurements; the ratios hold under any constant-power assumption, the absolute values do not.

For a field device that wakes, transmits and sleeps, the more useful sum is: energy for computation (small with ML-KEM) plus energy for transmitting and receiving keys and ciphertexts (larger with ML-KEM) plus the time spent awake waiting for a peer’s reply. Three design choices reduce the total:

• Rekey less often on battery devices. Match the rekey interval to the duty cycle rather than to a schedule designed for mains-powered gateways.
• Let the stronger side generate keys. In a KEM, key generation and decapsulation fall on one party and encapsulation on the other. If the field device only encapsulates against a gateway’s encapsulation key, it skips key generation. It still has to receive the encapsulation key and transmit a ciphertext, though.
• Keep the key exchange off the radio hop where possible. If a solar-powered RTU connects to a nearby mains-powered gateway, putting the post-quantum exchange on the gateway’s backhaul link avoids kilobyte-scale handshakes over the constrained radio.

Which ML-KEM parameter set fits best on constrained OT hardware?

ML-KEM-768 is the sensible default for gateways and site-to-site links. ML-KEM-512 is a defensible choice for the most constrained devices and links. ML-KEM-1024 is usually reserved for cases where policy requires category 5 strength.

FIPS 203 lists the parameter sets in order of increasing security strength and decreasing performance: ML-KEM-512, ML-KEM-768 and ML-KEM-1024. It assigns ML-KEM-512 to security category 1, ML-KEM-768 to category 3 and ML-KEM-1024 to category 5.

Sources: sizes for ML-KEM-512 and ML-KEM-768 from the IETF ML-KEM security considerations draft (2025); ML-KEM-1024 from arXiv 2603.19340 (2026), which notes that public keys range from 800 to 1,568 bytes, and ciphertexts from 768 to 1,568 bytes.

A 2026 WAN migration framework puts the selection logic well: the choice should depend on the applicable standard, security policy, protocol profile and required protection period, and the largest parameter set is not automatically the best operational choice. In OT, the required protection period is often long, because process data, network topology and engineering files can stay sensitive for decades. That argues for ML-KEM-768 wherever the hardware and link allow it.

What should OT teams measure before rolling out ML-KEM on embedded hardware?

Measure the complete handshake on the actual hardware over the actual link, and record RAM headroom, time to completion and energy per rekey. Published cycle counts are a starting point, not a commissioning result.

• Peak RAM during a handshake, including key and ciphertext buffers that pqm4-style stack figures leave out.
• Handshake time over the field link, including fragmentation when a 1,088-byte ciphertext exceeds the link’s frame size.
• Interaction with control traffic. Check that a rekey does not delay polling cycles or trip watchdogs on the RTU.
• Crypto-agility. Confirm that the algorithm can be changed later through a supported update path, as the CISA OT guidance recommends.

The direction from public authorities is clear. As Mona Harrington, then acting Assistant Director of CISA’s National Risk Management Center, put it: “Critical infrastructure and government leaders must be proactive and begin preparing for the transition to post-quantum cryptography now.” For embedded ARM hardware, the benchmarks suggest that processor speed is rarely what holds you back. Memory, message size and the ability to update firmware are what need planning.