Hybrid post quantum key exchange is a key-agreement method in which two endpoints run a classical algorithm, such as elliptic-curve Diffie-Hellman, and a post-quantum algorithm, such as ML-KEM, side by side, then combine both results into one session key. The connection stays confidential as long as at least one of the two parts remains unbroken.
For operators of OT and critical infrastructure, this is not an abstract question. Links between substations, pumping stations, control rooms, cloud historians and remote engineers carry data whose value lasts for years: network topologies, setpoints, maintenance schedules and process recipes. Traffic captured today could be decrypted later once a capable quantum computer exists. Hybrid key exchange is the most widely recommended way to close that window without betting everything on a single, still young, algorithm.
What is hybrid key exchange?
Hybrid key exchange runs two independent key agreements in the same handshake and feeds both shared secrets into a key derivation function to produce one session key. An eavesdropper would have to break both algorithms to recover that key.
How two secrets become one key
In a typical design, each side performs a classical exchange (for example X25519 or ECDH on a NIST curve) and a post-quantum key encapsulation. The two resulting secrets are concatenated, usually together with handshake context, and passed through a key derivation function. The output becomes the symmetric key that encrypts the actual traffic. This combiner step matters: a poorly designed combiner can weaken the result, so it should follow published constructions rather than an improvised mix.
Standard protocols already support this pattern. For IPsec, RFC 9370 defines multiple key exchanges in the Internet Key Exchange protocol version 2 (IKEv2), which allows a post-quantum exchange to run next to the classical one.
Where it applies in OT networks
Three connection types benefit most: site-to-site links between plants or field locations, edge-to-cloud links that carry telemetry to a historian or analytics platform, and remote access for engineers and vendors. All three typically cross networks the operator does not control, including the public internet, which is exactly where traffic can be recorded at scale.
Why combine classical and post-quantum algorithms?
Classical algorithms are well understood but will fall to a large quantum computer, while post-quantum algorithms resist quantum attacks but have a much shorter track record. Combining them means a flaw in either one alone does not expose the session key.
Shor’s algorithm and Diffie-Hellman
Shor’s algorithm, published by Peter Shor in 1994, solves integer factorisation and discrete logarithms efficiently on a quantum computer. That breaks RSA, finite-field Diffie-Hellman and elliptic-curve Diffie-Hellman, the foundations of almost every VPN and TLS handshake in use today. The required machine does not exist yet, and estimates of its size vary.
- Resource estimate (2024): one published physical resource estimate for using Shor’s algorithm on RSA-2048 is 20 million physical qubits and 8 hours of runtime.
- Expert expectations (2024): the Global Risk Institute’s 2024 survey of 47 quantum computing experts puts the probability of cryptographically relevant quantum computers at 34% by 2034, double the 17% projected in the 2022 assessment.
For OT, the relevant question is not when such a machine appears but whether data sent today must stay secret beyond that point. Infrastructure assets run for decades, and an attacker who records traffic now only needs patience.
A hedge against new mathematics
Post-quantum algorithms rest on mathematical problems that have been studied for far less time than factoring. European agencies have been explicit about the consequence. Germany’s BSI recommended that “quantum computer-resistant methods should not be used alone” during a transitional period, but only in hybrid mode. In a joint position paper, ANSSI, BSI, the Netherlands NLNCSA and the Swedish National Communications Security Authority wrote that “the clear priority should therefore be the migration to post-quantum cryptography in hybrid solutions”.
| Approach | Protection against a future quantum computer | Protection if the PQ algorithm has a hidden flaw | Maturity |
|---|---|---|---|
| Classical only (ECDH, Diffie-Hellman) | None | Not applicable | Decades of analysis |
| Post-quantum only (ML-KEM) | Yes, as far as is known | None | Standardised in 2024 |
| Hybrid (ECDH + ML-KEM) | Yes, through ML-KEM | Yes, through the classical part | Combines both |
What is ML-KEM?
ML-KEM (Module-Lattice-Based Key-Encapsulation Mechanism) is the post-quantum key establishment algorithm that NIST standardised in FIPS 203. It lets two parties agree on a shared secret over a public channel in a way that is designed to resist quantum attacks.
FIPS 203 was published on 13 August 2024, and ML-KEM is the name given to the algorithm in this standard derived from CRYSTALS-KYBER. Its security is related to the computational difficulty of the Module Learning with Errors problem. The standard is the product of a long public process:
- Standardisation effort (2024): NIST describes its first finalised post-quantum standards as the result of an eight-year effort managed by NIST.
A KEM works differently from Diffie-Hellman. Instead of both sides contributing a public value, one side publishes an encapsulation key, the other uses it to encapsulate a random secret, and the first side decapsulates it. FIPS 203 defines three parameter sets, in order of increasing security strength and decreasing performance: ML-KEM-512, ML-KEM-768 and ML-KEM-1024. The shared secret is 32 bytes for all three parameter sets, which makes it straightforward to combine with a classical secret in a hybrid design.
Is ML-KEM safe to use today?
Yes, according to NIST and the major European agencies, provided it is implemented carefully and, during the transition, used in hybrid mode. NIST has stated that the algorithm is ready for production use.
The FIPS 203 abstract states: “At present, ML-KEM is believed to be secure, even against adversaries who possess a quantum computer.” When it published the standards, NIST said the algorithms are ready for immediate use, and encouraged computer system administrators to begin transitioning to the new standards as soon as possible.
What “safe” does and does not cover
The algorithm is one thing, the implementation another. NIST itself notes that conformance to the standard does not ensure that a particular implementation is secure. Constant-time code, sound randomness and correct key validation all matter. FIPS requires approved implementations to perform a pair-wise consistency test on each freshly generated keypair. NIST also maintains an errata list: a planning note dated 17 November 2025 flags an issue to be corrected in a future revision. Operators should therefore track updates rather than treat the standard as frozen.
NIST is also building in diversity. HQC, a non-lattice, code-based KEM, was selected for standardisation in March 2025 to complement ML-KEM. That is a strong argument for crypto agility: equipment should be able to swap its post-quantum algorithm without replacing hardware.
The regulatory clock
- NIST IR 8547 (draft November 2024): quantum-vulnerable algorithms at 112-bit security strength, including finite-field and elliptic-curve Diffie-Hellman, are deprecated after 2030 and disallowed after 2035.
- EU NIS Cooperation Group (2025): member states should draw up transition plans by the end of 2026, complete migration of high-risk systems by 2030, and migrate as many systems as possible by 2035.
How often should session keys be renewed?
No NIST standard fixes one universal interval: neither FIPS 203 nor NIST IR 8547 prescribes a rekey period. Good practice is to renew keys often enough that each key protects only a small slice of traffic, which on continuous OT links means minutes rather than hours or days.
Why short intervals help
Each rekey with fresh ephemeral values creates a new, independent session key. If one key were ever exposed, through a memory leak, an implementation bug or future cryptanalysis, only the traffic from that interval would be at risk. Short intervals also keep the volume of data under any single key far below the limits of the symmetric cipher and its nonce space. On OT links that run for months without interruption, a policy that only rekeys at connection setup can leave one key in use for a very long time.
Practical criteria for setting the interval
- Both halves, every time: renew the classical and the post-quantum exchange together. Refreshing only the classical half quietly removes the quantum protection from new keys.
- Time and volume triggers: rekey on whichever comes first, a fixed time or a data threshold, so high-throughput links do not exceed safe limits.
- Seamless rollover: new keys should take over without dropping packets. Control protocols such as Modbus/TCP or IEC 60870-5-104 react badly to short outages.
- Handshake cost: ML-KEM operations are fast, so frequent rekeying is affordable on current x86 gateways.
As an example of what this looks like in practice, the QPN gateway from Quantum Network combines a classical part and ML-KEM into one session key, renews both handshakes every two minutes, encrypts payload with ChaCha20-Poly1305 and checks every packet with a Poly1305 authentication tag.
How do you deploy hybrid key exchange in OT and critical infrastructure?
Start where data leaves your controlled perimeter: links between sites, to the cloud and to remote users. Encrypting at the network layer protects legacy devices that can never run post-quantum software themselves.
Decisions that matter in industrial networks
- Inventory first: list every link, the protocol it carries, and how long its data must stay confidential. Prioritise long-lived, sensitive flows.
- Encrypt at Layer 3: a gateway at each end of the link protects all traffic above it, including old PLCs, RTUs and HMIs that cannot be updated.
- Firewall ordering: if a firewall must keep inspecting traffic, the encryption point belongs on the outside of it, so inspection still sees cleartext.
- Fail closed: a quantum-safe link that silently falls back to plaintext or classical-only keys after an outage provides little real protection. Verify the behaviour during failover testing.
- Isolated networks: air-gapped and segmented sites need solutions without telemetry or cloud dependencies.
- Keep scope clear: encryption in transit is not a firewall, an anti-malware tool or a denial-of-service defence, and it does not protect the devices behind the gateway.
Some gateways are built around these constraints. QPN, for example, never falls back to unencrypted traffic, retries automatically after a line failure, sends no telemetry, and supports a change of post-quantum algorithm when necessary. That last capability matters because the post-quantum algorithm landscape is still developing.
Where Quantum Network fits
Quantum Network is a quantum-safe encryption gateway that protects the connections between your own locations, without replacing the network equipment you already run.