NIST spent nine years picking a lattice-based algorithm called ML-KEM to protect the internet from quantum computers, then turned around in March 2025 and picked a second one built on completely different math. That second algorithm, HQC, is not a replacement. It is a backup, and the gap between the two tells you almost everything about how post-quantum encryption is actually rolling out in 2026.

ML-KEM (Module-Lattice-Based Key-Encapsulation Mechanism) became a final NIST standard as FIPS 203 on August 13, 2024, and it is already carrying real TLS traffic at Cloudflare, Google, AWS, and inside OpenSSH. HQC (Hamming Quasi-Cyclic) won its spot as NIST’s fifth post-quantum algorithm on March 11, 2025, with a draft standard expected around 2026 and a final version targeted for 2027. One is deployed. The other is still on the runway. This comparison walks through the byte counts, the benchmark data, the deployment map, and what each algorithm actually costs you in bandwidth and compute, so you can decide what belongs in your migration plan for post quantum encryption this year.

Why NIST Wanted a Second Post-Quantum Algorithm

NIST’s post-quantum cryptography project standardized ML-KEM, ML-DSA, and SLH-DSA between 2022 and 2024, closing out most of a competition that started in 2016. ML-KEM won because it is fast, its keys are compact, and its underlying problem, Module Learning With Errors, has held up under two decades of cryptanalysis. But ML-KEM shares its mathematical foundation, structured lattices, with most of the other finalists NIST considered. If a breakthrough in lattice cryptanalysis ever landed, it could weaken more than one standard at once.

That single point of failure is exactly what pushed NIST to keep evaluating code-based candidates after the first four algorithms were finalized. HQC decodes random quasi-cyclic error-correcting codes, a branch of math that traces back to Robert McEliece’s 1978 cryptosystem and has nothing to do with lattices. NIST’s own announcement framed HQC as insurance: a second key-encapsulation mechanism built on different assumptions, so a future attack on lattice problems would not leave the entire post-quantum internet without a fallback. It beat out three other finalists, including BIKE and Classic McEliece, largely on the strength of its security proofs and implementation maturity.

That framing matters when you are deciding what to deploy this year. ML-KEM is the default, production-ready choice for post quantum encryption right now. HQC is a hedge you plan for, not a system you ship in 2026.

ML-KEM vs HQC: Full Specs Comparison

The two algorithms solve the same problem, letting two parties agree on a shared secret over a public channel, but they get there through very different math and very different byte budgets. Here is how they stack up across the specs that actually matter for deployment.

AttributeML-KEM (FIPS 203)HQC
Full nameModule-Lattice-Based Key-Encapsulation MechanismHamming Quasi-Cyclic
Mathematical basisModule Learning With Errors (structured lattices)Decoding random quasi-cyclic codes
NIST status (Sept 2026)Final standard, published August 13, 2024Selected as backup, March 11, 2025, draft expected 2026, final expected 2027
Role in NIST’s PQC suitePrimary, default KEMBackup KEM with a different security assumption
Parameter setsML-KEM-512, ML-KEM-768, ML-KEM-1024HQC-128, HQC-192, HQC-256
Public key size, lowest level800 bytes (ML-KEM-512)Combined pk+ct roughly 7 KB at the equivalent level, per Cloudflare
Ciphertext size, lowest level768 bytes (ML-KEM-512)Included in the ~7 KB combined figure above
Public key size, highest level1,568 bytes (ML-KEM-1024)Combined pk+ct roughly 21 KB at the top level, per Cloudflare
Ciphertext size, highest level1,568 bytes (ML-KEM-1024)Included in the ~21 KB combined figure above
Relative compute cost, top levelBaselineMore than 4x the compute of HQC-1 (its own lowest tier), per Cloudflare
TLS 1.3 IETF codepointsAlready drafted and deployed (e.g. X25519MLKEM768)Not yet defined
Reference implementationOpen source via liboqs, OpenSSL 3.2+, BoringSSLOpen source via liboqs (Open Quantum Safe)
Production deployment, 2026Cloudflare, AWS KMS, Google Cloud KMS, OpenSSH, ChromeNone identified in production, test and benchmark builds only

