FIPS 203 is the NIST standard that specifies ML-KEM, the Module-Lattice-Based Key-Encapsulation Mechanism, a post-quantum algorithm for establishing shared secret keys between two systems. NIST published it on August 13, 2024, alongside FIPS 204 and FIPS 205 for digital signatures. ML-KEM is the post-quantum replacement for the key exchange that RSA and elliptic curve Diffie-Hellman provide today, and it sits at the center of the federal transition deadlines now in place.
This article explains what FIPS 203 specifies, why it matters to compliance programs as well as to engineers, and how organizations are adopting it.
What FIPS 203 and ML-KEM Specify
A key-encapsulation mechanism lets two parties agree on a shared secret over an untrusted channel. One party publishes an encapsulation key; the other uses it to produce a ciphertext and a shared secret; the first recovers the same secret from the ciphertext with its decapsulation key. That shared secret then keys symmetric encryption such as AES for the rest of the session. ML-KEM defines three operations, key generation, encapsulation, and decapsulation, and fixes the shared secret at 256 bits.
ML-KEM is derived from CRYSTALS-Kyber, one of the algorithms selected through NIST’s multi-year post-quantum standardization process. Its security rests on the difficulty of a lattice problem called module learning with errors, which is not known to be efficiently solvable by quantum computers.
The Three Parameter Sets
| Parameter set | NIST security category | Encapsulation key size | Ciphertext size | Typical use |
|---|---|---|---|---|
| ML-KEM-512 | 1 (comparable to AES-128) | 800 bytes | 768 bytes | Constrained environments where category 1 suffices |
| ML-KEM-768 | 3 (comparable to AES-192) | 1,184 bytes | 1,088 bytes | The common default for general enterprise use |
| ML-KEM-1024 | 5 (comparable to AES-256) | 1,568 bytes | 1,568 bytes | Required under CNSA 2.0 for national security systems |
The table shows the main operational change from classical key exchange: size. An elliptic curve public key is a few dozen bytes; ML-KEM keys and ciphertexts run to more than a kilobyte. That rarely matters for a web session, but it can affect constrained devices, protocols with tight message limits, and network equipment that inspects handshakes. Choosing the parameter set is usually a policy decision rather than an engineering one: national security systems follow CNSA 2.0, and most other programs choose ML-KEM-768 unless a customer or regulator specifies otherwise.
How It Relates to the Other Standards
FIPS 203 covers key establishment only. FIPS 204 (ML-DSA) and FIPS 205 (SLH-DSA) cover digital signatures. In March 2025 NIST also selected HQC, a code-based algorithm built on different mathematics, as a backup key-encapsulation mechanism; it is intended as insurance in case a weakness is ever found in lattice-based schemes, not as a replacement for ML-KEM.
Why FIPS 203 Matters to Compliance Programs
For most organizations outside government, post-quantum cryptography was an engineering roadmap item until recently. Federal policy has since turned FIPS 203 into a compliance reference point, because the deadlines that now exist are deadlines for key establishment, and ML-KEM is the standardized way to meet them.
The Federal Deadlines Point to It
Executive Order 14412, signed June 22, 2026, requires agencies to move their high value assets and high impact systems to post-quantum key establishment by December 31, 2030, and to post-quantum digital signatures by December 31, 2031. It also directs the FAR Council to propose a rule requiring covered contractors to comply with NIST’s post-quantum FIPS standards by December 31, 2030. For key establishment, that means FIPS 203. NIST’s final transition report, NIST IR 8547, published October 27, 2026, maps the quantum-vulnerable key establishment schemes in current NIST standards to ML-KEM as their replacement.
Validated Modules Are the Practical Constraint
Federal programs rarely accept an algorithm on its own; they expect it inside a cryptographic module validated under the NIST Cryptographic Module Validation Program to FIPS 140-3. Validation takes time, and post-quantum modules are newer than the classical modules most products use. Published analyses of Executive Order 14412 report that it also directs NIST to speed up validation of post-quantum modules. Until validated ML-KEM implementations are widely available in the products an organization uses, adoption plans have to account for which modules are validated and which are not.
Hybrid Deployment Fits the Rules as Proposed
The most common path today is hybrid key exchange, which combines a classical algorithm with ML-KEM so the session stays secure if either one holds. FedRAMP’s RFC-0035, open for comment until November 17, 2026, addresses this directly: under the proposal, adding a non-validated algorithm while a validated module still protects federal customer data, as in a hybrid implementation, would not be treated as a transformative change. That gives cloud providers a defined way to add ML-KEM without dropping the validated cryptography their agency customers rely on.
National Security Systems Have Their Own Rule
For national security systems, the NSA’s Commercial National Security Algorithm Suite 2.0 sets the requirement, and it specifies ML-KEM-1024. Defense contractors that build or operate those systems follow CNSA 2.0 rather than choosing a parameter set themselves.
How Organizations Are Adopting FIPS 203
Most organizations will not implement ML-KEM themselves. They will receive it through the platforms, libraries, browsers, and network equipment they already use, many of which have added hybrid key exchange that includes ML-KEM. The compliance work is knowing where it applies, confirming it is turned on and validated where required, and documenting it.
Step 1: Start From the Cryptographic Inventory
Adoption decisions depend on knowing where key establishment happens: TLS endpoints, VPNs, service-to-service connections, key management systems, and file transfer. Elevate’s guide to building a cryptographic inventory covers the fields to record.
Step 2: Prioritize Long-Lived Data
Key establishment that protects data with a long confidentiality requirement is exposed today to collection and later decryption. Those paths should move to hybrid ML-KEM first. Elevate’s explainer on harvest now, decrypt later covers how to identify them.
Step 3: Choose the Parameter Set by Policy
Use ML-KEM-1024 where CNSA 2.0 applies, and follow customer or regulator requirements elsewhere. Where nothing is specified, ML-KEM-768 is the common choice. Record the decision so assessors can see why a parameter set was used.
Step 4: Ask Vendors the Right Questions
For each product that terminates encrypted connections, ask whether it supports hybrid key exchange with ML-KEM, which parameter sets, whether the implementation sits in a FIPS 140-3 validated module or is in validation, and when it will be on by default. The answers separate what the organization can enable now from what depends on vendor roadmaps.
Step 5: Test Before Turning It On Everywhere
Larger keys and ciphertexts can break older middleboxes, load balancers, or devices with tight message limits. Test hybrid key exchange on representative traffic paths before enabling it broadly, and keep a rollback path.
Step 6: Document It in the Compliance Record
For FedRAMP providers, the CR26 rules already require documenting the cryptographic modules used to protect federal customer data, including whether they are validated. Adding ML-KEM should appear there, with the hybrid configuration described, so agencies can see where and how it is used. Elevate’s overview of the FedRAMP Consolidated Rules for 2026 explains those documentation rules.
Elevate helps cloud providers prepare FedRAMP documentation and assessments through its FedRAMP services. To review where ML-KEM fits in your environment, talk to an Elevate advisor.
Conclusion
FIPS 203 standardizes ML-KEM, the post-quantum mechanism that replaces RSA and elliptic curve key exchange. It has three parameter sets, a larger footprint than classical keys, and, since 2026, a place at the center of federal deadlines: post-quantum key establishment for the government’s most sensitive systems by the end of 2030, with a contractor rule to follow.
For most organizations the work is not cryptographic engineering. It is knowing where key establishment happens, moving long-lived data paths to hybrid ML-KEM first, confirming validation status with vendors, and recording the configuration where assessors and customers can see it. To plan that work for your environment, book a call with an Elevate advisor.
Key Takeaways
FIPS 203 defines ML-KEM, the NIST standard for post-quantum key establishment.
- Published August 13, 2024. It was finalized alongside FIPS 204 and FIPS 205 for digital signatures.
- Three parameter sets. ML-KEM-512, 768, and 1024 map to NIST security categories 1, 3, and 5.
- CNSA 2.0 requires ML-KEM-1024. National security systems follow the NSA suite; ML-KEM-768 is the common choice elsewhere.
- Federal deadlines center on it. Executive Order 14412 sets December 31, 2030 for post-quantum key establishment on high value assets and high impact systems.
- Validation is the practical constraint. Federal programs expect ML-KEM inside FIPS 140-3 validated modules.
- Hybrid is the path today. FedRAMP’s RFC-0035 would not treat a hybrid addition alongside a validated module as a transformative change.
Frequently Asked Questions
What is FIPS 203?
FIPS 203 is the NIST Federal Information Processing Standard that specifies ML-KEM, the Module-Lattice-Based Key-Encapsulation Mechanism. It defines how two systems establish a shared secret key in a way believed to resist attacks by quantum computers. NIST published it on August 13, 2024, and it is derived from the CRYSTALS-Kyber algorithm.
What is the difference between ML-KEM and Kyber?
ML-KEM is the standardized version of CRYSTALS-Kyber, the algorithm NIST selected in its post-quantum competition. The final standard made changes during standardization, including fixing the shared secret at 256 bits and adjusting some internal steps, so ML-KEM and earlier Kyber implementations are not interchangeable. Products should implement ML-KEM as specified in FIPS 203.
Which ML-KEM parameter set should I use?
Use ML-KEM-1024 where CNSA 2.0 applies, such as national security systems. Elsewhere, follow customer or regulator requirements; where none apply, ML-KEM-768, at NIST security category 3, is the common choice. ML-KEM-512 suits only constrained environments where category 1 is sufficient.
Is FIPS 203 required for federal contractors?
Not yet as a general contract requirement. Executive Order 14412 directs the FAR Council to propose a rule requiring covered contractors to comply with NIST’s post-quantum FIPS standards, including FIPS 203, by December 31, 2030. Agencies themselves must move their high value assets and high impact systems to post-quantum key establishment by the same date.
Does FedRAMP require ML-KEM?
No. FedRAMP has not set post-quantum requirements, and RFC-0035 states that it does not set any. The proposal would allow providers to add post-quantum algorithms such as ML-KEM at agency request, and it would not treat a hybrid addition alongside a validated module as a transformative change. Its comment period closes on November 17, 2026.