ML-KEM-768 vs ML-KEM-1024: which level for OT networks?

ML-KEM is the post-quantum key-encapsulation mechanism that NIST standardised in FIPS 203. It comes in three parameter sets: ML-KEM-512, ML-KEM-768 and ML-KEM-1024. They trade security strength against key size and speed. Choosing between ML-KEM-768 and ML-KEM-1024 sets how much margin your encrypted links get against future quantum attacks.

For organisations running operational technology (OT), this choice matters more than usual. Links between substations, pumping stations, plants, cloud environments and remote engineers often carry data that has to stay confidential for decades. The same networks may also have tight MTU limits or rely on older WAN paths. This article compares the parameter sets, explains the regulatory drivers and gives a practical way to decide.

What is the difference between ML-KEM-512, ML-KEM-768 and ML-KEM-1024?

The three sets differ in security category, key size and ciphertext size. ML-KEM-512 is claimed to be in security category 1, ML-KEM-768 in security category 3, and ML-KEM-1024 in security category 5.

NIST defines its security categories by comparison with symmetric ciphers. These levels correspond to the hardness of breaking AES-128, AES-192 and AES-256 respectively. All three sets use the same lattice construction and the same polynomial ring. The main structural difference is the module rank: 2, 3 or 4. That rank drives both the security margin and the message sizes.

Source: NIST FIPS 203, Tables 1 and 3 (August 2024).

Every set produces the same output. All variants produce a 32-byte shared secret. The session keys derived from that secret are therefore the same length whichever set you pick. What changes is how hard it is to recover the secret from the public handshake.

On the default choice, NIST is explicit: “NIST recommends using ML-KEM-768 as the default parameter set, as it provides a large security margin at a reasonable performance cost.”

How much more bandwidth and processing does ML-KEM-1024 need?

ML-KEM-1024 adds about 864 bytes per key exchange compared with ML-KEM-768, and the extra computing cost is small. The real operational issue is packet fragmentation, not CPU load.

Bytes on the wire

In one key exchange, one side sends an encapsulation key and the other sends back a ciphertext. Using the FIPS 203 sizes:

• ML-KEM-768: 1,184 + 1,088 = 2,272 bytes per exchange.
• ML-KEM-1024: 1,568 + 1,568 = 3,136 bytes per exchange.
• Difference: +864 bytes, about 38% more (calculated from FIPS 203 Table 3, 2024).

This overhead only applies when keys are set up or renewed. User data is protected by a symmetric cipher, so throughput after the handshake is the same at every ML-KEM level. On a site-to-site tunnel that renews keys every few minutes, an extra 864 bytes per renewal is negligible, even on a narrowband telemetry link.

Fragmentation and MTU

Message size matters more when a single key-exchange message no longer fits in one packet. This is common on OT paths that run over cellular, satellite or nested tunnels with a reduced MTU. The IETF draft on ML-KEM in IKEv2 notes that since the ML-KEM-768 and ML-KEM-1024 public key and ciphertext sizes can exceed the typical network MTU, these key exchanges could require two or three network IP packets from both the initiator and the responder.

The NSA’s IPsec profile for CNSA 2.0 is even more direct. It warns that if ML-KEM-1024 were used in the IKE_SA_INIT exchange, the sizes of its public key and ciphertext would cause the initiator and responder messages to exceed the typical path MTU and necessitate IP-level fragmentation. For that reason it requires that the additional key exchange performed in IKE_INTERMEDIATE MUST be ML-KEM-1024.

Processing

Computation scales with the module rank, but in a hybrid handshake the classical half usually dominates. In a 2024 TLS 1.3 benchmark with P-384 as the classical component, hybrid handshakes reached 375.19 connections per second with ML-KEM-768 and 369.84 with ML-KEM-1024 on AVX2. That is about 1.4% fewer (arXiv 2404.13544, 2024). The same authors found that handshake time in hybrid mode is primarily composed of two components: ECDH and ML-KEM, so solely improving ML-KEM performance is insufficient.

For gateways on standard server hardware, the difference between ML-KEM-768 and ML-KEM-1024 rarely limits capacity. Constrained field devices and microcontrollers are a different case and should be benchmarked separately.

Why does CNSA 2.0 require ML-KEM-1024?

NSA’s Commercial National Security Algorithm Suite 2.0 aims for one uniform, top-level strength: AES-256, SHA-384 or SHA-512, and the category 5 versions of the new post-quantum algorithms. ML-KEM-1024 is the only ML-KEM set that matches AES-256.

