# NIST Round 4 KEM Candidates: Final Status **Source**: https://quantumsequrity.com/blog/nist-round-4-status **Category**: Future Research --- [← Back to Blog](../../blog) Future Research # NIST Round 4 KEM Candidates: Final Status 10 min read NIST's Round 4 of the Post-Quantum Cryptography Standardization Process kept three Key Encapsulation Mechanism (KEM) candidates alive after the lattice-based ML-KEM (formerly Kyber) was selected in Round 3. The three were Classic McEliece, BIKE, and HQC. All three are non-lattice schemes, included in Round 4 specifically to provide algorithmic diversity in case lattice-based KEMs were later weakened by attack. After three years of additional analysis, NIST published its Round 4 conclusions in NIST IR 8545 in March 2025, selecting HQC for standardisation. This article walks through what each of the three candidates is, why NIST selected HQC, and what happens to the other two now. The bottom line: HQC is on a FIPS track for 2026, BIKE remains a research-grade alternative, and Classic McEliece survives in niche conservative deployments but is not on a NIST standardisation track. ## Why Round 4 Existed NIST's main Post-Quantum Cryptography Standardization Process ran from 2017 to 2024. The agency received 82 submissions, narrowed to 64 in Round 1, 26 in Round 2, and 7 finalists plus 8 alternates in Round 3. In 2022, NIST selected one signature scheme (CRYSTALS-Dilithium, now ML-DSA), one stateless hash-based signature (SPHINCS+, now SLH-DSA), one lattice signature alternate (Falcon, now FN-DSA), and one KEM (CRYSTALS-Kyber, now ML-KEM). The three KEMs that did not get selected in Round 3 but were considered worth further study were moved to Round 4: Classic McEliece, BIKE, and HQC. NIST's reasoning: all the selected KEM was lattice-based, and if lattice cryptography were later compromised, the world would need a non-lattice fallback. The three Round 4 candidates were all code-based, providing diversity against the unlikely-but-possible failure of all lattice schemes. For background on the timeline, see [NIST PQC Standards Timeline](nist-pqc-standards-timeline). ## Classic McEliece Classic McEliece is the oldest KEM in the competition. The original McEliece cryptosystem was proposed by Robert McEliece in 1978 and has resisted all serious cryptanalytic attacks for nearly 50 years. The Round 4 submission updates the original to use Goppa codes with modern parameters and a CCA-secure conversion. **Why it is appealing**: The longest cryptanalytic record of any post-quantum scheme. No surprises in 50 years. **Why it lost out**: Public key sizes are huge. The standard parameter set (mceliece6960119) has a 1,047,319-byte (~1 MB) public key. A typical TLS handshake with this key is impractical. The submission team argues this is acceptable for some use cases (server-side static keys, occasional key exchange) but admits it is not a general-purpose KEM. NIST IR 8545 placed Classic McEliece in a "conservative deployment" category: not on the FIPS 203 track, but suitable for specific applications where conservative security mathematics outweighs the size penalty. Some HSM vendors and high-assurance government deployments still consider it. For more, see [Classic McEliece Deep Dive](classic-mceliece-deep-dive). ## BIKE BIKE (Bit-Flipping Key Encapsulation) is a code-based KEM using Quasi-Cyclic Moderate Density Parity-Check (QC-MDPC) codes. Compared to Classic McEliece, BIKE has 200x to 1000x smaller public keys (around 1.5 to 5 KB) at the cost of more complex security analysis around something called the Decoding Failure Rate (DFR). **Why it is appealing**: Compact keys, fast decryption, code-based diversity. **Why it lost out**: NIST IR 8545 cited two concerns: 1. **DFR analysis is hard**. Estimating the rate at which the bit-flipping decoder fails is non-trivial, and incorrect estimates lead to attacks (the GJS attack from 2016 demonstrated this). 2. **Side-channel resistance is harder than HQC**. The bit-flipping decoder has data-dependent timing in subtle places, making constant-time implementations error-prone. NIST did not say BIKE was insecure, only that HQC was the better fit for general-purpose standardisation. BIKE remains a research-grade alternative. For more, see [BIKE Explained](bike-explained). ## HQC HQC (Hamming Quasi-Cyclic) is a code-based KEM that avoids decoding failures entirely. It uses a different construction than BIKE: instead of relying on a probabilistic decoder, HQC has a deterministic structure that always decrypts correctly given the right private key. **Why NIST chose it**: - **No DFR issues**: HQC's design avoids the failure-rate analysis that complicates BIKE. - **Constant-time implementations**: Easier to make timing-safe than BIKE. - **Reasonable parameters**: Public keys around 7 KB, ciphertexts around 14 KB. Larger than ML-KEM but workable for non-handshake applications. - **Code-based diversity**: NIST gets a non-lattice KEM in the standard portfolio. NIST IR 8545 (March 2025) selected HQC for standardisation. NIST plans to publish the HQC standard as FIPS 207. When it selected HQC in March 2025, NIST said it expected a draft in about a year and a final standard in 2027; no draft had been published by August 2026. For more, see [HQC Explained](hqc-explained). ## What the Round 4 Decision Means NIST IR 8545 sets out three categories: 1. **Standardised**: HQC. Going on the FIPS track. 2. **Conservative use**: Classic McEliece. Suitable for niche applications, not on FIPS track. 3. **Research grade**: BIKE. Not standardised, may be reconsidered in future calls. The implications for production: - **For most users**: Stick with ML-KEM for KEM. It is FIPS-203 standardised, has the most mature implementations, and is the default in most PQC libraries. - **For users wanting non-lattice diversity**: HQC is the new option. Its FIPS standard is in progress. Plan for production deployment late 2026 or 2027. - **For high-assurance niches**: Classic McEliece remains an option for specific use cases (long-term archive encryption, government-trusted-channel KEM) where the 1 MB key is acceptable. - **For research**: BIKE remains interesting and may resurface in a future NIST call. For the broader picture, see [NIST FIPS Guide](nist-fips-guide). ## What Comes Next NIST has indicated several follow-up activities: **FIPS 207 (HQC)**: NIST planned a final standard for 2027; no draft had been published by August 2026. The standard will define HQC parameter sets, encoding formats, and conversion to a CCA-secure KEM. **Future KEM diversification**: NIST has not closed the door on additional KEM standardisation. A future call could revisit BIKE or invite new code-based or other-family submissions. As of early 2026, no such call is scheduled. **Signature on-ramp**: Separate from the KEM track, NIST opened an additional signature on-ramp in 2023 with 40 submissions. 14 advanced to Round 1 in late 2024. See [NIST Signature On-Ramp](nist-signature-onramp) for details. **Threshold cryptography**: A separate track for threshold post-quantum schemes is in progress. See [PQ Threshold Signatures](pq-threshold-signatures). For migration timelines, see [NIST PQC Standards Timeline](nist-pqc-standards-timeline). ## How HQC Compares to ML-KEM in Practice For users deciding between ML-KEM and HQC for non-lattice diversity, the practical comparison: **Public key sizes**: ML-KEM-768 has a 1,184-byte public key. HQC-128 has a 2,249-byte public key. Both fit comfortably in a TLS handshake. **Ciphertext sizes**: ML-KEM-768 ciphertext is 1,088 bytes. HQC-128 ciphertext is 4,481 bytes. HQC ciphertexts are about 4x larger than ML-KEM, which matters for high-volume key exchanges but is acceptable for most use cases. **Encapsulation time**: ML-KEM-768 encapsulation runs in around 50 microseconds on commodity x86. HQC-128 takes about 200 microseconds. Both are fast enough for any practical workload. **Decapsulation time**: Similar order of magnitude. ML-KEM is somewhat faster in current optimised implementations, but HQC has room to improve as the FIPS standard matures. **Security assumptions**: ML-KEM relies on Module-LWE. HQC relies on syndrome decoding of structured codes. Different families, no overlap in attack surface. For most users, ML-KEM is the default. HQC is the option to add for organisations that explicitly want non-lattice diversity. Hybrid encryption can use both: encrypt under ML-KEM and HQC simultaneously, derive the AES key from both shared secrets via KDF, gain protection if either family is broken. ## Migration Timing Considerations Organisations planning post-quantum migration have to decide when to add HQC support: **Now**: ML-KEM is FIPS-203 standardised since 2024. HQC FIPS draft is expected mid-2026, final by end-2026 or early 2027. Production HQC deployments are reasonable starting in 2027. **For new systems**: Build with ML-KEM today, add an HQC option in 2027 or 2028 once libraries mature. **For existing systems**: Migrate to ML-KEM first (or hybrid with X25519 as recommended by NIST). HQC can be added later as a non-breaking upgrade if the envelope format is extensible. **For high-assurance niches**: Some deployments may want HQC sooner to maximise diversity. Watch the FIPS 207 draft and pilot in a sandboxed environment before production. For the full timeline picture, see [NIST PQC Standards Timeline](nist-pqc-standards-timeline). ## What QNSQY Provides QNSQY ships ML-KEM hybrid encryption across all tiers. The Business tier additionally supports HQC for users who want non-lattice diversity. Classic McEliece and BIKE are not shipped because they are not on the NIST FIPS track for general-purpose use. The hybrid construction (ML-KEM + X25519, or HQC + X25519 in Business) means even if any single KEM family is ever broken, the encryption stays secure on the strength of the other family. See [Hybrid Encryption](hybrid-encryption) for the design and [HQC Explained](hqc-explained) for the HQC variant. QNSQY tracks NIST FIPS standards as they evolve. When FIPS 207 (HQC) is finalised, the QNSQY HQC implementation will be updated to match the standardised parameters. The hybrid envelope format is designed for forward compatibility, so adding new schemes does not require breaking changes to encrypted file formats. For organisations watching the post-quantum landscape, the takeaway from Round 4 is: the standards are settling. ML-KEM is the workhorse, HQC is the non-lattice alternative, and the rest of the post-quantum cryptographic toolkit (signatures, threshold variants, advanced primitives) is being built on top. The Round 4 conclusion does not mean the post-quantum competition is over. NIST continues with the [signature on-ramp](nist-signature-onramp) (14 candidates in Round 2), the threshold cryptography track, and may open future calls. The agency's stated philosophy is that post-quantum cryptography will need ongoing diversification, not just a one-time standardisation event. Round 4's outcome is one milestone in a longer programme. For users wanting a single sentence summary: ML-KEM is the default, HQC is the non-lattice alternative coming via FIPS 207, planned for 2027, Classic McEliece is the conservative niche option, BIKE is research-grade. Most production deployments today use ML-KEM. Adding HQC for non-lattice diversity is a reasonable upgrade target for 2027 onward. ## Frequently Asked Questions ### When will FIPS 207 (HQC) be published? When it selected HQC in March 2025, NIST said it expected a draft in about a year and a final standard in 2027. No draft had been published by August 2026. Production deployments using HQC can be expected in 2027 onward. ### Why was Classic McEliece not standardised despite its strong cryptanalytic record? Public key size. Classic McEliece keys are about 1 MB, which is impractical for most TLS-style key exchange. NIST chose HQC for general-purpose standardisation while leaving Classic McEliece available for niche conservative deployments. ### Is BIKE still secure? Yes, at the standardised parameter sets, with the caveat that DFR analysis is sensitive. NIST chose HQC over BIKE for analytical maturity and side-channel ease, not because BIKE was insecure. BIKE remains a research-grade alternative. ### Should I migrate to HQC instead of ML-KEM? For most users, ML-KEM is the default and works fine. HQC adds non-lattice diversity, which is meaningful only if you specifically want to hedge against an unlikely lattice break. QNSQY's Business tier offers both, so users can choose or use both in a hybrid. ### Will NIST open a new KEM standardisation round? NIST has not announced one as of early 2026. The agency has signalled it might consider additional KEM submissions in the future, but no concrete plan exists. The focus right now is on signature on-ramp and threshold cryptography. ### Can I run HQC and ML-KEM together for diversity? Yes. The deployment pattern is called a triple-hybrid: classical (X25519 or P-256), ML-KEM, and HQC combined through HKDF. ETSI TS 103 744 and IETF PQUIP guidance both accommodate this. The cost is one extra ciphertext (~14 KB for HQC-256) and modest extra CPU. The benefit is resilience if either lattice or code-based assumptions fall. ## Sources 1. NIST. "Status Report on the Fourth Round of the NIST Post-Quantum Cryptography Standardization Process." NIST IR 8545, March 2025. https://csrc.nist.gov/pubs/ir/8545/final 2. NIST. "FIPS 203: Module-Lattice-Based Key-Encapsulation Mechanism Standard." 2024. https://csrc.nist.gov/pubs/fips/203/final 3. Aragon, N., Barreto, P., Bettaieb, S., et al. "BIKE: Bit Flipping Key Encapsulation, Round 4 Specification." 2022. https://bikesuite.org/files/v5.0/BIKE_Spec.2022.10.10.1.pdf 4. Aguilar-Melchor, C., Aragon, N., Bettaieb, S., et al. "HQC: Hamming Quasi-Cyclic, Round 4 Specification." 2023. https://pqc-hqc.org/doc/hqc-specification_2023-04-30.pdf 5. Bernstein, D.J., et al. "Classic McEliece, Round 4 Submission." 2022. https://classic.mceliece.org/nist/mceliece-20221023.pdf 6. NIST. "Status Report on the Third Round of the NIST Post-Quantum Cryptography Standardization Process." NIST IR 8413, July 2022. https://csrc.nist.gov/pubs/ir/8413/final 7. ETSI TS 103 744 v1.2.1, "Quantum-Safe Hybrid Key Exchanges." https://www.etsi.org/deliver/etsi_ts/103700_103799/103744/ 8. IETF PQUIP Working Group, "Post-Quantum Cryptography for Engineers." https://datatracker.ietf.org/doc/draft-ietf-pquip-pqc-engineers/ ## Related Articles - [HQC Explained](hqc-explained) - [BIKE Explained](bike-explained) - [Classic McEliece Deep Dive](classic-mceliece-deep-dive) - [NIST FIPS Guide for Post-Quantum Standards](nist-fips-guide) - [NIST PQC Standards Timeline](nist-pqc-standards-timeline) --- ### Protect Your Data Before Q-Day Arrives QNSQY's NIST-standardized post-quantum encryption protects files against both current and quantum-era threats. [Try QNSQY](../../pricing)