ML-KEM is the Module-Lattice-Based Key-Encapsulation Mechanism, standardized by NIST as FIPS 203 in August 2024. It is a post-quantum method for two parties to agree on a shared secret key over an untrusted channel — the job classical key exchange like ECDH does today, but built on a problem believed to resist attack by a quantum computer.

What does FIPS 203 standardize?

FIPS 203 is the NIST publication that defines ML-KEM: its algorithms for key generation, encapsulation, and decapsulation, along with its parameter sets. Standardizing it means implementers have one agreed specification to build and test against, rather than a research proposal that can shift.

ML-KEM-768 is one parameter set of ML-KEM. It sits at NIST security category 3 and is built on the module-learning-with-errors (module-LWE) problem with fully public parameters — there is no secret setup, only a hard mathematical problem. The 768 refers to the parameters that set its security level.

How does ML-KEM relate to ML-DSA and SLH-DSA?

They are complementary. ML-KEM (FIPS 203) handles key establishment. ML-DSA (FIPS 204) and SLH-DSA (FIPS 205) handle digital signatures — proving who sent something and that it was not altered. A full migration typically touches both key exchange and signatures, so all three standards tend to appear together.

Do I replace ECDH with ML-KEM all at once?

Not necessarily. A common pragmatic default is a hybrid ECDH + ML-KEM key exchange, where a classical and a post-quantum method run together so the result is at least as strong as the stronger of the two. This is the migration path Q-Shield's NIST-aligned roadmap uses where it fits.

Q-Shield

What Is ML-KEM (FIPS 203)? A Plain Guide to the Post-Quantum Key Standard

ML-KEM is the NIST post-quantum key-establishment standard, published as FIPS 203 in August 2024. What it does, how ML-KEM-768 is parameterized, and how it fits alongside ML-DSA and SLH-DSA.

The one job ML-KEM does

When two systems open a secure connection, before they can encrypt anything they have to agree on a shared secret key — over a channel an eavesdropper may be watching. That agreement is called key establishment, and today it usually rests on classical methods like ECDH. Those methods are exactly the ones a sufficiently capable quantum computer running Shor's algorithm would break.

ML-KEM is the post-quantum replacement for that one job. Its name stands for Module-Lattice-Based Key-Encapsulation Mechanism, and it lets two parties arrive at the same secret key without an attacker being able to recover it — even one holding a quantum computer, under current understanding. It does not encrypt your data directly; it establishes the key that your ordinary symmetric encryption then uses.

What FIPS 203 means

ML-KEM did not simply appear as a good idea. It was standardized by NIST as FIPS 203, published in August 2024, after a multi-year public evaluation of candidate algorithms.

That "standardized" matters more than it sounds. A standard is a single, frozen specification: how keys are generated, how a shared secret is encapsulated and decapsulated, and which parameter sets are permitted. Everyone who implements ML-KEM builds against the same document, so independent implementations interoperate and can be tested for conformance. Before standardization, a scheme is a moving research target; after it, it is something you can deploy, audit, and require by name.

How ML-KEM-768 is built

ML-KEM comes in parameter sets that trade key size and computation against security level. A widely referenced middle choice is ML-KEM-768.

It sits at NIST security category 3 — one of the standardized rungs describing how much effort breaking it should take.
Its security rests on the module-learning-with-errors (module-LWE) problem, a lattice problem for which no efficient classical or quantum attack is known.
Its parameters are fully public. There is no trusted setup and no secret parameter to protect; the security comes entirely from the hardness of the underlying problem, out in the open.

The practical takeaway: choosing a parameter set is a deliberate security-level decision, not a detail to leave to chance. ML-KEM-768 is a common starting point precisely because category 3 gives comfortable margin for most systems.

Where ML-DSA and SLH-DSA fit

Key establishment is only half of what a secure channel needs. The other half is authentication — proving who you are talking to and that a message was not tampered with. That is the work of digital signatures, and NIST standardized post-quantum signatures alongside ML-KEM:

ML-DSA (FIPS 204) — a module-lattice signature scheme, the general-purpose signing counterpart to ML-KEM.
SLH-DSA (FIPS 205) — a stateless hash-based signature scheme, resting on different mathematics for teams that want that diversity.

You do not choose *between* these and ML-KEM. A real migration usually touches both key exchange and signatures, so ML-KEM (FIPS 203) tends to travel with ML-DSA (FIPS 204) and SLH-DSA (FIPS 205) as a set.

The pragmatic migration default: hybrid

Switching a live system straight from classical key exchange to ML-KEM alone is a large, risky step — the post-quantum implementations are newer and less battle-tested. So a widely used interim default is hybrid ECDH + ML-KEM: run a classical method and ML-KEM together and combine their outputs, so the connection is at least as strong as the stronger of the two. If some future weakness were found in either half, the other still holds.

This is the path a NIST-aligned migration roadmap typically takes: adopt hybrid first, gain operational experience, and move toward post-quantum-only key exchange as the ecosystem matures. It is a way to start migrating without betting everything on one new algorithm overnight.

Where Q-Shield fits

Understanding ML-KEM is one thing; knowing where in your own systems it needs to go is another. Q-Shield produces a NIST-aligned migration roadmap toward ML-KEM — including a hybrid ECDH + ML-KEM key exchange where that fits — so the standards described here map onto a concrete, prioritized plan rather than a reading list.

See how Q-Shield builds a NIST-aligned migration roadmap toward ML-KEM, including hybrid ECDH + ML-KEM key exchange.

Get started