ML-KEM Guide: How FIPS 203 Works and How to Deploy It

Every key exchange that relies on RSA or elliptic curve Diffie-Hellman today can be recorded now and broken later by a large enough quantum computer, and ML-KEM is the NIST standard that replaces it. FIPS 203, the Module-Lattice-Based Key-Encapsulation Mechanism Standard, was published as final on 13 August 2024 and is the only post-quantum public-key key establishment scheme NIST currently approves. This guide goes below the migration roadmap: what a KEM actually does, how the three parameter sets differ in size and strength, which implementation rules in FIPS 203 and SP 800-227 trip teams up, how hybrid key exchange is built, and what to demand from suppliers. It is written for security architects, cryptography engineers, platform teams and the people who buy products that will carry ML-KEM. For the programme view (inventory, prioritisation, timelines), see the Post-Quantum Cryptography Migration Guide.

Key takeaways

• ML-KEM is a key encapsulation mechanism, not a drop-in Diffie-Hellman. One party encapsulates to the other's public key and sends a ciphertext; protocols built around a symmetric DH exchange need redesign, not just a new algorithm identifier.
• ML-KEM-768 is the common default, ML-KEM-1024 the high assurance choice. Category 3 suits most commercial traffic; CNSA 2.0 requires ML-KEM-1024 for US national security systems at all classification levels.
• Keys and ciphertexts are far larger than ECDH. An ML-KEM-768 encapsulation key is 1,184 bytes against 32 bytes for X25519, which breaks assumptions in packet sizes, middleboxes, HSM buffers and constrained devices.
• Hybrid is the deployment pattern for now, with an approved combiner. X25519MLKEM768 is already widely negotiated in TLS 1.3, and SP 800-227 warns that a naive combination of shared secrets can lose the security properties you wanted.
• Procure against FIPS 203 explicitly. Ask for the parameter sets supported, validation status, input checking, seed handling, side-channel resistance and a crypto-agile upgrade path, because FIPS 203 itself has a pending correction.

What ML-KEM is and why it matters now

ML-KEM lets two parties establish a shared secret over a public channel. That secret then feeds symmetric encryption and authentication, exactly as an ECDH shared secret does in TLS, SSH, IPsec or a messaging protocol today. Its security rests on the Module Learning with Errors (MLWE) problem, which is believed to resist attack by both classical and quantum computers. ML-KEM is derived from CRYSTALS-Kyber, the scheme selected in round three of the NIST post-quantum competition; FIPS 203 Appendix C lists the changes, so a library that implements "Kyber" from before 2024 is not interoperable with FIPS 203 ML-KEM and should not be treated as compliant.

• The threat it addresses: harvest now, decrypt later. An adversary who records traffic today, for example through network sniffing (T1040) or an adversary-in-the-middle position (T1557), can decrypt it once a cryptographically relevant quantum computer exists. Data with a long confidentiality life is exposed now, not in the future. See the Harvest Now Decrypt Later Risk Assessment Template.
• What it does not cover: authentication. Signatures in certificates and code signing need ML-DSA or SLH-DSA, which have a different and generally slower migration path. See the ML-DSA and SLH-DSA Post-Quantum Signatures Guide.
• Status: FIPS 203 is final. On 17 November 2025 NIST added a planning note saying it had identified an issue that will be corrected in a future update, with details in an errata spreadsheet on the publication page. Track that page and your library's release notes.

How a KEM works: the three algorithms

A KEM has three operations. Understanding who holds which value is the basis for every design and key protection decision.

Two properties matter in practice. First, ML-KEM uses implicit rejection: if a ciphertext is malformed or tampered with, decapsulation does not return an error but a pseudo-random value derived from secret material, so the protocol fails later at key confirmation or the first authenticated record. Code that adds its own early error paths can reintroduce the timing oracles the design avoids. Second, decapsulation can fail by chance, but the failure probabilities stated in FIPS 203 are negligible: about 2^-138.8 for ML-KEM-512, 2^-164.8 for ML-KEM-768 and 2^-174.8 for ML-KEM-1024.

