On 11 March 2025, the U.S. National Institute of Standards and Technology announced the selection of HQC — Hamming Quasi-Cyclic — as an additional algorithm for post-quantum key encapsulation. It joins the set of algorithms NIST has been standardizing since the conclusion of its multi-year post-quantum cryptography competition, and it answers a specific strategic question that has been open since the first standards were finalized: what happens if the primary algorithm turns out to be broken.

For organizations planning the migration of cloud infrastructure to quantum-resistant cryptography, HQC is not an alternative to deploy today. It is an insurance policy whose value lies precisely in being held in reserve. Understanding why NIST selected it — and why it built the migration program to accommodate it — is useful for anyone responsible for the cryptographic posture of cloud systems over the coming decade.

The Diversity Argument

When NIST finalized its first post-quantum standards in August 2024 — the key-encapsulation mechanism standardized as FIPS 203 (ML-KEM, derived from CRYSTALS-Kyber) and the digital-signature schemes in FIPS 204 and FIPS 205 — the headline result was that the world finally had government-blessed algorithms believed to resist attack by a sufficiently large quantum computer. We covered that milestone and its implications for cloud migration timelines in our analysis of the finalized post-quantum standards.

But cryptographers raised a structural concern. ML-KEM is built on the hardness of problems over structured lattices. So are most of the other leading candidates. If a mathematical breakthrough were to undermine the lattice assumptions — not a quantum attack, but a classical advance in lattice cryptanalysis — a large fraction of the new post-quantum ecosystem could fall at once. Cryptographic monoculture is a systemic risk: it is precisely the situation that lets a single discovery cascade into a global emergency.

HQC addresses this by resting on a different foundation. It is a code-based scheme, built on the hardness of decoding random linear codes — a problem family studied since the late 1970s, with a long and well-examined track record. Code-based cryptography and lattice-based cryptography would not both be broken by the same mathematical advance. By standardizing an algorithm from an unrelated assumption class, NIST gives implementers a fallback that does not share the failure modes of the primary recommendation.

What HQC Is and Is Not

HQC is a key-encapsulation mechanism: it lets two parties establish a shared secret over an untrusted channel, the building block beneath protocols like the TLS handshake that secures cloud API traffic. It is functionally comparable to ML-KEM in what it does, but it makes a different engineering trade-off.

The honest comparison:

  • ML-KEM remains the primary recommendation. It is faster and has smaller keys and ciphertexts than HQC. For the overwhelming majority of deployments, ML-KEM is the algorithm to standardize on now.
  • HQC has larger keys and ciphertexts. Code-based schemes have historically carried this cost. For protocols sensitive to handshake size — and TLS is somewhat sensitive, because larger key-exchange messages mean more bytes in every connection setup — this is a meaningful difference.
  • HQC is slower in the relevant operations, though both algorithms are fast enough for most practical use.

NIST has been explicit that HQC is a backup, not a replacement. The intended posture is that systems deploy ML-KEM as the default and have HQC available — ideally through crypto-agile implementations — so that if confidence in lattice assumptions ever erodes, the migration to a code-based alternative is a configuration change rather than a fresh multi-year scramble.

The Standardization Timeline

The HQC selection is an announcement, not a finished standard. NIST’s stated process is to develop a draft standard for the algorithm and put it through public review before finalization, a process that runs over the following couple of years. Implementers should therefore treat HQC as a known future option rather than something to wire into production paths immediately — the parameter sets and encoding details can still change before the standard is final.

This sequencing mirrors the ML-KEM path: years of competition and analysis, a selection announcement, draft standards, public comment, and then a finalized FIPS document. The discipline of that process is part of why the resulting standards command confidence.

Why This Matters for Cloud Migration

The practical lesson for cloud infrastructure teams is about architecture, not algorithm choice. The single most important property a system can have, in the face of an evolving cryptographic landscape, is crypto-agility: the ability to change the algorithm in use without re-architecting the system.

A few principles follow:

  • Build for substitution. Cryptographic primitives should be abstracted behind interfaces, with algorithm identifiers negotiated rather than hard-coded. A system designed this way can adopt ML-KEM now and move to HQC later — or run both in a hybrid arrangement — without invasive rework. A system with cryptographic choices baked into application logic will face the same painful migration twice.
  • Inventory before you migrate. Most organizations do not have a complete map of where and how they use public-key cryptography across their cloud estate — in TLS termination, service-to-service authentication, code signing, secrets management, and stored data. That inventory is the prerequisite for any orderly migration, and it is independent of which algorithm wins.
  • Hybrid is the prudent interim. Combining a classical algorithm (such as the established elliptic-curve key exchange) with a post-quantum one in a hybrid handshake means the connection remains secure as long as either component holds. This hedges against both quantum attack and implementation flaws in the still-young post-quantum code.

The threat model that justifies all of this is the “harvest now, decrypt later” scenario: an adversary records encrypted traffic today and stores it against the day a quantum computer can break the key exchange retroactively. Data with a long confidentiality lifetime — health records, state secrets, intellectual property — is exposed to this risk now, even though the decryption capability does not yet exist. That is why migration planning is a present-day concern rather than something to defer until quantum computers arrive.

A Note on Foundations

There is a thread connecting HQC’s selection to the longer history of distributed and open infrastructure. The reason the world can have an open, scrutinized fallback algorithm at all is that the post-quantum standardization process was conducted in public, with candidate algorithms, reference implementations, and cryptanalysis exposed to global review over years. The robustness of the result is a product of that openness — the same property that makes open-source infrastructure auditable makes open cryptographic standards trustworthy. A backup algorithm chosen behind closed doors would carry far less of the assurance that HQC’s public vetting provides.

Operator Takeaways

For teams responsible for cloud cryptographic posture in 2025:

  • Continue planning ML-KEM adoption as the primary post-quantum key-encapsulation mechanism; HQC does not change that.
  • Treat HQC as confirmation that crypto-agility is the right architectural investment — the standards body has explicitly built in algorithm diversity, and systems should be able to exploit it.
  • Track the HQC draft standard as it moves through public review, but do not deploy the algorithm in production until the standard is finalized.
  • Prioritize the cryptographic inventory and the abstraction work now; those efforts pay off regardless of which algorithms the next decade settles on.

Further Reading

Back to Blog