One major reason ML-KEM got deployed before the other post-quantum standards is timing. An attacker can record your encrypted traffic today and decrypt it once there’s a large enough quantum computer out there, so the key exchange has to be fixed first.
This article explains what ML-KEM does and how a key-encapsulation mechanism works. You’ll also learn why it reached wide deployment ahead of the rest.
What ML-KEM is
ML-KEM is an abbreviation of Module-Lattice-Based Key-Encapsulation Mechanism. Its one job is to let two parties agree on a shared secret key over a channel anyone can read, with no known efficient classical or quantum method for recovering that key. Cryptographers call that step key establishment. Once the two sides share the secret, the protocol derives traffic keys for fast symmetric encryption such as AES-GCM or ChaCha20-Poly1305.
It was created by CRYSTALS, the same research project that’s behind Dilithium, now the ML-DSA signature standard. In August 2024, NIST made some technical changes to Kyber and published the result as the ML-KEM standard. The two names are used interchangeably, though the final standard isn’t a byte-for-byte copy of the original.
Its security rests on Module-LWE, a difficult problem on module lattices that no known efficient classical or quantum algorithm solves, and we discuss the underlying math in Lattice-Based Cryptography: Why Quantum Can't Crack It.
Inside a KEM
A key-encapsulation mechanism has a specific shape. The recipient generates a key pair and publishes the public half (the other half being the private key). With that public key, the sender produces two linked outputs at once: a random shared secret and a ciphertext that wraps it, then sends the ciphertext over. Back on the other end, the recipient feeds the ciphertext into their private key and recovers the same secret.
Anyone passively monitoring the connection sees only the public key and the ciphertext, which give no known feasible route to the secret under ML-KEM's assumptions. A KEM on its own doesn't prove whose public key you received, though. A deployed protocol still has to authenticate that key, through certificates or identity keys, to block a man-in-the-middle attack, where an impostor slips between the two ends and impersonates one to the other.
A KEM exchange: the recipient publishes a public key, the sender encapsulates a shared secret into a ciphertext, and the recipient decapsulates it back. Both end up with the same 32-byte secret.
It works a little differently from the Diffie-Hellman handshake, where both sides mix their own inputs into a shared key. A KEM runs in one direction, which fits cleanly into protocols like TLS and into the hybrid designs now shipping in production.
Why it holds up against quantum computers
The security comes from Module-LWE. Recovering the shared secret from what crosses the wire means solving a lattice problem, and there’s no known efficient quantum algorithm for that.
Shor's algorithm, the method that breaks RSA and elliptic-curve key exchange, doesn't crack Module-LWE. This is why ML-KEM is replacing quantum-vulnerable key establishment, which is the shift we explain in more detail in Post-Quantum Cryptography Explained.
ML-KEM also hardens itself against a subtler attack. A raw lattice encryption scheme can leak information if an attacker sends specially built ciphertexts and watches how decryption responds. ML-KEM wraps its core with an implicit-rejection form of the Fujisaki-Okamoto transform. During decapsulation, it decrypts the ciphertext and re-encrypts the result, then checks whether the two match. If they don't, it returns a fallback key that looks random instead of signaling a failure. That's what gives ML-KEM its believed chosen-ciphertext security, or IND-CCA2, the property a deployed protocol needs.
What it costs in bytes
ML-KEM comes in three parameter sets, from ML-KEM-512 up to ML-KEM-1024, each aimed at a higher security level. ML-KEM-768 is the set used in the recommended X25519MLKEM768 TLS hybrid. At that level, the public key is about 1,184 bytes and the ciphertext about 1,088, against a few dozen bytes for an elliptic-curve exchange. The shared secret itself is a compact 32 bytes.
That's manageable by post-quantum standards. In the standardized TLS hybrid, ML-KEM adds about 2.2 KB of key-share data to a handshake over plain X25519. In a full TLS handshake, the KEM public key and ciphertext each travel once, so those extra bytes stay modest next to the data a typical request carries, though they weigh more on short connections and can occasionally trip up old network gear. That small cost, together with the harvest-now-decrypt-later urgency and the option to keep classical certificate authentication, helped hybrid ML-KEM reach browsers before post-quantum certificate signatures.
Where it's already running
Final ML-KEM is already carrying live traffic through hybrid TLS. Chrome switched from the pre-standard Kyber draft to X25519MLKEM768 in version 131, and Cloudflare supports that standardized hybrid across its edge.
The messaging side is more mixed. Signal's 2023 PQXDH rollout used the pre-standard CRYSTALS-Kyber-1024 with X25519, and Signal began rolling out a separate ML-KEM-based mechanism called SPQR in 2025. Apple's published PQ3 design uses Kyber-1024 with P-256. AWS supports final ML-KEM hybrid key exchange in selected services, with client and configuration requirements varying by service.
Hybrid deployment has become the norm for ML-KEM in TLS and early messaging rollouts. ML-KEM is new, and a correctly built hybrid is designed so an attacker has to defeat both the classical scheme and the lattice one, which keeps today's security intact even if a flaw turns up in the lattice math later. It's a reasonable hedge as the new math earns more trust.
The hybrid design in production: a classical X25519 exchange and ML-KEM-768 run together and combine into one session key, so an attacker has to break both.
What ML-KEM protects in crypto
As far as crypto is concerned, ML-KEM covers a different flank than the signature schemes. Signatures like ECDSA control who can move funds. A KEM protects confidentiality, keeping data secret in transit.
Classical discrete-log signatures and classical key-establishment schemes are both vulnerable to a large enough quantum computer, and both need a post-quantum replacement. The harvest-now-decrypt-later strategy hits confidentiality first, so encrypted channels that rely on quantum-vulnerable classical key exchange and carry data that stays sensitive face a record-now-crack-later risk. This is why key establishment produced some of the first large-scale post-quantum deployments.
The asset side is a signature problem, which is what qLABS focuses on. Moving coins is authorized by a signature, so a quantum-safe vault leans on a post-quantum signature. qLABS applies a post-quantum layer in qVAULT, a non-custodial vault the company describes as using Falcon-based authorization.
A system that also needs post-quantum confidentiality would add a separate KEM like ML-KEM for that role. The qVAULT materials describe Falcon authorization, with no ML-KEM integration claimed. The vault listed qONE and HYPE as its supported assets as of August 2026. qLABS launched and promotes qVAULT and develops the qONE token. It also publishes the L1 Quantum Vulnerability Index. This gives it a commercial and reputational interest in the claims here, so read them with that in mind. Treat none of it as financial advice.
FAQ
What is ML-KEM?
ML-KEM is the NIST standard for post-quantum key establishment, published as FIPS 203 in 2024. It lets the two ends of a connection agree on a shared secret key that no known efficient classical or quantum attack can recover, and it's based on module-lattice math. It was built from the foundations of the scheme formerly called Kyber.
Is ML-KEM the same as Kyber?
Close, but not exactly the same. Kyber is the original name from the CRYSTALS project, and ML-KEM is NIST's standardized version in FIPS 203. FIPS 203 includes technical changes, so an older Kyber implementation shouldn't be assumed ML-KEM-compatible or FIPS-compliant.
What's the difference between ML-KEM and ML-DSA?
They do different jobs. ML-KEM (Kyber) establishes a shared secret key, protecting confidentiality. ML-DSA (Dilithium) produces digital signatures, and thus proves authenticity. An authenticated encrypted system generally needs both key establishment and authentication, though those roles needn't specifically use ML-KEM and ML-DSA.
Is ML-KEM being used yet?
Yes, but not every deployment labeled Kyber is the final ML-KEM. Final ML-KEM is live in hybrid TLS, after Chrome switched to X25519MLKEM768 in version 131 and Cloudflare enabled the same hybrid. On the messaging side, Signal's 2023 PQXDH used the pre-standard Kyber-1024, and Signal began rolling out an ML-KEM-based mechanism called SPQR in 2025. Apple's PQ3 uses Kyber-1024. Key establishment produced some of the earliest large-scale post-quantum deployments.
Is ML-KEM quantum safe?
As far as anyone knows, yes. It rests on the Module-LWE problem, which is vulnerable to no known efficient quantum attack, and this resistance is why NIST standardized it. That matches what cryptanalysts see today, short of a mathematical proof, so many early deployments use a hybrid classical and post-quantum construction as a safeguard.
qLABS Editorial. Sources are linked inline. See the L1 Quantum Vulnerability Index for our full methodology and conflict-of-interest disclosure.
