ML-KEM vs Kyber: what changed between the draft and FIPS 203

CRYSTALS-Kyber and ML-KEM are not two algorithms. ML-KEM is the standardized form of CRYSTALS-Kyber, published by NIST as FIPS 203 on 13 August 2024. The change is not cosmetic: FIPS 203 is a specification with its own parameter set names, its own key formats and its own validation rules, and an implementation of the earlier competition submission does not interoperate with an ML-KEM implementation. In TLS, that is why the pre-standard group X25519Kyber768Draft00 (codepoint 0x6399) is obsolete and has to be replaced by the ML-KEM groups.

One design, two names, one approved specification

A KEM (key encapsulation mechanism) is the component of a handshake that lets two parties agree on a shared secret. CRYSTALS-Kyber was the name of the lattice-based KEM submitted to the NIST post-quantum standardization process. When NIST issued the final standard, the algorithm was renamed ML-KEM, short for Module-Lattice-Based Key-Encapsulation Mechanism, and specified in FIPS 203. It was published alongside FIPS 204 (ML-DSA, signatures) and FIPS 205 (SLH-DSA, stateless hash-based signatures) on the same day.

In conversation, Kyber and ML-KEM refer to the same family of designs. In code, in a group list or in a compliance document, they are not interchangeable. Only ML-KEM as specified in FIPS 203 is an approved standard. Anything still labelled Kyber, Kyber768 or Draft00 predates it. Our ML-KEM reference page tracks the standard and its status, and the Kyber draft page tracks the pre-standard groups that should now be removed from configurations.

What the move from draft to final standard changed

FIPS 203 was released as an initial public draft for comment before NIST issued the final text. Three categories of change matter to an engineer or an architect.

Names and parameter sets

Kyber512, Kyber768 and Kyber1024 became ML-KEM-512, ML-KEM-768 and ML-KEM-1024. FIPS 203 specifies exactly these three parameter sets. A build option, a constant or a test vector that still carries a Kyber name is a signal that the code has not been updated, not simply that someone kept an old label.

Specification details that break interoperability

The final standard differs from the earlier competition submission in specification details including key generation, key encoding and the derivation of the shared secret. Those details are normative in FIPS 203 and should be read there rather than summarised second hand. The practical consequence is simple and absolute: a peer running pre-standard Kyber and a peer running ML-KEM will not derive the same shared secret. There is no negotiation between them, no downgrade path and no partial compatibility. The handshake fails, or the group is simply never selected.

Rules an implementation has to follow

FIPS 203 also specifies checks that an implementation performs on received key material before it is used, and defines the behaviour of decapsulation when the input is not valid (implicit rejection, which returns a pseudorandom shared secret instead of an error). Library authors carry most of this weight. For a consumer of a library, the lesson is to prefer a maintained implementation that states FIPS 203 conformance over a copy of reference code from the competition period, and to check the release notes rather than the algorithm name.

The three parameter sets: 512, 768 and 1024

FIPS 203 defines the three parameter sets against NIST security categories. The number is not a key length in bits: it is a label for the parameter set.

For general purpose TLS and SSH, ML-KEM-768 inside a hybrid construction is where the ecosystem has converged. If you operate systems in scope of NSA CNSA 2.0, the suite names ML-KEM-1024 together with ML-DSA-87, LMS or XMSS, AES-256 and SHA-384 or SHA-512, with exclusive use expected by the end of 2030 for software and firmware signing and traditional networking equipment, and by the end of 2033 for web browsers and servers, cloud services and operating systems. Other authorities frame their positions as recommendations: BSI TR-02102-1 recommends hybrid post-quantum key agreement, and ANSSI makes hybridation mandatory inside its regulated scope while stating that its post-quantum recommendations are not yet regulatory obligations elsewhere. This article is information, not legal advice.

TLS groups: what is current, what is obsolete

The named group is the visible part of all of this. Only the codepoints below exist in the IANA registry for ML-KEM, and only one of them is the obsolete pre-standard entry.

The hybrid groups combine a classical key agreement with ML-KEM, so the session stays at least as strong as the classical part if a weakness is found in the lattice construction, and gains post-quantum protection against recorded traffic. That combination is described for TLS 1.3 in RFC 10024 (August 2026). Recorded traffic is protected only by the key exchange, which is why key agreement migrates first and certificates can follow later. The X25519MLKEM768 page gives the detail of the group most servers should enable first.

What to check in libraries, servers and SSH

Run read-only checks first, on a staging host, before touching a production configuration.

OpenSSL

OpenSSL 3.5 or later is required for the ML-KEM TLS groups. An older branch may still advertise a Kyber draft group through a provider or a distribution patch: that is the case to find and remove.

openssl version
openssl list -tls-groups | grep -i mlkem
openssl s_client -connect example.com:443 -groups X25519MLKEM768

In the s_client output, read the negotiated group. If the connection fails with a handshake error while a classical group succeeds, the server does not support ML-KEM yet.

Server configuration

Always keep a classical fallback after the hybrid group so that older clients still connect. On nginx built against OpenSSL 3.5 or later:

ssl_ecdh_curve X25519MLKEM768:X25519:secp256r1;

Syntax and supported values differ between servers and between distribution builds, so verify against your own version. Our guide to enabling ML-KEM on nginx, Apache, HAProxy and Caddy covers the directive for each one.

SSH

OpenSSH 9.9 (19 September 2024) added mlkem768x25519-sha256, available by default. OpenSSH 10.0 (9 April 2025) made it the default key agreement, and OpenSSH 10.1 (6 October 2025) warns when a connection negotiates a key agreement that is not post-quantum, through the WarnWeakCrypto option enabled by default. Earlier versions, from OpenSSH 9.0, default to the hybrid sntrup761x25519-sha512@openssh.com, which is post-quantum but not ML-KEM.

ssh -V
ssh -Q kex | grep mlkem

Application code and dependencies

• Search your repositories and configuration management for the strings Kyber, kyber768, Draft00 and 0x6399. Every hit is either dead code or an active misconfiguration.
• Check pinned group lists in load balancers, CDNs, API gateways, reverse proxies and TLS terminators. A pinned list is the most common reason a modern library still negotiates a classical group.
• Check the release notes of your crypto library, not the algorithm name, for the statement that the implementation follows FIPS 203. Where FIPS validation matters to you, check the validation status of the specific module and version you ship.
• Record the parameter set, not just the algorithm, in your inventory: ML-KEM-768 and ML-KEM-1024 are different answers to an auditor asking which one you deployed.

Check what your servers actually negotiate

The fastest way to know whether a domain is on the standard or still on a draft group is to look at what it offers on the wire. You can scan your domain with PQC Status for free: the scanner reports the hybrid ML-KEM groups a server accepts, the TLS versions and cipher suites, and the certificate chain. A scan describes the externally visible TLS configuration only. It is not a certification and not a compliance attestation. The concrete next step for this topic: confirm that every public endpoint offers X25519MLKEM768 with a classical fallback, then remove any remaining reference to the pre-standard Kyber group from your configuration and your inventory.