What Is HQC? The Backup PQC Standard Security Architects Need to Plan For Now

When NIST finalized ML-KEM (FIPS 203), ML-DSA (FIPS 204), and SLH-DSA (FIPS 205) in August 2024, many security architects treated the portfolio as complete. NIST did not. In March 2025, NIST selected HQC as a fifth post-quantum algorithm—a second KEM built on entirely different mathematics—and documented its evaluation and rationale in NIST IR 8545.[NIST] That selection is a design signal, not an academic footnote. It tells architects that NIST itself does not consider a single algorithm family an adequate long-term foundation for key exchange security. Organizations currently building PQC migration roadmaps around ML-KEM alone are making an implicit bet that lattice-based cryptography will remain unbroken indefinitely. HQC exists largely because that bet carries non-trivial long-term risk. The analysis that follows interprets NIST's selections from an architectural-risk perspective; quotations and references to NIST documents are noted explicitly.

What HQC Is - and What It Is Not

HQC - Hamming Quasi-Cyclic - is a key encapsulation mechanism (KEM) selected by NIST as a backup to ML-KEM (FIPS 203), the main algorithm for general encryption finalized in 2024.[NIST CSRC] It is the fifth PQC algorithm selected by NIST and the second KEM in the portfolio. In operational terms, "backup" means HQC is not intended to replace ML-KEM or compete with it for immediate deployment. NIST guidance indicates organizations should continue prioritizing migration to the standards finalized in 2024 – FIPS 203, FIPS 204, and FIPS 205 – while HQC is being developed as a backup.[NIST] Understanding this distinction is critical before briefing leadership or updating migration roadmaps.

HQC does not yet have a finalized FIPS number. It is in a pre-draft phase; NIST plans to issue a draft standard incorporating HQC in about a year, with a finalized standard expected in 2027.[NIST] The window between now and that draft publication is a planning window - not a deployment window. For architects currently designing crypto-agile key exchange infrastructure, this timeline is directly actionable.

The Math Behind HQC: Why Code-Based Cryptography Matters

ML-KEM's security rests on the hardness of lattice problems - specifically, the Module Learning With Errors (MLWE) problem. HQC's security rests on an entirely different mathematical foundation: the hardness of decoding quasi-cyclic codes, a problem in code-based cryptography.[NIST IR 8545] This distinction is a central rationale for HQC's existence as a backup.

Code-based cryptography has a longer public security track record than lattice-based cryptography - the foundational problem dates to McEliece's 1978 proposal - and its hardness assumptions are considered mathematically independent from lattice problems.[NIST IR 8545] In practical terms, this means that a cryptanalytic breakthrough against lattice-based schemes would not automatically compromise HQC, and vice versa. For security architects, the implication is direct: a portfolio that includes both ML-KEM and HQC is not redundant - it is diversified. The two algorithms protect against different failure modes across different mathematical domains.

Why NIST Chose HQC Over BIKE and Classic McEliece

HQC was not the only code-based candidate evaluated in NIST's fourth round. BIKE and Classic McEliece were also under consideration.[NIST IR 8545] NIST IR 8545 documents the evaluation rationale that favored HQC over both. Classic McEliece has a decades-long security record but is characterized by very large public key sizes that create practical deployment barriers. BIKE is a more compact code-based scheme but raised concerns in evaluation that HQC's security profile did not.[NIST IR 8545] According to NIST IR 8545, HQC's selection reflects a judgment that it struck the best balance among the code-based candidates across security confidence, parameter sizes, and standardization readiness.

For architects who need to explain this selection internally, the core message from NIST IR 8545 is that HQC provided sufficient security assurance with more practical implementation characteristics than Classic McEliece, and stronger security confidence than BIKE warranted at the time of evaluation.[NIST IR 8545]

Where HQC Fits in the Full NIST PQC Stack

HQC is a KEM - it provides key encapsulation for establishing shared secrets, the same functional role as ML-KEM. It does not address digital signatures. That role is covered by ML-DSA (FIPS 204) and SLH-DSA (FIPS 205), with FN-DSA (forthcoming FIPS 206) rounding out the signature portfolio.[NIST PQC Project] Understanding how ML-KEM, ML-DSA, and HQC relate within the finalized NIST portfolio is essential before designing any migration architecture.

NIST SP 800-227 provides KEM definitions, security properties, and recommendations relevant to how KEMs like ML-KEM or future KEMs such as HQC can be evaluated and integrated.[NIST SP 800-227] For architects mapping HQC against existing protocol requirements - TLS key exchange, hybrid key agreement, or long-lived key establishment - SP 800-227 is the appropriate reference framework for understanding where a secondary KEM slot would apply.

