Hybrid vs pure ML-KEM: which do EU and US agencies require?

Hybrid vs pure ML-KEM is the choice between two ways of setting up a session key. In hybrid mode, ML-KEM (the post-quantum key encapsulation mechanism standardised in NIST FIPS 203) is combined with a classical key exchange such as ECDH. In pure mode, ML-KEM is used on its own. Both protect against future quantum decryption. They differ in how they handle the risk that the new algorithm or its implementation has weaknesses.

For operators of OT and critical infrastructure, this is a practical decision and not only a theoretical one. Links between substations, plants, control centres, cloud environments and remote engineers often carry data that stays sensitive for years. That makes the key exchange the most urgent part to fix: traffic recorded today can be decrypted later if the key exchange was quantum-vulnerable. The difficulty is that European and US agencies point in different directions on how ML-KEM should be deployed.

Do European cybersecurity agencies require post-quantum algorithms to be used only in hybrid mode?

In practice, yes. BSI, ANSSI and the Netherlands National Communications Security Agency (NLNCSA) all treat hybrid key establishment as the expected form of post-quantum deployment during the transition. None of them currently endorses ML-KEM as a standalone replacement for classical key exchange.

Germany: BSI TR-02102

The BSI technical guideline BSI TR-02102-1 recommends post-quantum key establishment only in combination with a classical scheme. Its recommended KEMs are ML-KEM-768 and ML-KEM-1024, with FrodoKEM and Classic McEliece as more conservative options. The reason BSI gives is maturity: hybrid schemes compensate for a possible lack of confidence in the security of the newer algorithms. A paper submitted to NIST’s 2025 KEM guidance workshop summarised the German position as “PQC only in hybrid solutions”.

France: ANSSI

ANSSI is the most explicit of the three. Its transition paper describes three phases and states that “the role of hybridation in the cryptographic security is crucial and will be mandatory for phases 1 and 2.” ANSSI also says it will not endorse direct drop-in replacement of current algorithms in the short to medium term. It adds that the hybrid construction itself must be implemented securely, a point that is easy to overlook.

The Netherlands: NLNCSA and the joint statement

The NLNCSA, which evaluates encryption products for Dutch classified government use, signed a joint statement with ANSSI, BSI and the Swedish National Communications Security Authority. That statement says that “the clear priority should therefore be the migration to post-quantum cryptography in hybrid solutions.” The NCSC-NL, which advises the wider Dutch economy, also recommends hybrid solutions in its migration guidance.

Does CNSA 2.0 allow standalone ML-KEM-1024 without a classical key exchange?

Yes. NSA CNSA 2.0 names ML-KEM-1024 as its key establishment algorithm, and its end state is ML-KEM-1024 with no classical component. It does not require hybrid, but it tolerates hybrid constructions during the transition.

You can see this in the IETF profiles NSA is writing for specific protocols. The CNSA 2.0 TLS profile requires ML-KEM-1024 as a standalone group, and a CNSA server must reject any other key exchange the client offers. The IPsec profile works differently. It allows a classical exchange (384-bit ECP or large MODP groups) in IKE_SA_INIT, followed by ML-KEM-1024 in an IKE_INTERMEDIATE exchange. The draft explains why: putting ML-KEM-1024 in the first message would exceed the typical path MTU and force IP fragmentation. In effect, the CNSA IPsec profile is a hybrid.

For SSH, the IETF hybrid ML-KEM draft describes a hybrid of ML-KEM-1024 and NIST P-384 that is CNSA 2.0 compliant until a set date.

CNSA 2.0 milestone: ML-KEM-1024 support is required from 2025, and the key exchange must use it without any classical algorithm from 2033 (IETF draft-ietf-sshm-mlkem-hybrid-kex-03, 2025).

Two limits matter. First, CNSA 2.0 applies to US national security systems. Most commercial OT operators in the US follow NIST guidance instead, unless they supply or operate such systems. Second, CNSA accepts only one parameter set: ML-KEM-768 does not qualify, even though BSI does recommend it.

Is hybrid key exchange safer than pure ML-KEM if ML-KEM implementations have bugs?

Yes, for the failures that hybrid is designed to cover. If the ML-KEM implementation leaks its secrets or turns out to be flawed, a correctly built hybrid still offers the security of the classical exchange, so the session is no weaker than it is today.