Parameter sets: sizes, strength and choice

FIPS 203 defines three parameter sets in order of increasing security strength and decreasing performance. All three are approved for protecting sensitive, unclassified federal information.

Choosing a parameter set

• General commercial and enterprise traffic: ML-KEM-768. It is the set used in the X25519MLKEM768 TLS group that browsers and major CDNs negotiate, which gives you the widest interoperability.
• US national security systems and their suppliers: ML-KEM-1024. The NSA CNSA 2.0 FAQ specifies ML-KEM-1024 for all classification levels, expects new acquisitions to be CNSA 2.0 compliant from 1 January 2027, and mandates CNSA 2.0 algorithms by 31 December 2031.
• Long-lived secrets and high-value archives: ML-KEM-1024 where the size cost is affordable, for example key wrapping for backups that must stay confidential for decades.
• Constrained devices and tight packet budgets: ML-KEM-512 is approved, but treat it as a deliberate, documented exception with a reason, and keep the code path able to move up a set.
• Small organisations: you will rarely choose parameters directly. Your decision is which products and library versions to run and whether their defaults are acceptable; document that decision and check it during procurement.

Implementation rules that matter

FIPS 203 and NIST SP 800-227, Recommendations for Key-Encapsulation Mechanisms (final, September 2025), contain the "shall" statements that validation labs test and the "must" statements that application owners are responsible for. The ones that cause real defects are below.

• Input checking: FIPS 203 states that implementers shall ensure Encaps and Decaps are only executed on inputs that have been checked (encapsulation key type and modulus checks, decapsulation key and ciphertext length checks). If you accept encapsulation keys from peers, confirm your library performs the check or do it before calling it.
• Randomness: random bytes must come from an approved random bit generator (SP 800-90A, 90B and 90C) with a fresh value per invocation, at 128, 192 or 256 bits of strength depending on the parameter set. Virtual machines cloned from a snapshot and early-boot embedded devices are the classic places where this fails.
• Seed storage: a key pair can be stored as the 64-byte seed (d, z) and re-expanded later. FIPS 203 says the seed shall be treated with the same safeguards as a decapsulation key. Seed storage is compact and attractive for HSMs and secure elements, but it is still a private key.
• Destroy intermediates: intermediate values must be destroyed once no longer needed, except the seed and public data such as the expanded matrix derived from the encapsulation key.
• Ephemeral key use: SP 800-227 requires an ephemeral key pair to be used for only one key establishment and destroyed as soon as possible. Reusing "ephemeral" keys for performance turns them into unmanaged static keys.
• Static key ownership: an encapsulator using another party's static encapsulation key must have assurance that the other party owns it, typically through a certificate or proof of possession. This is where ML-KEM meets PKI and identity.
• Key confirmation: recommended rather than required. Where used, it must be done with an approved MAC (HMAC, AES-CMAC or KMAC) and a key-confirmation key used only for that purpose.
• Side channels: SP 800-227 calls for constant-time, side-channel resistant implementations and secure storage of private data. Hand-rolled lattice code is a poor idea; use a maintained library or a validated module.
• Test hooks: some libraries expose deterministic inputs for testing. OpenSSL 3.5, which added ML-KEM, documents an "ikme" parameter for this and warns it should not be used other than for testing; supplying it makes the FIPS approved indicator return 0. Search production code for such parameters.

Hybrid key exchange and key combiners

Most deployments today combine ML-KEM with a classical exchange so that the session stays secure if either component holds. NIST IR 8547 (initial public draft, November 2024) describes hybrids as adding complexity and cost and as typically temporary, followed by a later move to post-quantum only, and says FIPS 140 validation will accommodate hybrid schemes where one component is NIST-approved. The NCSC notes that browsers already use a hybrid of traditional and ML-KEM key exchange. The NSA, by contrast, says it will not require hybrid for security purposes under CNSA 2.0.

These groups are specified in draft-ietf-tls-ecdhe-mlkem. As checked on 27 October 2026 the current version is -04 (8 February 2026), in the RFC Editor queue but not yet published as an RFC, so codepoints are stable but wording can still change. Note that X25519MLKEM768 places the ML-KEM share first "for historical reasons", the reverse of the other two. For protocol detail and rollout, see the Hybrid Post-Quantum TLS Key Exchange Guide.

