Why ML-KEM Only Is Not a Strategy

NIST spent eight years selecting post-quantum cryptography algorithms. Within seven months of finalising the first standards, they added a backup. What does that tell you about single-algorithm strategies?

On August 13, 2024, NIST published FIPS 203, finalising ML-KEM (formerly CRYSTALS-Kyber) as the primary standard for post-quantum key encapsulation. On March 11, 2025, they announced the selection of HQC as a backup algorithm built on entirely different mathematics. The message from the world's leading standards body is clear: even thoroughly vetted algorithms may harbour undiscovered vulnerabilities. Crypto-agility is not optional. It is the only sustainable approach to cryptographic security.

The case for crypto-agility was written in July 2022, when a NIST post-quantum finalist was broken in spectacular fashion. SIKE (Supersingular Isogeny Key Encapsulation) had survived nearly five years of intense global scrutiny in NIST's standardisation competition. It advanced through three rigorous evaluation rounds. Security researchers worldwide had examined its mathematical foundations.

Then Belgian researchers Wouter Castryck and Thomas Decru published a paper that ended SIKE instantly. Their attack recovered secret keys in approximately 62 minutes on a single CPU core of a decade-old Intel processor. The mathematical foundation of the attack proved especially sobering: they exploited research from 1997 and 2000 that had been publicly available for over two decades.

SIKE's design team issued an unambiguous verdict: "SIKE and SIDH are insecure and should not be used." NIST promptly eliminated the algorithm from consideration. This was not the first catastrophic failure that year. Rainbow, a digital signature finalist, had been broken by IBM researcher Ward Beullens just months earlier using 53 hours of laptop computation.

The March 2025 selection of HQC was deliberate and instructive. Dustin Moody, NIST mathematician and PQC project lead, explained the rationale: "We are announcing the selection of HQC because we want to have a backup standard that is based on a different math approach than ML-KEM. As we advance our understanding of future quantum computers and adapt to emerging cryptanalysis techniques, it's essential to have a fallback in case ML-KEM proves to be vulnerable."

The mathematical diversity is intentional. ML-KEM uses module lattice structures. HQC relies on quasi-cyclic error-correcting codes. If a breakthrough weakens lattice-based approaches, HQC remains unaffected. NIST's official status report states this explicitly: "NIST values having a variety of computational hardness assumptions and aims to reduce the risk that a single cryptanalytic breakthrough will leave no viable standard for key establishment."

If the standards body responsible for FIPS 203 is hedging, your organisation should too.

Security leaders already understand concentration risk. You manage it every day in other domains. You diversify cloud providers because a single outage should not take down your business. You spread certificate issuance across multiple CAs because one compromise should not invalidate your entire PKI. You build disaster recovery across regions because geography should not be a single point of failure.

Now apply that same logic to your cryptographic algorithms. If you are betting everything on ML-KEM, you have created the same concentration risk you spend resources avoiding everywhere else. The SIKE and Rainbow failures demonstrate this is not theoretical. Algorithms that survived years of expert review were broken by classical computers, not quantum ones.

Crypto-agility is not a product. It is an architectural capability. IBM Quantum defines it as systems that "can rapidly adapt cryptographic mechanisms and algorithms in response to changing threats, technological advances, or vulnerabilities." In practical terms, this means algorithm changes happen through configuration, not rebuilds.

‍"How many places would need to be updated if ML-KEM was deprecated tomorrow?"

‍If you can answer with a specific number, you have visibility. If that number is manageable through configuration changes rather than code rewrites, you have agility. If you cannot answer at all, you have exposure.

Major technology platforms have already embraced this approach. Apple's iMessage PQ3 combines ML-KEM with classical cryptography. Signal's protocol merges ML-KEM with existing elliptic curve algorithms so "an attacker has to break both." Cloudflare enabled hybrid X25519Kyber768 on all TLS 1.3 traffic. These organisations are not waiting to see if ML-KEM survives. They are building for the assumption that any algorithm might need replacement.

ExeQuantum's Agile principle, part of our STAC framework, is built specifically for this challenge: make algorithm changes routine, not revolutionary. Our platform enables organisations to discover where cryptographic dependencies live across their environment, remediate with hybrid and diversified approaches, and govern ongoing algorithm health as standards evolve.

The goal is not just surviving the post-quantum transition. It is building the architectural flexibility to handle whatever comes next, whether that is a new NIST standard, an unexpected vulnerability, or the eventual arrival of cryptographically relevant quantum computers. Organisations that treat PQC migration as a one-time project will find themselves scrambling when the next SIKE happens. Those that build crypto-agility will adapt and continue.

NIST spent eight years selecting algorithms and still added a backup seven months after finalising standards. Two late-stage candidates were broken by classical computers after years of expert review. The lesson is not that post-quantum cryptography is untrustworthy. The lesson is that no single algorithm should carry the entire weight of your cryptographic security. Build for change. Deploy hybrid approaches. Make algorithm updates routine. The organisations that embrace crypto-agility today will avoid the scramble that inevitably follows the next unexpected algorithmic collapse.