The NIST-confirmed byte counts for ML-KEM come straight from FIPS 203. The HQC wire-size figures come from Cloudflare’s own 2025 post-quantum internet report, which measured HQC against ML-KEM at matching security tiers and published the delta directly rather than leaving it to estimation.

Key and Ciphertext Sizes, Byte by Byte

Size is where the two algorithms diverge the most, and it is the number that shows up first in every engineering decision about post quantum encryption. ML-KEM-512, the lowest of the three parameter sets, needs an 800-byte public key and produces a 768-byte ciphertext. ML-KEM-768, the level most deployments actually use because it roughly matches AES-192 strength, needs 1,184 bytes for the public key and 1,088 bytes for the ciphertext. ML-KEM-1024, the highest tier, uses 1,568 bytes for both the public key and the ciphertext. Every one of those numbers is published directly in FIPS 203.

HQC does not publish as tidy a table in general circulation yet, partly because it has not gone through NIST’s formal FIPS drafting process. What is verified is Cloudflare’s side-by-side wire measurement: HQC-1, the entry-level parameter set, needs roughly 7 KB combined for its public key and ciphertext. That is close to double the 3 KB combined footprint of ML-KEM-1024, the strongest ML-KEM tier. At the top of HQC’s range, HQC-5 balloons to roughly 21 KB, about three times HQC-1 and seven times ML-KEM-1024.

Those extra kilobytes are not free. Every TLS handshake, every SSH connection, every VPN tunnel that switches from ML-KEM to HQC pays that overhead on every single connection setup. For a browser loading a page, a few extra kilobytes barely registers. For a constrained IoT device negotiating thousands of short-lived connections over a metered radio link, that same overhead adds up fast, and it is one reason engineering teams keep circling back to ML-KEM as the practical default.

Performance Benchmarks: Speed, Cycles, and Compute Overhead

Cloudflare’s post-quantum internet report is the most concrete public benchmark comparing the two algorithms directly, and its conclusion left little room for interpretation: HQC underperforms ML-KEM on every metric the team measured, including wire size and raw compute cost. At HQC’s highest security tier, Cloudflare clocked more than four times the compute overhead of HQC-1, its own lowest security tier. That is not a marginal gap. It is the kind of difference that shows up immediately in CPU utilization graphs on a busy edge server handling millions of handshakes.

wolfSSL, which maintains one of the most widely embedded TLS libraries in IoT and automotive firmware, reached a similar conclusion from its own implementation work. Comparing the two mechanisms directly, wolfSSL’s engineering team found ML-KEM smaller and faster across key generation, encapsulation, and decapsulation at every matching security level, and their public guidance now tells customers to start post-quantum migration today using ML-KEM rather than waiting on HQC. wolfSSL’s stated position is that ML-KEM already has standardized code points and production tooling, while HQC is still pre-standard, and shipping firmware against a moving target is not something the company recommends to embedded customers with multi-year hardware lifecycles.

The Open Quantum Safe project’s liboqs library, the reference implementation most vendors build on for early PQC testing, includes both algorithms and exposes its benchmark harness publicly. liboqs reports mean CPU cycles across key generation, encapsulation, and decapsulation for every supported KEM, and HQC’s code-based arithmetic consistently costs more cycles per operation than ML-KEM’s lattice arithmetic across the parameter sets liboqs tracks. Academic benchmarking on constrained hardware tells the same story from a different angle: research groups testing NIST’s standardized algorithms on ARM Cortex-M class microcontrollers have found ML-KEM’s memory footprint and cycle count far better suited to devices with kilobytes, not megabytes, of RAM. HQC’s larger keys and heavier arithmetic push it out of reach for a lot of that hardware class today.

Put together, three independent sources, Cloudflare’s production benchmarking, wolfSSL’s embedded implementation testing, and the Open Quantum Safe project’s cycle-count harness, land on the same conclusion from three different angles: ML-KEM is faster and lighter than HQC at every security level measured so far.

Security Foundations: Lattices vs Error-Correcting Codes

Performance numbers only matter if the underlying math actually holds. ML-KEM’s security rests on Module Learning With Errors, a lattice problem that asks an attacker to recover a short vector hidden inside a high-dimensional lattice full of noise. Structured lattice problems have absorbed roughly two decades of dedicated cryptanalysis, including the entire NIST PQC competition process, without a practical break. That track record is a big part of why ML-KEM won the primary slot.

