ML-KEM Survived a Scare. The Lesson Is Still About Crypto-Agility

Because for those few days, the response across the security community was telling. The reason the news landed so hard is not that one paper was unusually convincing. It is that most of the post-quantum cryptography we are deploying today rests on a single mathematical assumption: the hardness of structured lattice problems. ML-KEM relies on Module-LWE. ML-DSA and Falcon, the two main NIST signature standards, do too. If lattice problems had fallen, much of the public-key crypto roadmap of the next decade would have needed a rewrite overnight.

It did not. But the scare was a useful rehearsal, and it surfaces a question worth answering calmly: what does a system look like when it does not have to rewrite itself overnight?

The answer is crypto-agility, not the perfect algorithm

A common misreading of episodes like this one is that we need a better algorithm, one with stronger guarantees, more conservative parameters, or a different mathematical foundation. That instinct is understandable, but it leads to the same trap a decade from now. The history of cryptography is a history of assumptions that held for a long time, then did not. RSA-1024. SHA-1. SIKE, broken in 2022 by classical means a few months after advancing to the final NIST round. Betting that the next standard will be the last one is not a strategy. It is wishful thinking.

Crypto-agility is the discipline of designing systems so that the algorithm is a parameter, not a foundation. It means key management, protocol negotiation, certificate formats, and hardware interfaces are built to accommodate change. When ML-KEM needs to be swapped for SLH-DSA, for a code-based scheme like Classic McEliece, or for something that has not been named yet, the system absorbs the change instead of being rebuilt around it. Hybrid deployments, running a classical and a post-quantum algorithm in parallel, are one practical expression of this principle, and they are already mandated in a growing number of regulatory drafts.

If the recent scare had been real, the organizations that woke up calm were the ones that had treated ML-KEM as a configuration, not a commitment.

Agility is not only about algorithms

There is a part of this conversation that gets less attention than it should. Crypto-agility is sometimes just framed as the ability to swap algorithms. But algorithms are not the only thing that determines whether a deployment is secure. The quality of the randomness feeding the algorithm matters just as much, and often more, because broken entropy fails silently.

A perfect ML-KEM implementation, sourcing keys from a weak or biased entropy source, is not secure. It was never secure. No algorithmic upgrade fixes that. As Deloitte outlined in its framework for RNG maturity, most deployed hardware RNGs still operate at what it defines as Level 3: physical entropy sources whose quality is largely validated through statistical testing and assumptions about the source itself. Level 4 RNGs go further by continuously measuring and verifying entropy quality in real time, turning randomness from an assumption into an observable security property. As systems are designed to swap algorithms cleanly, the same modularity needs to extend to the entropy layer: where the randomness comes from, how it is mixed with software generators, and crucially, whether its quality can be checked rather than assumed.

Where Quside fits in

We’ve spent over a decade building a quantum entropy source that produces random numbers at the speed, scale, and quality that real cryptographic deployments require, with output that can be verified. Our products are designed to be the modular entropy layer in a crypto-agile architecture: plug-in compatible with standard libraries, capable of feeding any post-quantum scheme, and providing measurable, certifiable quality so the entropy assumption stops being a leap of faith.

If lattice problems fall tomorrow, our customers change one parameter. The randomness underneath does not need to change.

Key takeaways

• The recent ML-KEM scare was not real, but the exposure it revealed is.
• The defense is crypto-agility: treat the algorithm as a parameter, not a foundation.
• Designing flexible and generously can anticipate emerging needs.
• Bad randomness breaks any cryptography, post-quantum or otherwise.
• While algorithms can be swapped or updated, your entropy resource is fixed in hardware.
• Verifiable entropy turns an assumption into a measurement.

What to do next

Audit your randomness sources alongside your algorithm choices.  If you are evaluating PQC migration paths, audit your entropy layer with the same rigor as your algorithms. And if you want to discuss what verifiable entropy looks like in practice, we’re happy to talk.