HQC is a key-encapsulation algorithm NIST selected on 11 March 2025 as a backup to ML-KEM. It rests on error-correcting codes, not lattices, so if a flaw were ever found in lattice-based schemes, a second option would exist. NIST says to keep migrating to ML-KEM in the meantime.
Why a backup at all
ML-KEM is the main general-purpose encryption standard, and it is built on structured lattices. If researchers found a serious weakness in that family, anything built only on lattices would be exposed at once. NIST wanted a fallback based on a different math approach than ML-KEM.
HQC fits that. Its security comes from the difficulty of decoding error-correcting codes. NIST's announcement says reviewers found it clean and secure enough to be a worthy backup.
How it differs from ML-KEM
NIST describes HQC as a lengthier algorithm that needs more computing resources. It is the backup, not the new default. If you are choosing today, ML-KEM is the recommended choice for general encryption.
Timeline NIST gave
In the March 2025 announcement, NIST said a draft standard for HQC was expected in about a year, followed by a 90 day public comment period, and a final standard in 2027. I could not confirm from the pages I fetched whether the draft has since appeared, so check the NIST project page before you plan around it.
What to do about it
- Do not pause your ML-KEM work. NIST says organizations should keep migrating to the standards finalized in 2024.
- Do not build HQC into production yet. There is no final standard to build against.
- Do design for algorithm swaps. Keep algorithm names in configuration, keep key and ciphertext sizes out of hard-coded buffers, and test with larger payloads.
- Track it if your risk model includes a break of lattice cryptography. Hybrid designs that combine different families are one response.
How this connects to crypto agility
The HQC story is the best argument for agility. NIST itself chose a second algorithm because it expects that parts of this field may change. Systems that can swap an algorithm through configuration and a rollout will be calmer when that happens.
A short test plan helps. Wrap your KEM calls behind one interface in your own code. Make sure that interface returns variable-length keys and ciphertexts. Add a test that swaps in a stub algorithm with different sizes and confirms the rest of the system still works. If that test passes, adding a second real algorithm later is a contained change instead of a project across every service.
Quick check
Should I wait for HQC before moving to post-quantum key exchange?
No. NIST says ML-KEM remains the recommended choice and that organizations should keep migrating to the standards finalized in 2024.
Is HQC lattice-based?
No. It is based on error-correcting codes, which is the reason NIST picked it as a backup.
Sources
Last reviewed: 19 October 2026.
