How to Migrate to Post-Quantum Cryptography: ML-KEM, ML-DSA and Hybrid Approach

When the team understands that quantum risk is real, the pendulum often swings from "not my problem" straight to "let's change everything now." Both extremes get in the way. Migrating to post-quantum cryptography is an engineering project with sequence, priority and care, not a button.

With the NIST standards finalized, there is somewhere to migrate. ML-KEM takes care of key establishment, ML-DSA takes care of digital signature, and SLH-DSA serves as backup signature with different mathematical foundation. Knowing where to go is half the battle. The other half is doing it without breaking what works.

This text is the pragmatic roadmap: where to start, how to order, what to take care of during implementation and why the transition goes through a hybrid phase.

Start with the inventory, not the algorithm

The question "which algorithm do I adopt" is tempting and premature. Before it comes another: "where do I use cryptography today". Most organizations respond with silence, and this silence is the project's biggest risk.

You can't migrate what you can't see. Before touching any library, you need a cryptographic inventory: where keys and certificates are, which libraries and versions applications use, which protocols underpin their connections, and which vendors and integrations go into this chain.

This survey defines the real size of the problem and reveals hidden dependencies, those that no one has documented but that stop production if tampered with carelessly. I deal with the inventory in depth in a specific article in the series, because it is the foundation of everything that comes after.

Without inventory, any migration plan is a guess. With inventory, you know what you have, what's critical, and what can wait.

Prioritize by data validity and exposure

Migrating everything at once is expensive, risky and unnecessary. Smart sequencing follows risk, and risk focuses on two axes.

The first axis is the validity of confidentiality. Data that needs to remain secret for many years is most threatened by "harvest now, decrypt later", the capture of encrypted data today for decryption with quantum computing](/post/introducao-computacao-quantica-startups) in the future. The longer the validity of the secret, the sooner it needs post-quantum protection.

The second axis is exposure. Flows that cross networks that can be captured, external integrations and everything that negotiates keys over the internet move up the queue, because that is where the harvesting happens. Internal, isolated, low-value systems can wait.

There is also a difference in urgency between the two uses of encryption. Key establishment, the territory of ML-KEM, is a top priority because of harvest now: data captured today can be read later. Digital signatures, the territory of ML-DSA, have a different urgency, because a forged signature requires the quantum machine existing at the time of the fraud, not before. This doesn't make it skippable, especially for long-lived things like root certificates and firmware signing, but it helps organize the effort.

ML-KEM and ML-DSA: what each one is for

It is worth fixing the roles so as not to get confused when planning.

ML-KEM, FIPS 203, is a key encapsulation mechanism. In practice, it is what establishes the shared secret key that protects a connection. It is the direct replacement for key exchange that currently depends on RSA and ECC, and is therefore the first target for migration in sensitive flows.

ML-DSA, FIPS 204, is digital signature. It guarantees authenticity and integrity: that a software update came from who it says it is, that a certificate is legitimate, that a document has not been altered. It goes into PKI migration, code signing, and verification processes.

SLH-DSA, FIPS 205, also signs, but relies on hashing, with different premises. It is more conservative and tends to generate larger subscriptions. It is valuable as a strategic reserve where extreme longevity and diversity of fundamentals offset the cost.

Note that these algorithms do not live freely. They come to your operation from libraries, protocol libraries, cloud providers, and operating systems. Much of your migration will be updating and configuring these dependencies as they incorporate standards, rather than implementing encryption by hand.

The hybrid approach during the transition

Abruptly switching from classical to post-quantum algorithms is risky, and the industry has converged on a more sober response: hybrid mode.

In a hybrid key exchange, you combine the classical algorithm such as ECC with the post-quantum one such as ML-KEM, deriving the session key from the two. The connection is only secure if both are. This provides an important guarantee during the transition: you gain protection against the quantum threat without giving up the maturity of the classical algorithm.

The logic is one of prudence. Post-quantum algorithms are robust on paper, but have much less operational mileage than RSA and ECC. If an implementation weakness or an unexpected problem appears in the post-quantum component, the classical component still holds the bar. And if the quantum threat materializes, the classical component falls, but the post-quantum maintains protection.

The cost of hybrid is real: bigger keys and handshakes, more processing, protocol tuning. But it's the path most serious providers are taking, and adopting it puts you in tune with the ecosystem rather than against it.

Implementation care that separates the serious from the hasty

An approved algorithm is not synonymous with secure implementation. This is where well-intentioned projects get hurt.

Don't implement post-quantum cryptography on your own. Use mature, audited and actively maintained libraries. The parameters of these algorithms are sensitive, and implementation details, such as side-channel leakage, turn a strong algorithm into leaky protection. This is expert work and code review, not improvisation.

Plan for the new sizes. Post-quantum keys, signatures and handshake messages are larger than classical ones. This impacts packet size, protocol limits, certificates, storage, and performance. Systems that have assumed small sizes in design can break in subtle ways. Test under load and in real network conditions.

Take care of performance and compatibility. Algorithm negotiation between clients and servers at different stages of the migration needs planning, otherwise you drop legitimate connections. And ensure rollback capability: If a post-quantum update causes a problem in production, you need a safe way back, which brings us to the topic of crypto-agility.

Above all, design to change again. Post-quantum cryptography will evolve, parameters will be adjusted, and you don't want to repeat a years-long project with each change. Those who isolate encryption behind well-defined layers change algorithms with few changes. Whoever spread figures throughout the code will suffer.