• Use an approved combiner: SP 800-227 requires an approved key combiner for multi-algorithm schemes, drawn from SP 800-56C or SP 800-133, and at least one shared secret must come from an approved scheme.
• Bind the transcript: SP 800-227 cautions that simply running a KDF over two shared secrets does not preserve IND-CCA security in every construction, and recommends hashing the secrets together with the ciphertexts, encapsulation keys and a domain separator. FIPS 203 itself warns that a combined KEM built with an SP 800-56C KDF might not meet IND-CCA2. In TLS 1.3 the handshake transcript provides this binding; in custom protocols you must design it.
• Do not invent a hybrid: the NSA FAQ says non-standardised hybrid solutions should not be used on national security mission systems. For everyone else, prefer IETF-specified constructions (TLS groups, the IKEv2 additional key exchange approach, HPKE and SSH profiles as they standardise) over bespoke designs.

Where ML-KEM shows up first

Symmetric cryptography is not the problem: AES-256 and SHA-2 or SHA-3 at appropriate sizes remain fine. The work is in the public-key exchange that delivers the symmetric key. See the How TLS Works Guide for where key exchange sits in the handshake.

How to implement: a phased approach

1. Inventory key establishment: list every protocol endpoint that uses RSA key transport, DH or ECDH, with library and version. Feed this from network scans, certificate and configuration data and a CBOM. See the Cryptographic Inventory and CBOM Guide.
2. Rank by data lifetime: prioritise flows carrying data that must stay confidential beyond the early 2030s, and links an adversary could easily record (internet-facing, cross-border, cloud interconnects).
3. Upgrade libraries first: move to versions that implement FIPS 203 ML-KEM, not pre-standard Kyber. Confirm the default groups and whether ML-KEM is enabled by default or needs configuration.
4. Test in a lab with real middleboxes: enable the hybrid group on a test endpoint and pass traffic through firewalls, load balancers, TLS inspection, IDS and old clients. Watch for handshake failures caused by larger ClientHello messages.
5. Pilot in rings: offer the hybrid group on a small share of servers or clients, keep classical groups as fallback, and compare handshake failure rates and latency against a control group.
6. Roll out and prefer hybrid: once failure rates match the control, make the hybrid group preferred. Rolling back is a configuration change that removes the group from the preference list, so keep that change scripted and tested.
7. Move key storage: where ML-KEM keys are static (for example KEM-based key wrapping), put decapsulation keys or seeds in an HSM or KMS that supports them. See the HSM Deployment and Operations Guide.
8. Plan the end state: track NIST IR 8547, which in its draft proposes deprecating 112-bit RSA, DH and ECDH key establishment after 2030 and disallowing quantum-vulnerable key establishment after 2035, and the NCSC milestones of 2028 (discovery and plan), 2031 (priority migrations) and 2035 (complete). Hybrids should be removable without another redesign.

Procurement: what to ask suppliers

• Standard and parameter sets: which FIPS 203 parameter sets are implemented, which is the default, and whether pre-standard Kyber has been removed or disabled.
• Validation: algorithm validation and FIPS 140-3 module validation status for the ML-KEM implementation, with certificate numbers, not "in process" claims. See the FIPS 140-3 and Cryptographic Module Validation Guide.
• Hybrid support: which IETF hybrid groups or methods are supported in each protocol the product speaks (TLS, SSH, IKEv2), and how preference order is configured.
• Implementation quality: input checking, constant-time decapsulation, side-channel testing, seed versus expanded key storage, and how errata in FIPS 203 or protocol drafts will be handled.
• Agility: whether algorithms and groups can be changed by configuration or firmware without hardware replacement, and the support period for that firmware. See the Crypto-Agility Guide.
• Contract terms: put the answers into the contract, which maps to NIST SP 800-53 SA-4 (Acquisition Process) and CSF 2.0 GV.SC-05.

