In March 2025, NIST quietly closed the book on the longest cryptography standardization process in history. HQC (Hamming Quasi-Cyclic) was selected as the fourth post-quantum standard, joining ML-KEM (FIPS 203), ML-DSA (FIPS 204), and SLH-DSA (FIPS 205) — the three algorithms Commerce approved in August 2024. The algorithm chapter is over. The migration chapter has no excuse not to have started.
Let me be direct about what HQC's selection actually means. The three finalized FIPS standards lean on two mathematical families: lattices (ML-KEM, ML-DSA) and hash functions (SLH-DSA). HQC is code-based — it relies on error-correcting codes, a completely different foundation. NIST selected it explicitly as a hedge: if a breakthrough attack on lattice problems materializes, HQC gives the ecosystem a fallback KEM. That's the right call. Cryptographic diversity at the algorithm layer is insurance, and good engineers buy insurance before the fire starts.
But here's what irritates me about how this is being received: the security community is spending energy debating HQC's selection rationale — decapsulation times, key sizes, performance trade-offs — while the vast majority of organizations haven't deployed any of FIPS 203, 204, or 205 yet. We're arguing about which fire extinguisher to bolt to the truck while the building has no sprinkler system installed.
The standardization timeline tells the real story. NIST kicked this off in 2016. Round 1 report in 2019. Third-round finalists in 2020. FIPS finalized in August 2024. Eight years from call-for-submissions to deployable standard — and implementation is still barely moving. Draft IR 8547, the transition roadmap, sets federal agency deadlines for deprecating RSA and ECC: broadly, 2030 for most systems, 2035 for the stragglers. Those dates sound distant. They aren't.
Consider the operational reality of migrating cryptography at scale. Certificate lifetimes, hardware security modules, protocol negotiation stacks, software dependencies, vendor support cycles — a realistic enterprise migration takes three to five years from initial audit to full cutover. If you're starting in 2026, you're cutting it close for 2030. If you haven't started, you're already late by any honest project plan.
The harvest-now-decrypt-later (HNDL) threat makes delay actively dangerous, not just strategically dumb. Adversaries — state actors primarily — are recording encrypted traffic today. They can't break RSA-2048 now, but they're banking on being able to in a decade. Sensitive data encrypted in 2022 could be readable by 2035. This isn't theoretical: multiple intelligence agencies have publicly confirmed HNDL as an active collection strategy. The sensitivity of what you're protecting today determines whether future decryption is catastrophic or merely embarrassing.
SP 800-227, the draft guidance on Key-Encapsulation Mechanisms published for comment in January 2025, closes another gap. It formalizes how KEMs should be integrated into protocols — exactly the implementation detail that library maintainers and vendors need to write interoperable, secure code. The comment period closed in March. The ecosystem is moving. The question is whether your organization is part of that movement or watching from the sidelines.
HQC matters. Crypto-agility — the engineering discipline of swapping cryptographic primitives without rearchitecting the whole system — is the right philosophy, and a code-based KEM gives the lattice-heavy FIPS portfolio a meaningful mathematical backup. But do not let the announcement of a fourth algorithm distract you from deploying the first three. The standards exist. The threat is active. The window is closing.
Run a KEM audit on your external-facing TLS endpoints this month. Tools like testssl.sh or ssllabs.com will show you which key exchange mechanisms are in use. Flag every service still negotiating RSA or ECDH-only handshakes and prioritize them for hybrid ML-KEM migration. Cloudflare, AWS ALB, and GCP Cloud Load Balancing all support X25519+ML-KEM hybrid today with a config change. Pick one service, flip it, measure the handshake overhead, and document the result. That's your proof-of-concept. Everything else follows from there.
HQC's selection may be generating false comfort in exactly the wrong places. Adding a fourth algorithm when most organizations haven't deployed the first three is a policy win that risks becoming an operational distraction. The cryptographic diversity argument is valid — mathematically diverse algorithms genuinely reduce systemic risk. But in practice, each additional standard expands the attack surface for misimplementation, increases the complexity of crypto-agility frameworks, and gives procurement teams one more reason to say 'let's wait until the dust settles.' The dust has settled. The risk isn't algorithm monoculture — it's inertia dressed up as prudence.