The suite is defined as a set: ML-DSA-87 and ML-KEM-1024 together with SHA384, SHA512, AES-256, LMS, and XMSS comprise the CNSA Suite 2.0. The NSA-authored TLS profile states plainly that “CNSA 2.0 requires the use of ML-KEM-1024 for key establishment in TLS.” It also excludes lower levels: any algorithm other than ML-KEM-1024 offered by the client MUST NOT be accepted by a CNSA TLS server establishing a CNSA-compliant connection.

The reasoning is consistency across the stack. If the session cipher is AES-256, a category 3 key exchange would become the weakest link. CNSA 2.0 also sets a timeline: CNSA 2.0 requires support for ML-KEM-1024 in 2025 and makes it mandatory without any classical algorithm in the key exchange in 2033.

CNSA 2.0 formally applies to US national security systems and their suppliers. Even so, many European utilities, defence suppliers and operators of shared infrastructure use it as a reference for the most demanding tier, especially when they exchange data with US partners.

Do national agencies such as BSI and ANSSI recommend a minimum ML-KEM level?

BSI and ANSSI both recommend ML-KEM in hybrid combination with classical algorithms. However, unlike the NSA, they do not impose one mandatory parameter set as strictly. Before you set a minimum, check the current edition of each document.

A 2026 comparison of national post-quantum policies found that Australia, India, and the United States of America (USA) explicitly prefer higher security levels (e.g., ML-KEM-1024), Canada permits a broader range of parameters, and France and Germany leave parameter selection largely unspecified. The same study notes that France and Germany additionally reference alternative KEMs such as Frodo-KEM or Classic McEliece, and lists hybrid key establishment as “Recommended” for both countries.

In practice, BSI TR-02102 is the document German operators of critical infrastructure (KRITIS) are most likely to be checked against. ANSSI guidance plays a similar role for French operators of vital importance. Neither agency rules out ML-KEM-1024. If you choose category 5 in a hybrid construction, you stay on the conservative side of all European guidance and also meet the NSA’s requirement.

Which ML-KEM security level should critical infrastructure use?

For most OT and critical infrastructure links, ML-KEM-1024 in a hybrid key exchange is the safer default, provided your network paths handle the larger messages. ML-KEM-768 remains a sound choice where size limits or peer compatibility make category 5 impractical.

Factors that point to ML-KEM-1024

• Long confidentiality lifetime. Grid topology, process recipes, safety system configurations and asset inventories can stay sensitive for 20 years or more. Traffic recorded today keeps only the protection it had when it was sent.
• Long-lived tunnels. Site-to-site links handshake rarely compared with the volume of data they carry. The IKEv2 draft describes the higher ML-KEM sets as conservative security level parameters which will not have material performance impact on IKEv2/IPsec tunnels.
• Exposure to US national security requirements. Suppliers to defence or federal programmes will meet CNSA 2.0 eventually, so it is sensible to standardise early.
• Matching symmetric strength. If your data channel already uses 256-bit keys, category 5 key establishment keeps the design balanced.

Factors that point to ML-KEM-768

• Fragmentation-sensitive paths. Where intermediate devices drop fragments and the protocol cannot split the exchange cleanly, the smaller messages may be the difference between a working and a failing handshake.
• Interoperability. Some peers, cloud endpoints or remote access clients may only support the NIST default.
• Constrained endpoints. Embedded devices with little memory benefit from the smaller decapsulation key.

ML-KEM-512 is hard to justify for infrastructure links. Compared with ML-KEM-768 it saves only a few hundred bytes per exchange and gives up two security categories.

Choices that matter as much as the parameter set

The ML-KEM level is one decision among several. Hybrid construction protects you if a weakness is found in the lattice assumption. Frequent rekeying limits how much data a single key protects. Crypto agility, meaning the ability to change the post-quantum algorithm or parameter set on deployed equipment, lets you move from ML-KEM-768 to ML-KEM-1024 without replacing hardware. For example, Quantum Network’s QPN gateway combines a classical and a post-quantum ML-KEM part into one session key, renews both handshakes every two minutes, and allows the post-quantum algorithm to be changed if necessary.

A practical rollout order is to start with the links that carry the longest-lived data, usually connections between control centres and to backup or cloud environments. Next, verify MTU behaviour on each WAN path. After that, extend the same parameter set to remote access, so you keep one policy instead of a mix.