HQC leans on a different, older idea. Its hardness comes from decoding random quasi-cyclic codes, a descendant of coding-theory problems that have been studied in information security since McEliece’s original 1978 cryptosystem. Code-based cryptography has its own long research history, and that is precisely the point. NIST is not picking HQC because it is faster or smaller, it is neither. NIST is picking it because a successful attack against lattice assumptions would not touch code-based assumptions at all. The two algorithms are intentionally unrelated at the math level, which is what makes HQC useful as insurance rather than as a primary tool.

This is also why organizations building crypto-agile systems, ones capable of swapping cryptographic primitives without a full rebuild, are treating ML-KEM and HQC as a pair rather than as competitors. The security argument for keeping both in the toolbox does not depend on either one winning a benchmark. It depends on them failing for different reasons, so that one failure mode does not take down every deployed system at once.

It helps to remember why this diversification instinct exists in the first place. RSA and classical Diffie-Hellman key exchange dominated the internet for over two decades on the strength of integer factorization and discrete logarithm problems, both of which a sufficiently large quantum computer running Shor’s algorithm would break. That is a single shared vulnerability sitting underneath almost the entire web’s key exchange. NIST’s post-quantum program exists to avoid recreating that same concentration risk with a new generation of algorithms, and pairing a lattice-based primary with a code-based backup is the most direct way to do that for key exchange specifically.

Standardization Status and Timeline in 2026

The standardization gap between these two algorithms is the single biggest reason they occupy different places in a 2026 migration plan. NIST published FIPS 203, the formal specification for ML-KEM, on August 13, 2024. It sits alongside FIPS 204 (ML-DSA) and FIPS 205 (SLH-DSA) as one of three finalized post-quantum standards, and IETF working groups have already drafted TLS 1.3 codepoints for it, including the hybrid group X25519MLKEM768 that pairs ML-KEM with classical elliptic-curve Diffie-Hellman for defense in depth.

HQC has no equivalent document yet. NIST’s March 2025 announcement selecting HQC also laid out the schedule: a draft standard for public comment roughly a year out, landing around 2026, with a final standard targeted for 2027. Nothing about that timeline has been accelerated as of September 2026. Until that draft and final publication happen, HQC has no FIPS number, no locked parameter definitions guaranteed to survive to the final version, and no IETF codepoints for TLS. Any team implementing HQC today is implementing against a specification that can still change.

That is not a knock on HQC’s cryptographic soundness. NIST already vetted the math before selecting it. It is a statement about process risk: shipping a pre-standard algorithm into production means re-doing that work if NIST tweaks parameters during drafting, a realistic possibility given that ML-KEM itself changed between its initial draft, submitted as CRYSTALS-Kyber, and its final FIPS 203 form.

Hybrid Key Exchange: Why Nobody Deploys PQC Alone

Almost nobody running ML-KEM in production today runs it by itself. TLS 1.3 defines the pure post-quantum codepoint TLS_MLKEM768, but the far more common deployment pattern combines ML-KEM with a classical elliptic-curve exchange like X25519 into a single hybrid group, X25519MLKEM768. Both the classical and post-quantum halves compute independently, and the final shared secret depends on both. An attacker has to break both halves to recover the connection, not just one.

That design choice reflects genuine caution rather than indecision. ML-KEM has had roughly a decade of public cryptanalysis as CRYSTALS-Kyber and as FIPS 203, which is a short track record next to the four decades classical elliptic-curve cryptography has survived. Hybrid groups mean a flaw discovered in ML-KEM tomorrow would not immediately expose traffic protected today, because the classical half of the key exchange is still doing its job. Cloudflare, Chrome, and the IETF’s TLS working group all standardized on hybrid groups rather than pure post-quantum ones for exactly this reason.

This is also where HQC’s eventual role becomes clearer. Once HQC has a final FIPS number, the most likely production pattern is not HQC replacing ML-KEM in the hybrid group, it is HQC joining as a third component, alongside a classical algorithm and ML-KEM, in deployments that want maximum diversification. A triple-hybrid group spends more bytes and more CPU cycles per handshake than a dual-hybrid one, so it will likely stay reserved for high-assurance environments rather than becoming the default for ordinary HTTPS traffic. That tradeoff, more assurance against a wider spread of possible failures in exchange for a heavier handshake, is the same tradeoff that shapes almost every decision in this comparison.

