ML-KEM and ML-DSA Explained for Architects

Most enterprise architects can name the two new acronyms by now, but far fewer can say precisely what ML-KEM and ML-DSA do, where they belong in an existing estate, and what migrating to them actually demands. This is the explainer we wish more boards had read before commissioning a "quantum strategy": grounded in the finalised standards, honest about timelines, and written for people who will have to deliver the migration rather than present a slide about it.

Key takeaways

• ML-KEM (FIPS 203) is a key encapsulation mechanism — it replaces RSA/ECDH key exchange. ML-DSA (FIPS 204) is a signature algorithm — it replaces RSA/ECDSA signatures. You need both, for different reasons.
• The urgent driver is harvest now, decrypt later: encrypted data captured today can be decrypted once a quantum computer arrives. Confidentiality that must outlast ~2030 is already at risk.
• Key exchange is the priority; signatures can follow. Confidentiality is retrospectively breakable; signature forgery is not.
• The real deliverable is crypto-agility, not a one-time swap. Standards and hybrid modes will change more than once.
• Realistic enterprise migration takes 5–15 years, and cryptographic discovery alone takes 12–24 months. Start the inventory now.

What problem are these algorithms actually solving?

A sufficiently large, fault-tolerant quantum computer running Shor's algorithm would break the public-key cryptography that secures essentially all modern communication: RSA, elliptic-curve Diffie-Hellman, and ECDSA. No such machine exists today, and credible estimates put a cryptographically relevant quantum computer years away. That sounds comfortable until you separate the two distinct guarantees public-key cryptography provides.

The first is confidentiality — keeping data secret. This is broken retrospectively. An adversary who records your encrypted traffic or exfiltrates encrypted backups today can simply store them and decrypt later, once the hardware exists. This is the harvest now, decrypt later threat, and it makes the migration urgent for any secret with a long confidentiality lifetime: patient records, state secrets, intellectual property, financial positions, anything you would not want read in 2035.

The second is authenticity — proving who signed something. A signature is verified at the moment of use. A quantum computer cannot forge a signature you accepted in the past; it can only forge new ones once it exists. That makes the signature migration important but less time-critical than key exchange. This single distinction shapes the entire migration sequence.

In Aug 2024, NIST finalised three standards to address both guarantees:

Standard	Algorithm	Type	Replaces	Migration priority
FIPS 203	ML-KEM (Kyber)	Key encapsulation	RSA / ECDH key exchange	High — harvest-now risk
FIPS 204	ML-DSA (Dilithium)	Lattice signature	RSA / ECDSA signatures	Medium — forgery at use-time
FIPS 205	SLH-DSA (SPHINCS+)	Hash-based signature	Conservative signature fallback	Niche — long-term roots of trust

ML-KEM and ML-DSA are both lattice-based, which gives good performance but relatively large keys and ciphertexts. SLH-DSA is hash-based — slower and larger, but resting on the most conservative security assumptions, which makes it attractive for long-lived roots of trust where you want minimal reliance on newer mathematics.

ML-KEM: replacing the key exchange

ML-KEM is a key encapsulation mechanism (KEM). The mental model is straightforward: instead of two parties running a Diffie-Hellman exchange, the sender uses the recipient's public key to encapsulate a freshly generated shared secret, producing a ciphertext; the recipient decapsulates it with their private key to recover the same secret. That shared secret then keys a symmetric cipher such as AES-256 — which, importantly, quantum computers do not meaningfully break, so your bulk encryption stays as it is.

The near-term deployment pattern is hybrid key exchange. In TLS 1.3, you combine a classical curve (typically X25519) with ML-KEM and derive the session key from both. The connection stays secure as long as either primitive holds — protecting you against a flaw in the still-young ML-KEM implementation and against the quantum threat to the classical curve. Major cloud, browser, and CDN providers — including Google, Cloudflare, AWS, and Microsoft — have deployed hybrid ML-KEM key exchange and are targeting broad internal adoption around 2029. For most enterprises, ML-KEM in hybrid TLS is the first concrete, low-regret step you can take today.

ML-DSA: replacing the signatures

ML-DSA handles digital signatures: code signing, document signing, certificate chains, token signing, firmware integrity. The engineering reality here is different from key exchange. ML-DSA keys and especially signatures are substantially larger than ECDSA equivalents, which has real consequences: certificates grow, handshakes carry more bytes, constrained devices and bandwidth-limited links feel it, and any system with hardcoded buffer sizes for signatures or certificates will need attention.

Because signature forgery is not a retrospective threat, you have more time — but PKI migrations are slow precisely because trust anchors are long-lived and widely embedded. The root-of-trust transition is the hardest part of any signature migration. This is where a hash-based fallback such as SLH-DSA earns its place for the most conservative, longest-lived roots. In our own delivery work, code signing pipelines and internal CAs are consistently where teams discover how many systems quietly assume a specific signature size.

The migration is a discovery problem first

Here is the uncomfortable truth we repeat to every client: you cannot migrate what you have not found. The single largest line item in a realistic post-quantum programme is cryptographic discovery — building a complete inventory of where, how, and why cryptography is used across applications, infrastructure, certificates, VPNs, message buses, databases, and embedded firmware. For a large organisation this routinely takes 12–24 months before a single algorithm is swapped. We cover the method in depth in our guide to cryptographic discovery and inventory.

