What is the HQC backup algorithm for ML-KEM?

The HQC backup algorithm for ML-KEM is Hamming Quasi-Cyclic (HQC), a code-based key encapsulation mechanism that NIST selected in March 2025 as a second post-quantum option for key establishment. ML-KEM rests on lattice problems. HQC rests on error-correcting codes, so if ML-KEM is ever weakened, encrypted connections can switch to a KEM with completely separate mathematical foundations.

This matters for organisations that protect links between substations, plants, control rooms, cloud workloads and remote engineers. Those links often stay in service for ten years or more. Algorithm changes have to be planned, tested and rolled out without disrupting operations. The sections below cover what HQC is, where its standard stands, how its sizes affect tunnels, and what gateway designs should account for.

What is HQC and why did NIST select it as a backup for ML-KEM?

HQC is a key encapsulation mechanism (KEM) based on coding theory. NIST chose it because it gives a fallback that does not depend on the lattice assumptions behind ML-KEM. In NIST’s own words, HQC is based on different math than ML-KEM, which could be important if a weakness were discovered in ML-KEM.

The selection closed the fourth round of the NIST post-quantum process. NIST advanced four KEM candidates to the fourth round for continued evaluation: BIKE, Classic McEliece, HQC, and SIKE. These algorithms were all based on different security assumptions than ML-KEM. In the end, the only key-establishment algorithm that will be standardized is HQC.

Why different mathematics matters

ML-KEM, specified in NIST FIPS 203, gets its security from the presumed hardness of certain computational problems in lattices. Lattice cryptography has been studied for decades, but post-quantum schemes in general are still young. In NIST IR 8545, NIST explains that it wants a choice of hardness assumptions to “reduce the risk that a single cryptanalytic breakthrough will leave no viable standard for key establishment.”

The fourth round itself showed how real that risk is. NIST IR 8545 records that SIKE, the sole isogeny-based candidate, was broken and thus does not satisfy IND-CCA2 security.

Why HQC rather than BIKE or Classic McEliece

BIKE was the closest rival, since it uses similar code-based assumptions. NIST favoured HQC mainly because its security analysis was more mature. Both schemes need a very low decryption failure rate to reach IND-CCA2 security, and NIST does not consider the DFR analysis for BIKE to be as mature as that for HQC. Overall, NIST determined that HQC would provide a good complement to ML-KEM, since it is based on a different underlying security problem and still retains reasonable performance characteristics for general applications.

HQC is still a backup, not a successor. Dustin Moody, who heads NIST’s Post-Quantum Cryptography project, said HQC is not intended to take the place of ML-KEM, which will remain the recommended choice for general encryption.

When will the FIPS 207 HQC standard be final?

NIST expects to publish the final HQC standard, NIST FIPS 207 (HQC-KEM), in 2027. A draft for public comment comes first. At its announcement, NIST said it plans to release a draft standard built around HQC for public comment in about a year. Following a 90-day comment period, NIST will address the comments and finalize the standard for release in 2027.

Key milestones so far:

• 13 August 2024: NIST published FIPS 203 (ML-KEM), along with FIPS 204 and FIPS 205.
• 11 March 2025: HQC was selected for standardization, and NIST IR 8545 was released alongside the decision.
• September 2025: At the Sixth PQC Standardization Conference, NIST’s Angela Robinson presented FIPS 207: HQC-KEM, covering plans to convert HQC into FIPS format and possible changes to the Round 4 specification.
• 18 September 2025: NIST published SP 800-227, its general recommendations for implementing and using KEMs. These apply to ML-KEM now and will apply to HQC once it is standardised.

A 2025 NIST roadmap presentation by Dustin Moody listed FIPS 207 - in 2026 as a next step for the draft. Check the NIST CSRC publications page for the current status before you write it into procurement or migration plans.

How do HQC key and ciphertext sizes compare to ML-KEM for VPN tunnels?

HQC keys and ciphertexts are several times larger than ML-KEM’s at the same security category, but its computation costs are in the same range. For tunnels, this means more handshake bytes and more fragmentation, while CPU load stays about the same.

At category 1, HQC’s public key is almost three times as large as ML-KEM’s, and its ciphertext is nearly six times as large. NIST’s own slides put it this way: HQC has a larger public key and a significantly larger ciphertext than the alternatives with smaller bandwidth.

