What if ML-KEM is broken? Impact on VPN and OT tunnels

“What if ML-KEM is broken” means asking what happens if someone finds a practical attack on the module-lattice key encapsulation mechanism standardized in FIPS 203. Tunnels that use ML-KEM on its own for key agreement would lose their quantum-resistant confidentiality. Hybrid tunnels would fall back to the strength of their classical component. The symmetric ciphers that encrypt the payload are not directly affected.

For organizations running operational technology (OT) and critical infrastructure, this question matters more than it does for typical office IT. Telemetry, control traffic and engineering data often stay sensitive for years, equipment stays in service for decades, and change windows at substations, pumping stations or production lines are rare. A cryptographic break is unlikely on any given day, but if you have no plan, it turns into a slow and risky scramble across dozens of sites.

What happens to VPN and site-to-site tunnels if ML-KEM is broken?

It depends on how the tunnel builds its session keys. Tunnels that use only ML-KEM lose confidentiality, both for live sessions and for any traffic recorded earlier. Hybrid tunnels stay protected by their classical key exchange, but lose their protection against future quantum computers.

A VPN or site-to-site tunnel has three separate cryptographic layers: key agreement (where ML-KEM sits), peer authentication (certificates or pre-shared keys) and payload encryption (an AEAD cipher). A break in ML-KEM hits only the first layer. That still matters a lot, because whoever can recover a session key can decrypt everything that key protected.

“Broken” can mean three different things

A mathematical break of the Module Learning With Errors problem would make every implementation unsafe and force you to switch algorithms. A parameter weakening might push you from ML-KEM-768 to ML-KEM-1024 without changing algorithm. An implementation flaw such as a timing side channel is fixed with a patch, and the algorithm stays in place. Your response plan should tell these three apart within hours, because each one leads to a very different amount of work.

There is precedent for new assumptions failing suddenly. NIST’s process started with 69 submissions, and Dustin Moody’s own overview notes that several algorithms were broken along the way. Most visibly, the polynomial-time break of SIKE, a fourth-round NIST candidate, by Castryck and Decru in 2022 showed that confidence in a scheme can disappear in a single paper.

Does hybrid key exchange still protect traffic if the post-quantum component fails?

Yes, provided both shared secrets are combined properly into one session key. In that case an attacker has to break both components, so a failure of ML-KEM leaves the classical part protecting the traffic.

This is exactly why hybrids exist. The IETF profile for ML-KEM in IKEv2 describes the hybrid approach as producing keys safe against cryptanalytically-relevant quantum computers and theoretical weaknesses in ML-KEM. European regulators have made it a requirement: a paper submitted to NIST’s 2025 KEM workshop notes that industry is moving to hybrids, aligning with ANSSI’s and BSI’s requirements that “Post-quantum algorithms must be hybridized”. In Germany that position is set out in BSI TR-02102.

Hybrid protection has limits, and you should be honest about them:

• The two-failure gap. If ML-KEM falls to classical cryptanalysis and a quantum computer later breaks ECDH, recorded hybrid traffic becomes readable. A hybrid buys you time to replace the post-quantum component. It does not make the tunnel safe forever.
• The combiner design. Both secrets have to feed one key derivation function. NIST warns in CSWP 39 that security analysis for a hybrid key-establishment algorithm can be more complicated than analysis of either of the algorithms on their own.
• Authentication is separate. A hybrid KEM protects confidentiality. Peer authentication has its own migration path and its own failure modes.

How fast can an organization switch encryption algorithms across all OT sites after a cryptographic break?

Where the algorithm is a configuration or software setting on centrally managed gateways, switching takes days. Where cryptography is built into field devices, firmware or long-certified systems, it takes months to years.

NIST’s crypto agility guidance states the stakes plainly: “In the worst case, a breakthrough cryptanalytic technique can indicate the need for an immediate algorithm transition.” In practice, five factors decide how fast you can switch in OT:

• Where the cryptography lives. CSWP 39 notes that in legacy systems, the absence of abstraction between cryptographic operations and core system logic hampers the ability to support crypto agility. It suggests a dedicated “crypto gateway” or “bump-in-the-wire” so that the algorithm can be changed in one place.
• Both ends must change together. A tunnel only works if both peers support the new algorithm, so you need either a coordinated cut-over or a period where both algorithms are negotiable.
• Packet size. The backup algorithm has larger messages. At NIST security category 1, HQC’s public key is 2,249 bytes and its ciphertext 4,497 bytes, against 800 and 768 bytes for Kyber-512. Even ML-KEM can be a tight fit: ML-KEM-768 and ML-KEM-1024 public keys and ciphertexts may make UDP packet sizes larger than typical network MTUs (1500 bytes). Test this over satellite, cellular and radio links before you need it.
• Air-gapped and remote sites. Updates arrive on physical media through a controlled process, often during scheduled maintenance.
• Supply-chain readiness. Your vendors need to ship validated code for the replacement algorithm. CSWP 39 notes that supply chains depend on the maturity of standards, protocols, and the cryptographic validation program.

Gateway-based designs move the change to a small number of boxes. Quantum Network’s Quantum Gateway, for example, combines a classical and a post-quantum part (ML-KEM in the standard product) into one session key, renews both handshakes every two minutes, and lets you change the post-quantum algorithm if needed. Automatic algorithm updates require an active subscription, and the gateway also supports air-gapped networks. Whatever architecture you use, measure your real switch time in an exercise. Don’t assume it.

What should a cryptographic incident response plan for network encryption include?

The plan needs a trigger definition, a per-tunnel cryptographic inventory, a pre-tested replacement configuration, a rollout order based on how long data stays sensitive, and an exposure assessment for traffic that may already have been recorded.

The inventory is the part most often missing. CSWP 39 describes a cryptographic architecture that helps an organization decide whether to replace or upgrade cryptographic algorithms in a timely manner when new vulnerabilities or threats emerge. Without one, the first days after a break go into finding where ML-KEM actually runs.

How do national agencies announce and handle a broken or deprecated cryptographic algorithm?

Agencies use formal status labels and publish updated guidance documents. A sudden break usually shows up first in research and on public mailing lists, and formal deprecation follows. Neither NIST, BSI nor CISA can force a same-day change across private infrastructure.

NIST

NIST uses the SP 800-131A vocabulary. Deprecated means that the algorithm and key length/strength may be used, but there is some security risk, while disallowed means that the algorithm, key length/strength, parameter set, or scheme is no longer allowed for the stated purpose. NIST IR 8547 applies these labels to the quantum transition: 112-bit security strength, deprecated after 2030, disallowed after 2035. For a planned backup, NIST has chosen a new algorithm for post-quantum encryption called HQC, which will serve as a backup for ML-KEM. Of the fourth-round candidates, the only key-establishment algorithm that will be standardized is HQC, and it is being developed as FIPS 207: HQC-KEM. NIST expects a finalized standard expected in 2027.

Moody explained the reasoning: NIST selected HQC because “we want to have a backup standard that is based on a different math approach than ML-KEM.” NIST also revises its guidance as it goes. CSWP 39 was withdrawn on June 29, 2026 and superseded by CSWP 39upd1, so check that you are using the current version.

BSI and CISA

BSI updates TR-02102 regularly, setting out recommended mechanisms and how long they are expected to remain suitable. In early 2025, a contributor to an IETF discussion noted that ANSSI, BSI, and Swedish NCSA have all just recently added ML-KEM to their list of recommended algorithms. CISA does not set cryptographic standards. It publishes advisories, coordinates with NIST and other agencies, and issues migration guidance aimed at critical infrastructure operators.