ML-KEM (FIPS 203) explained: what it replaces, how big it is and how to deploy it

Published 12 October 2026 · 9 min read · By Ali Korsi ML-KEM is the post-quantum algorithm most organisations will deploy first, because it protects key exchange, which is where harvest-now-decrypt-later risk lives. Here is what it is, how big it is, and what deploying it actually involves.

ML-KEM in one paragraph

ML-KEM (Module-Lattice-Based Key-Encapsulation Mechanism) is the NIST standard for establishing a shared secret key in a way that resists quantum computers. It was published as FIPS 203 in August 2024 and is derived from CRYSTALS-Kyber, the winner of NIST’s post-quantum competition. Its security rests on the Module Learning With Errors problem, for which no efficient quantum attack is known. It replaces the key establishment part of today’s public-key cryptography, not signatures, and not symmetric encryption.

What it replaces, and what it does not

Key establishment is where harvest-now-decrypt-later risk sits: traffic recorded today can be decrypted later if the key exchange that protected it is broken. That is why ML-KEM is usually the first post-quantum algorithm to deploy, ahead of signatures.

How a KEM differs from Diffie-Hellman

A key encapsulation mechanism has three operations:

1. KeyGen — the receiver creates an encapsulation key (public) and a decapsulation key (private).
2. Encaps — the sender uses the encapsulation key to produce a ciphertext and a 32-byte shared secret.
3. Decaps — the receiver uses the decapsulation key on the ciphertext to recover the same shared secret.

In an ephemeral exchange such as TLS 1.3 this maps neatly onto the existing pattern: the client’s key share is an encapsulation key, the server’s is a ciphertext. Protocols that rely on Diffie-Hellman’s other properties — static-static key agreement, or both sides contributing symmetrically without a round trip — do not get a drop-in replacement and need protocol changes. That is a design question to raise early, not at the end of a migration.

One more practical point: ML-KEM as standardised in FIPS 203 is not byte-compatible with earlier Kyber drafts. Software that shipped “Kyber” before 2024 needs updating to interoperate.

The three parameter sets

For comparison, an X25519 public key is 32 bytes and an RSA-2048 ciphertext is 256 bytes. ML-KEM is fast — key generation, encapsulation and decapsulation are cheap on modern CPUs — so the practical cost is mostly bandwidth: bigger handshakes, and messages that may no longer fit in a single packet.

Which one to choose? ML-KEM-768 is the common default and the one used in hybrid TLS today. The US CNSA 2.0 suite requires ML-KEM-1024 for national security systems. European agencies such as ANSSI and BSI generally ask for category 3 or above and for hybrid use during the transition. ML-KEM-512 is rarely the right choice for data that must stay confidential for a long time.

Hybrid key exchange in TLS 1.3

The most widely deployed form of ML-KEM today is the hybrid TLS 1.3 key-exchange group X25519MLKEM768. The client sends both an ML-KEM-768 encapsulation key and an X25519 public key (1,216 bytes together); the server answers with an ML-KEM ciphertext and its own X25519 share (1,120 bytes). Both shared secrets feed the key schedule, so the session stays secure as long as either algorithm holds. This is the “hybridation” that ANSSI recommends (in French).

Major browsers enable this group by default, large CDNs and cloud providers support it, and recent versions of common TLS libraries offer it. To check whether a server negotiates it, use an OpenSSL 3.5 or later client:

openssl s_client -connect example.com:443 -groups X25519MLKEM768 -brief </dev/null

If the handshake succeeds and reports X25519MLKEM768 as the negotiated group, the server supports it. Because the ClientHello grows past a typical packet size, test through your real network path: some older middleboxes and load balancers mishandle large or fragmented ClientHellos.

Library and platform support

Support has moved quickly. As of this writing, ML-KEM is available in, among others:

• OpenSSL 3.5 and later, including the hybrid TLS groups;
• Go 1.24 and later, with the crypto/mlkem package and hybrid key exchange enabled by default in crypto/tls;
• Java (JDK 24 and later), through the standard KEM API;
• BoringSSL and AWS-LC, Bouncy Castle, and the Open Quantum Safe project’s liboqs.

Versions and defaults change release by release, so check your exact versions — and the HSMs, appliances and managed services in the path, which often lag behind software libraries.

Planning the migration to ML-KEM

1. Find every key-establishment use. RSA key transport, ECDH, X25519, Diffie-Hellman and ECIES-style encryption, in code, in TLS and SSH configuration, in VPNs and in vendor products. A CBOM is the natural place to record them.
2. Rank by data lifetime and exposure. Flows that carry long-lived confidential data over networks you do not control come first; that is where HNDL risk is real.
3. Turn on hybrid TLS where your stack supports it. For many internet-facing services this is a configuration change once libraries are current, followed by testing for size-related breakage.
4. Plan the protocol work. Custom protocols, static key agreement and encrypted storage formats need design changes, not a library upgrade. Start them early.
5. Chase suppliers. HSMs, load balancers, VPN gateways and SaaS providers need their own ML-KEM support; track their roadmaps and put requirements in contracts.
6. Make the next change cheaper. Centralise key establishment behind libraries or services and make algorithms configurable — crypto-agility — so the next transition is not another rewrite.

For the wider picture across ML-KEM, ML-DSA and SLH-DSA, see our post-quantum migration roadmap, and for scoping, how to estimate the blast radius of a migration.

Where CRYPTAGION fits

CRYPTAGION covers step 1 and supports step 2. It finds RSA, ECDH, Diffie-Hellman and other quantum-vulnerable cryptography in Python, JavaScript/TypeScript, Java, Go and C/C++ source, X.509 certificates and live TLS endpoints (negotiated protocols and cipher suites), with the file and line or endpoint of every finding. Each finding gets a quantum status, a risk score that accounts for HNDL exposure, and a recommended replacement — for key establishment, ML-KEM (FIPS 203) — with a migration year and a roadmap wave. The inventory exports as a CycloneDX 1.6 CBOM.

Sources

• NIST FIPS 203: Module-Lattice-Based Key-Encapsulation Mechanism Standard (August 2024)
• NIST IR 8547 (initial public draft): Transition to Post-Quantum Cryptography Standards (November 2024)
• IETF draft-ietf-tls-ecdhe-mlkem: Post-quantum hybrid ECDHE-MLKEM key agreement for TLS 1.3
• Commission Recommendation (EU) 2024/1101 on a Coordinated Implementation Roadmap for the transition to Post-Quantum Cryptography

Sizes are taken from FIPS 203. Library and platform support is summarised as of October 2026 and changes often; check the release notes for the versions you run.

← All resources · Home