This risk has already shown up in real code. KyberSlash exposed secret-dependent division timings in widely used Kyber implementations, the reference code among them. The NIST workshop paper cited above argues that deprecation deadlines push industry to use the very first ML-KEM implementations in production, and that doing so without hybrid creates unacceptable risks. An IETF draft makes a similar point: future implementation issues are more likely to weaken security than to break it completely, and a hybrid approach can offset that weakening.

Hybrid does not cover everything, and operators should know where its protection ends:

• Shared failure points: a weak random number generator, a flawed key derivation step or a bad combiner affects both halves at once.
• Downgrade paths: if a peer can negotiate the classical part alone, the post-quantum protection disappears. Hybrid only helps when both components are mandatory.
• The long-term quantum case: if ML-KEM is broken and a cryptographically relevant quantum computer also exists, both halves fail. Hybrid protects against an ML-KEM weakness under today’s threat model, not against both failures at once.

In practice, this means asking which implementation is used, whether it is constant-time and validated, and how the two shared secrets are combined. Asking only “hybrid or not” is not enough.

Which hybrid or pure ML-KEM mode should an organization choose if it operates sites in both the EU and the US?

Default to hybrid key exchange with ML-KEM-1024 plus a classical exchange of comparable strength (such as ECDH on P-384) on every link. Keep the ability to switch individual links to standalone ML-KEM-1024 when a US requirement calls for it.

Choosing ML-KEM-1024 instead of ML-KEM-768 is the step that makes a single configuration work in both regions, because it is the only parameter set that both BSI and CNSA 2.0 accept. The cost is larger keys and ciphertexts. On links with small MTUs, such as some cellular backhaul and older WAN segments, this can cause fragmentation, which is the same issue NSA’s IPsec profile works around.

Make the decision per link, not per organisation. A transatlantic tunnel between an EU control centre and a US plant is the case where both rule sets apply at once. A link that falls under CNSA 2.0 as a national security system has its own schedule and may need standalone ML-KEM-1024 earlier than the rest of the network.

When will agencies stop requiring hybrid mode and allow pure post-quantum key exchange?

No European agency has set a firm date to end its hybrid recommendation. The indicative horizon is around 2030 for ANSSI. For US national security systems, the move to standalone ML-KEM-1024 is scheduled.

NIST transition: NIST intends to deprecate and ultimately remove quantum-vulnerable algorithms from its standards by 2035, with high-risk systems moving much earlier (NIST CSRC, 2026). The IR 8547 document was still marked as an initial public draft in mid-2026, so check its dates again before relying on them.

Other agencies point the same way. Spain’s CCN expects a possible switch to standalone schemes after 2030. The UK NCSC describes hybrid as a temporary solution and says systems should be able to move to standalone post-quantum cryptography. BSI has not published an end date. In practice, the end of hybrid will depend on cryptanalytic confidence in ML-KEM, not on a calendar date. Organisations should therefore plan for a later configuration change, not a one-time choice.

How should OT operators prepare site, cloud and remote access links for either mode?

Build crypto agility into the encryption layer now, so that moving from hybrid to pure ML-KEM, or to a different post-quantum algorithm, is a configuration and update task rather than a hardware replacement.

OT makes this harder in specific ways. PLCs, RTUs and protection relays rarely support modern key exchange and are replaced on decade-long cycles. That is why many operators put the post-quantum key exchange in network gateways at Layer 3 instead of in the field devices. The questions to ask about any gateway, client or cloud endpoint are concrete:

• Which ML-KEM parameter set does it use, and can it be set to ML-KEM-1024?
• Which classical component is combined with it, and how are the two secrets merged into one session key?
• Can standalone ML-KEM be enabled per tunnel without affecting other links?
• How do algorithm updates reach sites that are air-gapped or have no cloud connectivity?
• Does the connection refuse to fall back to classical-only or unencrypted traffic when negotiation fails?

Products built along these lines already exist. Quantum Network’s QPN gateway, for example, uses a hybrid key agreement that combines a classical part and ML-KEM into one session key, renews both handshakes every two minutes, and allows the post-quantum algorithm to be changed if necessary. Whatever you deploy, record each link’s mode, parameter set and governing framework in your cryptographic inventory. When BSI, ANSSI or the NSA change their position, that inventory tells you which links have to change.