ML-KEM (Module-Lattice-Based Key-Encapsulation Mechanism) is the post-quantum key-exchange standard NIST published as FIPS 203 on August 13, 2024. Derived from CRYSTALS-Kyber, it lets two parties agree on a shared secret key that NIST believes can resist attacks from quantum computers. It comes in three sizes: ML-KEM-512, ML-KEM-768 and ML-KEM-1024.
The name is still unfamiliar to most people, even though their browser, CDN or SSH client may already use it. According to Ahrefs data from October 5, 2026, “ml-kem” gets only about 90 searches a month in the US (500 worldwide). The broader term “post-quantum cryptography” gets about 11,000 (14,000 worldwide). This guide explains what ML-KEM is, how it differs from Kyber and what to do about it.
What is ML-KEM?
ML-KEM is a key-encapsulation mechanism, or KEM: a set of algorithms that two parties use to set up a shared secret key over a public network. NIST defines it in FIPS 203, the Module-Lattice-Based Key-Encapsulation Mechanism Standard.
A KEM works like a lockbox exchange. One side publishes an encapsulation key. The other side uses it to create a fresh secret and a ciphertext, which it sends back. Only the holder of the matching decapsulation key can open the ciphertext and recover the same 32-byte secret. Both sides then use it to protect the rest of the session.
The name describes the math: FIPS 203 ties the security of ML-KEM to the difficulty of the Module Learning with Errors problem. NIST says that at present, ML-KEM “is believed to be secure, even against adversaries who possess a quantum computer,” which is not the same as proven unbreakable.
ML-KEM has one job: establishing keys. It does not sign anything. Digital signatures have their own post-quantum standards, ML-DSA and SLH-DSA, which NIST approved alongside FIPS 203 in August 2024. The RSA and ECDSA certificates most websites use today are still classical.
Why ML-KEM exists: the quantum threat to RSA and ECC
ML-KEM exists because NIST classes the public-key algorithms behind most key exchanges today, RSA and elliptic-curve cryptography (ECC), as quantum-vulnerable. When it published FIPS 203, NIST encouraged system administrators to begin transitioning to the new standards as soon as possible.
The pressure comes from data with a long shelf life. In the “harvest now, decrypt later” threat, adversaries “collect encrypted data now with the goal of decrypting it once quantum technology matures,” according to NIST’s draft IR 8547.
A 2023 factsheet from CISA, NSA and NIST makes the same point. It warns that threat actors could be targeting data today that would still need protection in the future. It calls this a “catch now, break later” or “harvest now, decrypt later” operation.
That makes a future problem a question about today’s traffic. Contracts, health records and trade secrets can stay sensitive for many years. You do not need to know when a capable quantum computer will exist to act on this. What matters is how long your data must stay confidential.
Kyber vs ML-KEM: what changed
ML-KEM is the standardized form of CRYSTALS-Kyber, not a new algorithm. But small changes in FIPS 203 mean it does not interoperate with the Kyber drafts shipped in 2023 and 2024.
CRYSTALS stands for Cryptographic Suite for Algebraic Lattices. Kyber was a submission to NIST’s post-quantum process, which opened with a call for proposals on December 20, 2016. On July 5, 2022, NIST chose it for general encryption, citing its comparatively small keys and its speed. FIPS 203 states that ML-KEM “is derived from the round-three version of the CRYSTALS-KYBER KEM,” so the core design is the same.
Appendix C of FIPS 203 lists what changed from round-three Kyber:
- The shared secret is fixed at 256 bits (32 bytes) for every parameter set.
- ML-KEM uses a different variant of the Fujisaki-Okamoto transform. For example, encapsulation no longer hashes the ciphertext into the shared secret.
- An initial step that hashed the input randomness was removed, and explicit input checks were added.
- Between the August 24, 2023 draft and the final standard, NIST added domain separation to key generation.
As a result, Kyber and ML-KEM implementations cannot talk to each other. In its September 13, 2024 post, Google said the final changes “make it incompatible with the previously deployed version of Kyber,” and announced that Chrome 131 would switch. The TLS codepoint changes from 0x6399 (X25519Kyber768) to 0x11EC (X25519MLKEM768).
ML-KEM parameter sets: 512, 768 and 1024
FIPS 203 defines three ML-KEM parameter sets. They trade key size and speed for security strength, and all three produce the same 32-byte shared secret.
| Parameter set | NIST security category | Encapsulation key (bytes) | Decapsulation key (bytes) | Ciphertext (bytes) | Shared secret (bytes) |
|---|---|---|---|---|---|
| ML-KEM-512 | 1 | 800 | 1,632 | 768 | 32 |
| ML-KEM-768 | 3 | 1,184 | 2,400 | 1,088 | 32 |
| ML-KEM-1024 | 5 | 1,568 | 3,168 | 1,568 | 32 |
FIPS 203 lists the three sets “in order of increasing security strength and decreasing performance,” so a higher category buys more margin at some cost in speed. Signal notes that ML-KEM 768 encapsulation keys and ciphertexts are over 1,000 bytes each, compared with the 32 bytes required for classical ECDH.
In deployed protocols, ML-KEM-768 is the common default. It is the post-quantum half of the X25519MLKEM768 TLS hybrid and of OpenSSH’s mlkem768x25519-sha256. NSA’s CNSA 2.0 requires ML-KEM-1024 for national security systems. FIPS 203 itself advises using the strongest parameter set possible when first setting up protection for data, weighed against performance.
Where ML-KEM is already used
ML-KEM and its Kyber predecessor are already deployed in Signal, Apple iMessage, Chrome, OpenSSH and Cloudflare. On April 7, 2026, Cloudflare reported that over 65% of human traffic to its network was post-quantum encrypted. Most deployments use a hybrid that pairs the post-quantum KEM with the classical X25519 algorithm.
A hybrid runs a classical exchange and a post-quantum exchange side by side and combines their keys. Signal’s 2025 design follows the same idea: it runs two ratchets alongside each other and mixes their keys into what it calls the Triple Ratchet protocol.
| Date | Deployment | What it uses |
|---|---|---|
| September 19, 2023 | Signal PQXDH | X25519 combined with CRYSTALS-Kyber |
| February 21, 2024 | Apple iMessage PQ3 | Kyber-1024 for initial key setup, Kyber-768 for rekeying, rolling out with iOS 17.4 |
| April 2024 | Chrome 124 | Kyber draft on by default for TLS 1.3 and QUIC on desktop |
| November 2024 | Chrome 131 | Switch from Kyber to ML-KEM, codepoint 0x11EC (announced September 13, 2024) |
| April 9, 2025 | OpenSSH 10.0 | mlkem768x25519-sha256 as the default key agreement |
| October 2, 2025 | Signal SPQR | ML-KEM 768 in the Triple Ratchet |
| Late October 2025 | Cloudflare | Majority of human-initiated traffic using post-quantum encryption |
| April 7, 2026 | Cloudflare | Over 65% of human traffic post-quantum encrypted; full post-quantum security targeted for 2029 |
| August 2026 | IETF RFC 10024 | X25519MLKEM768, SecP256r1MLKEM768 and SecP384r1MLKEM1024 as a Proposed Standard |
Signal’s SPQR announcement calls the new component the Sparse Post Quantum Ratchet, and it runs on ML-KEM 768. According to the OpenSSH 10.0 release notes, the hybrid mlkem768x25519-sha256 is now the default for key agreement.
Cloudflare also looks beyond key exchange: in its April 7, 2026 roadmap, it set 2029 as its target to be fully post-quantum secure, including post-quantum authentication.
Authentication is the gap. Key exchange is moving fast, while certificates and signatures are still mostly classical. With RFC 10024, published in August 2026, the TLS hybrids now have a Proposed Standard to build on.
The migration timeline: NIST, NSA and HQC
NIST IR 8547 is an initial public draft released on November 12, 2024. It proposes deprecating RSA and ECC at 112 bits of security strength after 2030 and disallowing quantum-vulnerable algorithms after 2035. Comments closed on January 10, 2025, but as of October 5, 2026, NIST’s CSRC site still lists only the draft, so treat its dates as proposals, not law. NSA has firmer dates for US national security systems, and NIST has picked a backup KEM in case ML-KEM ever needs one.
The two stages depend on strength level. For RSA, ECDSA, ECDH and finite-field Diffie-Hellman at 112 bits of security strength, such as RSA-2048, the draft lists “deprecated after 2030” and then disallowed after 2035. At 128 bits and above, it skips that stage and lists them as disallowed after 2035. The draft cites National Security Memorandum 10, which sets 2035 as the primary target for completing the migration across federal systems.
NSA’s rules for national security systems are stricter. Its CNSA 2.0 FAQ (version 2.1, December 2024) requires ML-KEM-1024 for all classification levels. From January 1, 2027, all new acquisitions for these systems must be CNSA 2.0 compliant unless otherwise noted. The FAQ says NSA intends all national security systems to be quantum-resistant by 2035.
NIST also wants a fallback. On March 11, 2025, it selected HQC, a KEM based on error-correcting codes, as a backup to ML-KEM. At the time, it said it expected to finalize the HQC standard in 2027. In the NIST announcement, Dustin Moody said the agency wanted “a backup standard that is based on a different math approach than ML-KEM,” which HQC provides.
What organizations should do now
Most organizations will never write ML-KEM code. Their job is to know where key exchange happens, protect long-lived secrets first and turn on hybrid key exchange wherever vendors already support it.
- Inventory your cryptography. List every place your systems establish keys: websites, APIs, VPNs, SSH, internal TLS, backups and third-party services.
- Rank data by how long it must stay secret. Records that must remain confidential for many years come first, because harvest now, decrypt later targets exactly that data.
- Enable hybrid key exchange where it exists. Check whether your CDN, load balancers and servers offer X25519MLKEM768, and whether SSH runs OpenSSH 10.0 or later with mlkem768x25519-sha256.
- Ask vendors for specifics. Ask which ML-KEM parameter sets they support, whether they follow RFC 10024 and when post-quantum signatures will arrive.
- Build for crypto agility. Keep algorithms configurable rather than hard-coded, so a revised standard or a backup algorithm becomes a configuration change, not a rewrite.
For a startup on modern cloud infrastructure, most of this comes down to settings and vendor questions. Teams that sell into government or regulated supply chains should also track CNSA 2.0 and any final version of IR 8547.
ML-KEM, Kyber and security brand names
Kyber remains a recognizable name in security branding, though the standard is called ML-KEM. To be precise, NIST standardized ML-KEM and derived it from CRYSTALS-Kyber.
One example from our portfolio is kyberit.si, a security-brand name that references Kyber, the algorithm family from which NIST’s ML-KEM was derived. .si is Slovenia’s country-code domain. For AI companies it reads as SuperIntelligence. That reading is our framing, not an official meaning. Our explainer on what superintelligence is covers the term itself.
Our guide to ccTLDs explains how country-code domains like .si work. Before buying any brand name, check the factors in our guide to premium domain names, from renewal costs to comparable sales.