Computation is a different story. In the same NIST benchmark, HQC-128 needed 87, 204 and 362 kilocycles for key generation, encapsulation and decapsulation, against 123, 155 and 289 for Kyber-512. That gap is too small to matter on gateway-class x86 hardware.

What the sizes mean for site-to-site and OT links

An HQC-192 or HQC-256 ciphertext is several times larger than a standard 1,500-byte Ethernet MTU. The key exchange therefore always spans multiple packets. In IKEv2, this is handled by the IKE_INTERMEDIATE exchange (RFC 9242) and multiple key exchanges (RFC 9370). Other tunnel protocols need their own message fragmentation.

Real-world tests in NIST IR 8545 point the same way. When network conditions (e.g., transmission rates and packet loss) are ignored or sufficiently good, HQC results in faster handshakes. In contrast, when network conditions are sufficiently bad, BIKE outperforms HQC. For fibre between data centres, HQC’s size is a non-issue. For a pumping station on a cellular backhaul, or a remote substation on a radio link, every extra fragment raises the chance that a handshake has to be retransmitted.

Rekey frequency adds to this. A gateway that renews its post-quantum handshake every few minutes sends tens of kilobytes per tunnel each time under HQC-256. That is negligible on a gigabit link but worth measuring on links where bandwidth is metered or scarce. The IETF document draft-ietf-pquip-pqc-engineers, since published as RFC 9958, is useful background here: it provides insights into expected key, ciphertext, and signature sizes and processing time differences between PQC and traditional algorithms.

Should encryption gateways be able to switch from ML-KEM to HQC?

Yes. Any gateway that will stay in service past 2027 should be able to change its post-quantum KEM through a software update, without new hardware or a redesign of the network. NIST picked HQC precisely so that a switch would be possible. A gateway that cannot make the switch leaves that option unused.

In practice, being able to switch involves more than including an HQC library. When assessing gateways, look for:

• Negotiable KEM selection: both ends agree on the KEM per tunnel, so sites can be migrated one by one instead of in a single cutover.
• Handling of large messages: the handshake has to carry a 14 KB ciphertext reliably, including over links with packet loss.
• Signed, controllable updates: in OT environments, algorithm updates need to go through change management, and in air-gapped networks they must work offline.
• Hybrid combination that follows SP 800-227: the post-quantum secret should be combined with a classical one so that neither component alone decides the session’s security.

As one example, Quantum Network’s Quantum Gateway uses a hybrid key agreement that combines a classical part with ML-KEM (FIPS 203) into a single session key. Its post-quantum algorithm can be changed if needed, and automatic algorithm updates require an active subscription.

What happens to quantum-safe tunnels if a weakness is found in ML-KEM?

What happens depends on whether the tunnel uses a hybrid key exchange and how fast its KEM can be replaced. With a hybrid design, the tunnel stays protected against classical attackers. Post-quantum protection for new sessions returns only once the post-quantum component has been swapped out.

Switching does not fix one thing: traffic that was recorded while ML-KEM was in use. Frequent rekeying limits how much data each session key protects, but if the KEM itself is weak, recorded handshakes from that period depend only on their classical component. For data that must stay confidential for a long time, such as grid topology, process recipes or safety system configurations, this exposure window is the real reason to plan for agility now rather than after an advisory comes out.

How can OT operators prepare for a possible ML-KEM to HQC switch?

Start with an inventory of your links and their constraints, not with algorithms. For each connection between sites, to the cloud and for remote users, note the bandwidth, packet loss, MTU, rekey interval and how long the data needs to stay confidential. This tells you which links will handle HQC easily and which need testing first.

Then set your upgrade route. In segmented OT networks, the gateway often sits right next to the firewall, so the deciding factors are whether updates can be staged, approved and applied (including offline) and whether rollback is possible. Hybrid tunnels based on FIPS 203 can be deployed now, and FIPS 207 can be followed in parallel. Where the gateway design allows it, run lab trials of HQC once the draft standard is available.

Finally, keep reading the primary sources. NIST IR 8545 explains the reasoning behind the backup choice, NIST SP 800-227 covers how to use KEMs securely, and the final FIPS 207 text will set the parameters your gateways need to support.