What Security Architects Should Know About HQC's Performance Trade-offs

HQC requires more computing resources than ML-KEM due to larger key and ciphertext sizes.[NIST] This is not a disqualifying characteristic - it is the known cost of code-based cryptography relative to lattice-based schemes, and it is largely why HQC is positioned as a backup rather than a primary algorithm. For protocol design, this means that environments with strict latency constraints or bandwidth limitations - high-frequency TLS handshakes, for example - should not plan for HQC as a drop-in replacement for ML-KEM. Rather, HQC's deployment profile will likely suit scenarios where cryptographic diversity outweighs performance optimization: long-lived key establishment, high-value data protection with extended confidentiality requirements, or hybrid schemes layering a code-based KEM alongside a lattice-based one.

The performance gap also reinforces NIST's sequencing guidance. Architects who have not yet completed migration to ML-KEM as specified in FIPS 203 should treat that as the immediate priority - HQC's larger footprint makes it a poor candidate for initial deployment in most environments.

How to Prepare for HQC Before the Draft Standard Arrives

The practical preparation posture for HQC has three components, in priority order.

1. Complete FIPS 203/204/205 Migration First

NIST's guidance is to prioritize the 2024 finalized standards.[NIST] Given this, it is prudent to avoid spending architecture effort on HQC integration before ML-KEM is fully deployed. The 2024 standards are the foundation; HQC is a future layer.

2. Build a Secondary KEM Slot into Your Architecture Now

The concrete action HQC's selection demands is not deployment - it is architectural accommodation. Read NIST IR 8545, specifically the sections covering HQC's selection rationale, and use it to add a "cryptographic diversity" requirement to your organization's PQC migration architecture document.[NIST IR 8545] Specifically, define a secondary KEM slot - a placeholder in your key exchange design that could accommodate HQC without requiring full re-architecture. If your current PQC roadmap has no mechanism for swapping or layering KEMs, you have a crypto-agility gap. HQC's standardization timeline—draft expected about a year after the March 2025 selection and finalization in 2027—gives architecture teams on the order of 12 to 18 months to prepare before the standard matures.

3. Monitor the Draft Comment Period

NIST has indicated that a draft FIPS standard for HQC will be published for public comment approximately one year after the March 2025 selection.[NIST] The comment period is the right moment for architecture teams to engage with the specification details: parameter sets, API definitions, and security levels. Organizations that have tracked NIST IR 8545 and built secondary KEM accommodation into their roadmaps will be positioned to evaluate the draft constructively rather than reactively. Monitor the NIST PQC project page for publication notices.[NIST PQC Project]

Key Takeaways

• HQC was selected by NIST in March 2025, as documented in NIST IR 8545 - it is the fifth PQC algorithm and the second KEM in the NIST portfolio, designated as a backup to ML-KEM (FIPS 203).
• HQC's security rests on the hardness of decoding quasi-cyclic codes - a mathematically independent foundation from ML-KEM's lattice basis, which is a central rationale for its existence as a backup.
• NIST selected HQC over fourth-round competitors BIKE and Classic McEliece based on security profile and standardization readiness as evaluated in NIST IR 8545.
• HQC requires more computing resources than ML-KEM due to larger key and ciphertext sizes - it is a backup and diversity mechanism, not a performance-optimized replacement.
• A draft FIPS standard for HQC is expected approximately one year after the March 2025 selection, with finalization projected in 2027. No FIPS number has been assigned yet.
• NIST guidance is to prioritize migration to FIPS 203, 204, and 205 first - HQC is being developed as a backup, not an immediate deployment target.
• The immediate architect action is to add a secondary KEM slot to your PQC migration architecture document now, before the draft standard opens for comment.

Related Reading

On this site:

• How ML-KEM differs from CRYSTALS-Kyber and what FIPS 203 requires
• Building crypto agility before the 2030 deadline
• Lattice-based cryptography standards and migration architecture for security teams

Primary sources:

• NIST IR 8545 - Fourth Round PQC evaluation report and HQC selection rationale
• NIST Post-Quantum Cryptography project page - standardization timeline and portfolio tracking
• NIST SP 800-227 - KEM security properties and integration recommendations

This article draws on primary documentation from NIST IR 8545, the NIST news announcement of March 11, 2025, NIST CSRC, the NIST PQC project page, and NIST SP 800-227. All claims verified against official sources as of April 2026.