A pragmatic sequence:

Loading diagram...

1. Inventory. Catalogue every cryptographic use with its algorithm, key size, owner, and the confidentiality lifetime of the data it protects.
2. Prioritise by exposure. Rank by harvest-now-decrypt-later risk. Long-lived confidential data and externally facing key exchange go first.
3. Deploy hybrid ML-KEM. Turn on hybrid TLS 1.3 key exchange where your platform supports it — the lowest-regret move available.
4. Pilot ML-DSA. Start with internal code signing and certificates; plan the CA and root-of-trust transition with the larger sizes in mind.
5. Abstract for agility. Route cryptographic calls through a versioned provider interface so the next change is configuration, not a project.
6. Re-test continuously. Re-run discovery on a cadence and track per-platform readiness as standards and hybrid modes evolve.

For the strategic framing — sequencing, governance, and how this fits a multi-year programme — see our crypto-agility roadmap for enterprises.

Where Azure fits

Microsoft added ML-KEM and ML-DSA to SymCrypt in late 2024, the cryptographic library underpinning Windows and many Azure services. Azure Key Vault and Managed HSM post-quantum support is tracking through 2026, with hybrid key exchange already reaching managed front ends and load balancers. The practical implication for architects is that different Azure services will reach PQC readiness at different times — your inventory must track readiness per service, not as a single platform flag. We walk through the specifics in Azure Key Vault post-quantum migration.

Crypto-agility is the actual goal

If you take one thing away, take this: the objective is not "deploy ML-KEM." It is to make cryptography something you can change on demand. The post-quantum standards will be revised, hybrid modes will eventually be deprecated in favour of pure post-quantum, parameter sets will shift, and SLH-DSA may displace lattice signatures for some roots. Organisations that abstracted cryptography behind clean interfaces will treat each of these as a configuration change. Organisations with algorithm choices hardcoded across hundreds of services will relive this migration every time. Crypto-agility is the difference between a one-off project and a permanent capability — and it is the lens through which every architectural decision here should be made.

The timeline pressure is real but manageable. NSA's CNSA 2.0 requires quantum-safe algorithms for new national-security systems by Jan 2027, with full migration across 2030–2035; the major cloud providers target roughly 2029 internally. For most European enterprises, the right posture in 2026 is to start the inventory, turn on hybrid key exchange where you can, pilot signatures, and build the agility that makes the rest tractable.

FAQ

What is the difference between ML-KEM and ML-DSA? They solve different problems. ML-KEM (FIPS 203) is a key encapsulation mechanism — it replaces the key exchange step that today uses RSA or elliptic-curve Diffie-Hellman, so two parties can agree on a shared secret. ML-DSA (FIPS 204) is a digital signature algorithm — it replaces RSA and ECDSA signatures used for authentication, code signing, and certificates. You generally need both, because confidentiality and authenticity are separate guarantees.

Are ML-KEM and ML-DSA production-ready in 2026? The algorithms themselves are finalised NIST standards (FIPS 203 and FIPS 204, published August 2024) and are implemented in mainstream libraries including Microsoft SymCrypt, OpenSSL, and BoringSSL. Production readiness depends on your platform: TLS 1.3 hybrid key exchange is widely deployed by major cloud and CDN providers, while signatures, PKI, and HSM-backed key storage are maturing through 2026. Treat key establishment as ready now and signatures as an active migration track.

Do we need to migrate to post-quantum cryptography now if quantum computers do not exist yet? Yes, for confidentiality that must outlast the next decade. The 'harvest now, decrypt later' threat means adversaries can record encrypted traffic and stored data today and decrypt it once a cryptographically relevant quantum computer exists. Any secret with a confidentiality lifetime beyond roughly 2030 is already exposed if it is protected only by classical key exchange. Signatures are less urgent because they protect against forgery at verification time, not retrospectively.

What is crypto-agility and why does it matter more than the algorithm choice? Crypto-agility is the ability to change cryptographic algorithms, key sizes, and protocols without re-architecting the systems that depend on them. It matters more than any single algorithm because the post-quantum standards will evolve, hybrid modes will be deprecated, and you will need to swap primitives more than once. Organisations that abstracted cryptography behind clear interfaces migrate in months; those with hardcoded algorithm choices spend years.

How does Azure support ML-KEM and ML-DSA? Microsoft added ML-KEM and ML-DSA to its SymCrypt cryptographic library in late 2024, which underpins Windows and many Azure services. Azure Key Vault and Managed HSM post-quantum support is tracking through 2026, with hybrid key exchange already reaching managed front ends and load balancers. Plan for an interim period in which different Azure services reach PQC readiness at different times, and design your inventory to track that per service.

How long does a post-quantum migration realistically take? For a large enterprise, five to fifteen years end to end. Cryptographic discovery alone — finding every place cryptography is used across applications, infrastructure, certificates, and embedded systems — typically takes twelve to twenty-four months before any migration begins. The realistic plan is a phased roadmap that prioritises long-lived confidential data and externally facing key exchange first, then signatures and PKI.

---

Post-quantum migration rewards the organisations that start with discovery and design for agility rather than chasing a single algorithm. If you want senior architects who have done this work to review your cryptographic inventory or shape your roadmap, our Zero Trust and security advisory team at CC Conceptualise is happy to help.