Where identity fits

Most ML-KEM traffic is between machines: services, workloads, devices and agents using mTLS, SSH and VPN tunnels. Static KEM keys need an owner, a lifecycle and assurance of ownership, which is the same discipline as any machine credential. When you add post-quantum key exchange to service mesh or workload identity systems, update the inventory of machine identities and their certificates at the same time. See the Post-Quantum Migration for NHIs Guide and the Cryptographic Key Management Guide.

Detection and measurement

• Negotiated group logging: log the TLS group per handshake on load balancers, reverse proxies and service mesh sidecars, so you can measure hybrid adoption directly.
• Handshake failure monitoring: alert on rises in handshake failures, fragmented ClientHello drops and resets after enabling hybrid groups, broken down by client type and network path.
• Library drift: scan software inventories and SBOMs for cryptographic libraries below the version that implements FIPS 203.
• Downgrade signs: watch for clients that offer hybrid groups but end up negotiating classical-only, which can indicate a middlebox stripping groups.

Framework mapping

Common failure patterns

• Shipping pre-standard Kyber: products that implemented draft Kyber in 2022 or 2023 and still advertise "post-quantum" are not FIPS 203 compliant and will not interoperate with ML-KEM peers.
• Breaking on larger handshakes: TLS inspection devices, old load balancers and firewalls that assume a ClientHello fits in one packet drop hybrid handshakes, and teams roll back without fixing the device. See the TLS Inspection Guide.
• Treating the seed as harmless: storing the 64-byte (d, z) seed in configuration or a database because it "is not the key", when FIPS 203 requires it to be protected exactly like the decapsulation key.
• Bespoke hybrid constructions: concatenating two shared secrets and hashing them without binding ciphertexts and public keys, against SP 800-227 advice.
• Reusing ephemeral keys: caching KEM key pairs across sessions to save CPU, which violates SP 800-227 and leaves keys nobody manages.
• Declaring victory at the edge: enabling hybrid TLS on the CDN while internal links, VPNs, backups and partner connections still rely on ECDH and RSA alone.

Practitioner checklist

• Record ML-KEM-768 (or ML-KEM-1024 where CNSA 2.0 or long data lifetimes apply) as the default in your cryptography standard, with ML-KEM-512 by exception only.
• Inventory every RSA, DH and ECDH key establishment endpoint and rank them by data confidentiality lifetime.
• Upgrade cryptographic libraries to FIPS 203 implementations and remove pre-standard Kyber.
• Enable X25519MLKEM768 (or the NIST-curve hybrids where required) in a lab, then pilot behind real middleboxes.
• Log the negotiated TLS group and handshake failures, and compare hybrid against a control group.
• Protect ML-KEM decapsulation keys and seeds in an HSM or KMS, and confirm ephemeral keys are single use.
• Use only IETF-specified hybrid constructions and SP 800-227 approved combiners; review any custom protocol.
• Add FIPS 203, validation evidence and crypto-agility requirements to supplier contracts.
• Watch the FIPS 203 errata, the draft-ietf-tls-ecdhe-mlkem status and the final version of NIST IR 8547.

Standards and references

• NIST: FIPS 203, Module-Lattice-Based Key-Encapsulation Mechanism Standard
• NIST: SP 800-227, Recommendations for Key-Encapsulation Mechanisms
• NIST: IR 8547 (Initial Public Draft), Transition to Post-Quantum Cryptography Standards
• IETF: Post-quantum hybrid ECDHE-MLKEM Key Agreement for TLSv1.3 (Internet-Draft)
• NCSC: Timelines for migration to post-quantum cryptography
• NSA: The Commercial National Security Algorithm Suite 2.0 and Quantum Computing FAQ
• OpenSSL: EVP_KEM-ML-KEM manual page
• NIST: SP 800-53 Rev. 5

Related NHI Mgmt Group resources: Post-Quantum Cryptography Migration Guide · Hybrid Post-Quantum TLS Key Exchange Guide · Crypto-Agility Guide · Cryptographic Inventory and CBOM Guide · Post-Quantum Migration for NHIs Guide