Where ML-KEM Is Already Running in Production

ML-KEM’s head start shows up clearly once you look at who has actually shipped it. Cloudflare has run hybrid post-quantum key exchange across its edge network since before FIPS 203 was even finalized, first with a draft version of Kyber and now with the standardized X25519MLKEM768 hybrid group, and its public post-quantum internet reports track adoption share across the traffic it handles.

AWS extended ML-KEM support into KMS, ACM, and Secrets Manager API connections in 2026, letting customers negotiate hybrid post-quantum TLS for the API calls that manage their encryption keys and certificates. Google Cloud KMS shipped its own ML-KEM-768 and ML-KEM-1024 key-encapsulation support around the same window, giving cloud customers a managed path to post quantum encryption without hand-rolling the cryptography themselves. Chrome and other Chromium-based browsers negotiate hybrid post-quantum key exchange with supporting servers by default, a major reason Cloudflare’s telemetry shows a meaningful share of HTTPS connections already using a post-quantum hybrid group.

OpenSSH added a Kyber-based post-quantum hybrid key exchange method years before FIPS 203 finalized, and current OpenSSH releases support ML-KEM-based hybrid groups for SSH session key negotiation, protecting remote administration traffic against future quantum decryption of recorded sessions. Signal’s PQXDH protocol and Apple’s iMessage PQ3 both adopted Kyber, the algorithm that became ML-KEM, ahead of NIST’s final standardization, specifically to get ahead of harvest-now-decrypt-later attacks against stored message metadata. That is five independent deployment paths, cloud infrastructure, browsers, SSH, and consumer messaging, all converging on the same algorithm well before HQC has a finished specification to build against.

Where HQC Stands Today

HQC’s deployment story in 2026 is short, and that is by design given its pre-standard status. The Open Quantum Safe project’s liboqs library added HQC support once NIST announced the selection, which lets researchers and library maintainers benchmark it and build test integrations. That is the extent of it. Available research and vendor documentation turned up no evidence of Google, AWS, Microsoft, or major browser vendors running HQC in any production traffic path as of September 2026. What exists is test tooling, academic benchmarking, and vendor statements about future readiness, not shipped infrastructure.

That gap is not a sign HQC is failing. It is exactly what NIST’s own timeline predicted: a backup algorithm selected in March 2025 was never going to have a draft standard, let alone production deployments, by late 2026. wolfSSL’s public position captures how most of the security industry is treating it right now, open to building HQC support once customers ask, but steering active migration work toward the algorithm that already has a FIPS number. Expect that to change once the draft standard lands and vendors have a fixed target to implement against, likely sometime around 2026 to 2027.

Adoption Cost and Infrastructure Overhead

Neither algorithm carries a license fee. Both ML-KEM and HQC reference implementations ship as open source through the Open Quantum Safe project’s liboqs, and both are built into free, widely used libraries: OpenSSL 3.2 and later, BoringSSL, and wolfCrypt all include ML-KEM support at no cost, while liboqs covers HQC for anyone testing ahead of standardization. The real cost of adopting either one is not a purchase order. It is bandwidth, compute, and hardware compatibility, and those costs diverge sharply between the two algorithms.

Cost factorML-KEMHQC
Software license costFree, open source (liboqs, OpenSSL 3.2+, BoringSSL)Free, open source (liboqs)
Bandwidth overhead per handshake, top security tier~3 KB combined public key and ciphertext~21 KB combined at top tier, per Cloudflare
Relative compute cost, top security tierBaseline reference point4x+ more compute than HQC-1 (its own lowest tier)
Constrained-device (microcontroller) readinessDemonstrated on ARM Cortex-M class hardware in academic benchmarksLimited by larger key and compute footprint
Cloud KMS support (AWS, Google Cloud), 2026Included in standard API pricing, no PQC surcharge identifiedNot offered as a managed KMS option yet
Migration engineering costLower, standardized target with existing IETF codepointsHigher, spec may still shift before final publication

