FIPS 203 (ML-KEM): the standard that replaces RSA and ECDH key exchange

FIPS 203 standardizes ML-KEM, the Module-Lattice-Based Key-Encapsulation Mechanism derived from CRYSTALS-Kyber. It is the single most urgent post-quantum migration, because key establishment is what harvest-now-decrypt-later attacks target: an adversary recording your traffic today can decrypt it later once a quantum computer can break the classical key exchange.

What a KEM is (and how it differs from key exchange)

A key-encapsulation mechanism is a three-function primitive: KeyGen produces a public/private key pair; Encapsulate takes the public key and outputs a ciphertext plus a shared secret; Decapsulate takes the ciphertext and the private key and recovers the same shared secret. The result is a shared symmetric key, exactly what a Diffie-Hellman exchange gives you — but the construction is different, so it is not a drop-in at the protocol layer. Protocols such as TLS 1.3 had to define new code points to carry ML-KEM ciphertexts.

• **ML-KEM-512** — security roughly comparable to AES-128 (NIST category 1).
• **ML-KEM-768** — comparable to AES-192 (category 3); this is the common default for general use.
• **ML-KEM-1024** — comparable to AES-256 (category 5), for the highest assurance.

Deploy it hybrid first

The mainstream way to adopt ML-KEM today is a hybrid key exchange: run a classical exchange (X25519) and ML-KEM together and combine both shared secrets, so the session is safe as long as either one holds. The IETF-defined X25519MLKEM768 group is widely implemented in browsers and servers. Hybrid protects you against a flaw in the new algorithm and against harvest-now-decrypt-later at the same time, which is why NSA's CNSA 2.0 and most deployment guidance start there.