HQC: Why NIST Selected a Backup to ML-KEM

Quick answer: NIST selected HQC (Hamming Quasi-Cyclic) in March 2025 as a fifth post-quantum algorithm and a structural backup to ML-KEM. Where ML-KEM relies on lattice math, HQC relies on error-correcting codes, a completely different hardness assumption, so a future weakness in lattice cryptography would not compromise both at once. HQC is not a replacement for ML-KEM and is not finalized: NIST expects a draft standard roughly a year after selection and a final FIPS by 2027. Organizations should continue migrating to ML-KEM now and treat HQC as a future option to track, not a production algorithm to deploy today.

HQC’s selection made headlines for a week and then mostly disappeared from planning conversations, which is a mistake. It answers a real question enterprise architects should be asking: what happens if ML-KEM turns out to have a weakness nobody has found yet. HQC is NIST’s answer, and understanding why it exists, and why it is not ready for production, is worth more than the initial news cycle it got.

Key Takeaways

• NIST announced HQC’s selection on March 11, 2025, as a fifth post-quantum standard and a structurally independent backup to ML-KEM.
• HQC is code-based, relying on the hardness of decoding error-correcting codes, a fundamentally different mathematical problem than the lattice problems behind ML-KEM.
• NIST’s own guidance is explicit: HQC does not replace ML-KEM. ML-KEM remains the primary recommendation for general-purpose encryption.
• HQC is not yet standardized. A draft FIPS was expected roughly a year after the March 2025 selection, with a final standard targeted for 2027.
• Algorithm diversity, not any specific known weakness in ML-KEM, is the reason HQC exists. It is insurance, not a signal that ML-KEM is in trouble.

What Code-Based Cryptography Actually Is

ML-KEM, ML-DSA, and SLH-DSA cover two mathematical foundations between them: module lattices for the first two, hash functions for the third. HQC introduces a third foundation entirely: error-correcting codes.

Error-correcting codes were originally built to recover data corrupted by noise, the same technology behind reliable data transmission over unreliable channels. Code-based cryptography flips that purpose: it constructs a problem, recovering a message deliberately obscured by structured noise, that is easy to solve if you know the underlying code’s secret structure and computationally infeasible if you do not, even for a quantum computer. HQC specifically uses quasi-cyclic codes, a structured variant chosen for a practical balance of key size and performance compared to older code-based schemes like Classic McEliece, whose keys run into hundreds of kilobytes.

This foundation has actually existed longer than lattice cryptography. McEliece’s original code-based cryptosystem dates to 1978, decades of scrutiny that lattice-based schemes like ML-KEM, by comparison, have not yet accumulated to the same degree.

See how HSM-as-a-Service supports ML-KEM key establishment today.

Why Algorithm Diversity Matters Here

NIST’s own framing for HQC’s selection is worth quoting directly in substance: the agency wanted a backup standard based on a different mathematical approach than ML-KEM specifically so that a future weakness in lattice cryptography would not leave organizations with no quantum-resistant key establishment option at all. This is the same logic behind maintaining both ML-DSA and SLH-DSA for signatures, lattice math and hash functions as independent fallbacks for each other.

It is worth being precise about what this is not: it is not a response to any discovered vulnerability in ML-KEM. ML-KEM remains NIST’s primary recommendation, and nothing about HQC’s selection changes that. Diversity is a hedge against an unknown future weakness, not a response to a known present one, and conflating the two leads to unnecessary anxiety about ML-KEM’s current security.

Where HQC Fits Once It Standardizes

HQC’s future role is narrow and specific: a fallback KEM for key establishment, activated in the event ML-KEM’s lattice-based security assumption is meaningfully weakened by future cryptanalysis. It is not designed to run as a default, not intended to replace ML-KEM in new deployments, and not expected to see broad production use unless that fallback scenario actually materializes. Organizations building crypto-agile systems should design for the ability to swap in HQC later, the same discipline that makes any future algorithm transition a configuration change rather than a rebuild, without treating HQC itself as something to implement now.

Why Enterprises Should Avoid Premature Production Use

Three reasons argue against deploying HQC in production before it standardizes:

• The specification is not final: Parameter sets, encodings, and implementation details can still change before a final FIPS is published, and building against a moving target risks rework.
• Library and platform support does not exist yet in any mature form: Unlike ML-KEM, which has broad TLS and browser support today, HQC implementations are early and not validated through NIST’s Cryptographic Module Validation Program.
• It solves a problem that has not occurred: ML-KEM has no known practical weakness. Spending migration budget and engineering time on HQC today diverts resources from the FIPS 203, 204, and 205 migration work that carries real, dated regulatory deadlines.

What We’d Actually Recommend

Continue migrating to ML-KEM as planned; nothing about HQC’s selection changes that priority. Track HQC’s standardization progress toward its expected 2027 finalization, and factor it into long-term crypto-agility planning as a future option rather than a current requirement. Build systems with the algorithm abstraction that would let HQC be added later without a redesign, the same crypto-agility discipline that pays off regardless of which specific algorithm eventually needs to change.

How Encryption Consulting Can Help

ML-KEM key establishment today runs through HSM-as-a-Service, FIPS-validated key management that will extend to HQC the same way once it standardizes, so the eventual “add HQC as a fallback” step is a configuration change on infrastructure you already run, not a new hardware deployment.

Our PQC Advisory Services build crypto-agility into migration roadmaps from the start, exactly the discipline that turns “add HQC as a fallback in 2027” into a configuration change rather than a project.

Insurance, Not an Alternative

HQC exists because NIST wants a fallback that does not share ML-KEM’s mathematical foundation, not because ML-KEM has shown any sign of weakness. That distinction matters for how organizations should treat it today: worth tracking as it moves toward a 2027 standard, worth designing crypto-agile systems that could adopt it later, and not worth deploying in production before it is finalized. The migration priority remains exactly where it was before HQC’s selection, ML-KEM, ML-DSA, and SLH-DSA, with HQC filed away as a well-reasoned insurance policy for a scenario that has not happened.

Frequently Asked Questions

Should we switch from ML-KEM to HQC?

No. NIST is explicit that ML-KEM remains the primary recommendation for general-purpose encryption. HQC is a backup, not a replacement, and is not yet standardized regardless.

Is HQC’s selection a sign that ML-KEM has a security problem?

No. HQC was selected to provide mathematical diversity as a hedge against a hypothetical future weakness, not in response to any discovered vulnerability in ML-KEM. ML-KEM has no known practical weakness as of this guide’s publication.

When will HQC be finalized as a standard?

NIST selected HQC in March 2025 and expected to release a draft standard roughly a year later, with a final FIPS targeted for 2027. Until finalized, its specification can still change.

How is HQC mathematically different from ML-KEM?

ML-KEM relies on the hardness of lattice problems, specifically Module Learning With Errors. HQC relies on the hardness of decoding structured error-correcting codes, an entirely different mathematical foundation with a longer research history dating back to the 1970s.

Should organizations wait for HQC before starting PQC migration?

No. Waiting would mean delaying migration to ML-KEM, ML-DSA, and SLH-DSA, all of which are finalized standards with dated regulatory deadlines already attached. HQC is a future addition to plan around, not a reason to pause current migration work.