The biggest hidden cost in either direction is not the algorithm itself, it is the engineering time spent building against a specification that has not been finalized. Every hour spent integrating HQC today is an hour that may need to be repeated once NIST publishes a draft with adjusted parameters. That risk, more than raw compute cycles, is what keeps most 2026 migration budgets pointed at ML-KEM first.

Migration Guide: Moving to Post-Quantum Encryption

Moving a system to post quantum encryption is not a flag you flip overnight, but the path for ML-KEM is well-trodden enough now that most teams can follow a straightforward sequence.

  • Inventory every place your systems use classical key exchange today: TLS termination points, SSH endpoints, VPN concentrators, and any custom key-agreement code.
  • Upgrade your crypto libraries to versions with native ML-KEM support. OpenSSL 3.2 and later, BoringSSL, and wolfCrypt all include it. Older LTS branches typically do not.
  • Enable a hybrid key-exchange group rather than switching to ML-KEM alone. Hybrid groups like X25519MLKEM768 keep a classical elliptic-curve exchange running alongside ML-KEM, so a flaw in either algorithm alone does not break the connection.
  • Test client compatibility before enforcing the new group everywhere. Older clients and some middleboxes still choke on the larger TLS ClientHello messages that hybrid post-quantum groups produce.
  • Monitor handshake latency and payload size in production. ML-KEM’s overhead is small compared to HQC, but it is not zero, and high-throughput services should baseline the impact before a full rollout.
  • Track NIST’s HQC draft standard rather than integrating it yet. Once the draft publishes, expect vendor libraries to add support quickly given liboqs already has a working implementation to build from.
  • Build your key-exchange code so the algorithm is swappable, not hardcoded. Crypto agility is what lets you add HQC as a second hybrid layer later without another full migration project.

A quick way to check whether your own TLS stack already speaks ML-KEM is to test a hybrid handshake directly against a server that supports it:

openssl s_client -connect example.com:443 -groups X25519MLKEM768

If the connection negotiates successfully and the output shows X25519MLKEM768 as the selected group, your OpenSSL build and the remote server both already support hybrid post-quantum key exchange. If it falls back to a classical group, that is a concrete signal for where to prioritize your migration work first.

Common Migration Pitfalls to Avoid

Most of the trouble teams run into migrating to ML-KEM has nothing to do with the algorithm itself and everything to do with how the change ripples through infrastructure that was never designed for larger handshake payloads. The most common failure is a fragmented rollout: enabling a hybrid group on the TLS termination layer without checking whether load balancers, middleboxes, or older firewall appliances silently drop or truncate oversized ClientHello messages. A hybrid ML-KEM handshake runs a few kilobytes larger than a classical one, and that is enough to trip fragmentation bugs in hardware that has sat unpatched for years.

A second recurring mistake is pinning a specific parameter set without checking what the client population can actually negotiate. ML-KEM-1024 offers the strongest security margin, but plenty of mobile clients and embedded devices still only support ML-KEM-768 or lack post-quantum support entirely. Forcing the highest tier everywhere, without a fallback path, breaks connectivity for a slice of real users instead of quietly downgrading them to a classical exchange while they catch up.

Teams experimenting with HQC ahead of standardization run into a different problem: treating a liboqs test build as production-ready. liboqs exists explicitly for research and benchmarking, and its own documentation does not present it as hardened, audited production cryptography. Wiring an unstandardized, pre-audit HQC implementation into a live system means inheriting both the standardization risk covered earlier and whatever implementation bugs have not yet been found through wider deployment. The safer pattern is keeping HQC confined to staging environments and internal benchmarking dashboards until NIST’s draft standard gives library maintainers a fixed target to harden against.

Finally, plenty of teams underestimate the operational cost of certificate and key-management systems that were never built with multi-kilobyte public keys in mind. Legacy hardware security modules, some ACME clients, and older certificate pinning logic can choke on payload sizes that barely register for a modern TLS stack. Auditing that layer before a hybrid rollout saves a lot of after-hours incident calls.

Pros and Cons: ML-KEM vs HQC

Neither algorithm is objectively better in every dimension. They are built for different jobs, and the honest tradeoffs look like this.

ML-KEM

  • Pro: Final NIST standard (FIPS 203) with locked parameters, no risk of spec drift.
  • Pro: Smallest keys and ciphertexts of any standardized PQC KEM, from 800 bytes at the lowest tier to 1,568 bytes at the highest.
  • Pro: Already deployed at Cloudflare, AWS, Google Cloud, in OpenSSH, and in Chrome, with real production telemetry behind it.
  • Pro: Fast enough for constrained microcontroller hardware, per published Cortex-M benchmarks.
  • Con: Lattice-based math shares assumptions with several of NIST’s other finalists, so it is not a hedge against a lattice-specific cryptanalytic break.

HQC

  • Pro: Built on code-based math, completely independent of ML-KEM’s lattice assumptions, which is real diversification value.
  • Pro: Backed by decades of code-based cryptography research dating to McEliece’s original 1978 system.
  • Con: No final FIPS standard yet. Draft expected around 2026, final around 2027.
  • Con: Roughly 2x to 7x the wire overhead of ML-KEM depending on security tier, per Cloudflare’s measurements.
  • Con: More than 4x the compute cost of ML-KEM-1024 at the top security tier.
  • Con: No confirmed production deployment at any major cloud provider or browser as of September 2026.

Five Use Cases and Which Algorithm Fits

The right choice depends heavily on what you are actually building. Here is how the decision tends to shake out across the situations most teams run into in 2026.

  • Public-facing TLS and HTTPS servers: use ML-KEM in a hybrid group today. It already has IETF codepoints, browser support, and CDN-level production experience behind it.
  • SSH and remote administration: use ML-KEM-based hybrid key exchange, since current OpenSSH releases already support it and the overhead is negligible for interactive sessions.
  • Long-term data-at-rest encryption with harvest-now-decrypt-later exposure: adopt ML-KEM now for anything encrypted today that must stay confidential for a decade or more, since waiting on HQC delays protection you can already have.
  • Federal, defense, or CNSA 2.0-aligned environments: follow NIST’s finalized guidance and standardize on ML-KEM, since HQC has no FIPS document to point compliance requirements at yet.
  • Bandwidth-constrained IoT and embedded devices: stick with ML-KEM-512 or ML-KEM-768. HQC’s larger keys and heavier compute make it a poor fit for metered radios and low-power microcontrollers right now.
  • Library maintainers and crypto-agility architects: implement HQC through liboqs in test and staging environments today, so your codebase is ready to add it as a second hybrid layer the moment NIST finalizes the standard.
  • High-assurance institutions wanting algorithm diversity as insurance: plan for a dual-KEM hybrid combining ML-KEM and HQC once HQC’s final standard ships, rather than deploying HQC alone ahead of standardization.

The Bigger Picture: NIST’s Full Post-Quantum Portfolio in 2026

ML-KEM and HQC only cover key exchange. NIST’s broader post-quantum program also standardized ML-DSA (FIPS 204) and SLH-DSA (FIPS 205) for digital signatures, and it is finalizing FN-DSA as a fourth signature option built on a different structure again. Key exchange and digital signatures solve different problems, agreeing on a shared secret versus proving a message came from a specific party, so an organization migrating to post quantum encryption typically needs to plan for both categories at once rather than treating ML-KEM alone as the finish line.

What makes the ML-KEM and HQC pairing distinct within that broader portfolio is the timing gap. ML-DSA and SLH-DSA finalized alongside ML-KEM in August 2024, giving signature algorithms their own diversity story already in place: ML-DSA is lattice-based, SLH-DSA is hash-based, an intentionally different foundation from day one. Key exchange did not get that same immediate diversity. ML-KEM shipped alone for seven months before NIST even named HQC as its future backup, and HQC still will not have a final specification for roughly another year past that. Anyone auditing a system for full post-quantum coverage in September 2026 will find the signature side of NIST’s portfolio more mature, with two independently-founded standards already available, than the key-exchange side, which is still waiting on its second option to finish standardization.

That gap is closing, not widening. NIST’s public statements around the HQC selection framed 2026 as the year for the draft standard, and vendor tooling, liboqs chief among it, is already built and waiting for that draft to land. The infrastructure to adopt HQC quickly exists. What is missing is the finished document to build against, and that is squarely NIST’s timeline to control, not industry’s.

The Verdict: Which Post-Quantum KEM Should You Use

For 2026 deployments, ML-KEM is the clear practical answer, and the data backs that up on every axis measured so far: smaller keys, smaller ciphertexts, lower compute cost, a finished FIPS standard, and production traffic already running through Cloudflare, AWS, Google Cloud, OpenSSH, and Chrome. HQC is not a failed algorithm. It is an unfinished one, still a year or more from a final standard, and Cloudflare’s own benchmarking shows it costing anywhere from roughly 2x to more than 4x the overhead of ML-KEM depending on which metric and security tier you look at.

The two algorithms are not really competing for the same job. ML-KEM is what you deploy for post quantum encryption today. HQC is what you architect your systems to accept later, as a second, mathematically independent layer once NIST locks its final specification. Teams that build crypto-agile systems now, capable of adding a second hybrid KEM without a rewrite, will be the ones positioned to fold HQC in cleanly whenever its FIPS document lands, likely in 2027.

Treat this as a two-stage plan rather than a single decision. Stage one, already underway across the industry, is getting ML-KEM into every TLS, SSH, and VPN endpoint that still relies on classical-only key exchange. Stage two, still ahead for nearly everyone, is layering HQC on top once its standard finalizes, for the specific systems where algorithm diversity is worth the extra bandwidth and compute. Conflating the two stages, either by rushing HQC into production early or by ignoring ML-KEM while waiting for a fully complete post-quantum picture, is the surest way to end up under-protected on both fronts.

Frequently Asked Questions

What is ML-KEM and why did it replace the name Kyber?

ML-KEM is the NIST-standardized version of the algorithm originally submitted to the PQC competition as CRYSTALS-Kyber. NIST renamed it Module-Lattice-Based Key-Encapsulation Mechanism when finalizing it as FIPS 203 in August 2024, and some parameters were adjusted from the original Kyber draft during standardization.

What is HQC and why did NIST pick a fifth algorithm?

HQC, short for Hamming Quasi-Cyclic, is a code-based key-encapsulation mechanism NIST selected on March 11, 2025. NIST added it as a backup specifically because it relies on different math than ML-KEM, reducing the risk that a single cryptanalytic advance could compromise every standardized post-quantum KEM at once.

Is HQC a replacement for ML-KEM?

No. NIST has been explicit that HQC is a backup, not a replacement, and that ML-KEM remains the recommended default for general-purpose post quantum encryption. HQC exists to provide a fallback if lattice-based cryptography is ever weakened.

When will HQC become a final NIST standard?

NIST said it planned to issue a draft standard for public comment roughly a year after the March 2025 selection, putting the draft around 2026, with a final published standard expected in 2027.

Which browsers and services already use ML-KEM?

Cloudflare runs ML-KEM-based hybrid key exchange across its edge network, Chrome and Chromium-based browsers negotiate it by default with supporting servers, AWS added ML-KEM hybrid TLS support to KMS, ACM, and Secrets Manager, Google Cloud KMS offers ML-KEM-768 and ML-KEM-1024, and current OpenSSH releases support ML-KEM-based hybrid key exchange for SSH sessions.

Is ML-KEM safe to use today for production TLS?

Yes. It is a finalized FIPS standard with published IETF TLS 1.3 codepoints, and major infrastructure providers already run it in production, typically paired with a classical algorithm like X25519 in a hybrid group for defense in depth.

Why is HQC so much larger than ML-KEM?

Code-based cryptography generally requires larger keys and ciphertexts than lattice-based cryptography to reach an equivalent security level, because the underlying decoding problem needs more redundant data to stay hard. Cloudflare’s benchmarking put HQC’s combined public key and ciphertext at roughly 7 KB to 21 KB depending on security tier, compared to ML-KEM’s 1.5 KB to 3 KB range.

Should I wait for HQC before migrating to post-quantum encryption?

No. Waiting on HQC delays protection against harvest-now-decrypt-later attacks that are already a real risk for data encrypted today. Migrate to ML-KEM now, since it is standardized and already deployed at scale, and plan to add HQC as an additional hybrid layer once its final standard ships.