Key takeaways
- FIPS 203 — ML-KEM (Table 2/3): three parameter sets, named for their matrix dimension k, in order of increasing security strength and decreasing performance.
- IR 8547 ties this timeline to National Security Memorandum 10, which set 2035 as the U.S.
In August 2024, NIST finalized the first three outputs of its Post-Quantum Cryptography (PQC) Standardization project, running since 2016: FIPS 203 (ML-KEM, key establishment), FIPS 204 (ML-DSA, digital signatures) and FIPS 205 (SLH-DSA, backup digital signatures). All three protect against a future large-scale quantum computer capable of breaking the RSA and elliptic-curve cryptography that secures most of today's TLS, firmware signing and secure-boot chains. NIST's own framing of urgency is blunt: these standards "can and should be put into use now," and a follow-on document, NIST IR 8547, has since attached hard 2030/2035 dates to the migration away from the algorithms ML-KEM, ML-DSA and SLH-DSA are meant to replace.
The three standards and what each one does
| Standard | Algorithm | Function | Based on | Published |
|---|---|---|---|---|
| FIPS 203 | ML-KEM | Key-encapsulation mechanism (establishing a shared secret key) | CRYSTALS-Kyber | 13 Aug 2024 |
| FIPS 204 | ML-DSA | Digital signatures | CRYSTALS-Dilithium | 13 Aug 2024 |
| FIPS 205 | SLH-DSA | Digital signatures (structurally independent backup) | SPHINCS+ | 13 Aug 2024 |
Per FIPS 203's own Abstract, a key-encapsulation mechanism (KEM) is "a set of algorithms that, under certain conditions, can be used by two parties to establish a shared secret key over a public channel," with that shared key then used by conventional symmetric-key cryptography for encryption and authentication. ML-KEM's security rests on the Module Learning With Errors (MLWE) problem, which is "believed to be secure, even against adversaries who possess a quantum computer." FIPS 204 and FIPS 205 both address digital signatures but deliberately rest on unrelated hardness assumptions — ML-DSA on structured lattice problems like ML-KEM, SLH-DSA purely on the security of its underlying hash functions — so a cryptanalytic advance against lattice-based math would not simultaneously compromise both NIST-approved signature options. All three are FIPS publications issued by NIST's Information Technology Laboratory with no individually credited authors; each is approved by the Secretary of Commerce and, per its own Applicability clause, available for voluntary adoption by private and commercial organizations even though FIPS formally governs U.S. federal information systems.
Parameter sets, key sizes and signature sizes
FIPS 203 — ML-KEM (Table 2/3): three parameter sets, named for their matrix dimension k, in order of increasing security strength and decreasing performance.
| Parameter set | Security category | Encapsulation key | Decapsulation key | Ciphertext |
|---|---|---|---|---|
| ML-KEM-512 | 1 | 800 bytes | 1,632 bytes | 768 bytes |
| ML-KEM-768 (NIST's recommended default) | 3 | 1,184 bytes | 2,400 bytes | 1,088 bytes |
| ML-KEM-1024 | 5 | 1,568 bytes | 3,168 bytes | 1,568 bytes |
NIST's own guidance in Section 8 of FIPS 203 is explicit: "NIST recommends using ML-KEM-768 as the default parameter set, as it provides a large security margin at a reasonable performance cost," reserving ML-KEM-1024 for cases needing even higher assurance and ML-KEM-512 for the most resource-constrained settings.
FIPS 204 — ML-DSA (Table 1/2): three parameter sets, named ML-DSA-kl for the dimensions of the matrix they use.
| Parameter set | Security category | Private key | Public key | Signature |
|---|---|---|---|---|
| ML-DSA-44 | 2 | 2,560 bytes | 1,312 bytes | 2,420 bytes |
| ML-DSA-65 | 3 | 4,032 bytes | 1,952 bytes | 3,309 bytes |
| ML-DSA-87 | 5 | 4,896 bytes | 2,592 bytes | 4,627 bytes |
FIPS 205 — SLH-DSA (Table 2): twelve parameter sets — six security-parameter/variant combinations, each available in a SHA2-based or SHAKE-based hash instantiation. The "s" suffix optimizes for a smaller signature; the "f" suffix optimizes for faster signing at the cost of a larger signature. Public keys are small and constant per security level (32, 48 or 64 bytes; private keys are double that), but signatures are the largest of any of the three standards:
| Parameter set family | Security category | Signature size |
|---|---|---|
| SLH-DSA-*-128s / 128f | 1 | 7,856 bytes / 17,088 bytes |
| SLH-DSA-*-192s / 192f | 3 | 16,224 bytes / 35,664 bytes |
| SLH-DSA-*-256s / 256f | 5 | 29,792 bytes / 49,856 bytes |
FIPS 205 §11 flags one nuance worth knowing before picking a variant: all twelve parameter sets meet their claimed EUF-CMA security category, "except SLH-DSA-SHA2-128f and SLH-DSA-SHAKE-128f" for the specific property of message-bound signatures (resistance to one key/signature pair validating two different messages) — applications that need that property should either account for it when choosing a parameter set or apply NIST's referenced BUFF transformation.
Why these sizes matter for firmware and constrained devices
Every one of these algorithms produces keys, ciphertexts or signatures that are larger than the RSA/ECC equivalents they replace — an ML-KEM-768 ciphertext (1,088 bytes) dwarfs a typical ECDH exchange, and even the smallest SLH-DSA signature (7,856 bytes) is an order of magnitude larger than a 64-128 byte ECDSA signature. For firmware images, secure-boot chains, TLS handshakes over constrained links, and any protocol with fixed-size packet or header budgets, this is not a drop-in swap: image/partition layouts, bootloader buffer sizes, handshake round-trip budgets and OTA-update payload sizes may all need to be re-evaluated before a PQC migration can ship. FIPS 203 §8 explicitly flags that parameter-set choice is itself a performance/security tradeoff, not just a security one — a reason NIST's own default recommendation (ML-KEM-768) exists as a starting point rather than a one-size answer.
The 2030/2035 migration deadlines
NIST IR 8547, "Transition to Post-Quantum Cryptography Standards," reached final publication in October 2026 (authors Dustin Moody, Ray Perlner, Andrew Regenscheid, Angela Robinson and David Cooper of NIST's Computer Security Division), and sets out the dates NIST intends to retire the algorithms ML-KEM, ML-DSA and SLH-DSA are meant to replace:
| Algorithm family | ≤112-bit security | ≥128-bit security |
|---|---|---|
| RSA, ECDSA, EdDSA (signatures) | Deprecated after 2030, disallowed after 2035 | Disallowed after 2035 |
| Finite-field/elliptic-curve DH and MQV, RSA key transport (key establishment) | Deprecated after 2030, disallowed after 2035 | Disallowed after 2035 |
IR 8547 ties this timeline to National Security Memorandum 10, which set 2035 as the U.S. government's overall target for mitigating quantum risk, and notes that OMB direction requires federal agencies' most sensitive systems to adopt PQC for key establishment by 31 December 2030 and for digital signatures by 31 December 2031 — both earlier than the general 2035 disallowal date. These deadlines formally bind NIST's own standards and U.S. federal procurement rather than private industry worldwide, but they propagate outward through FIPS 140-3/CMVP's approved-algorithm lists and through sector regulators and large government-adjacent buyers who reference NIST guidance — so a device or firmware vendor with any federal, critical-infrastructure or FIPS-140-adjacent customer base should treat 2030 as the point to have a tested migration path, not just a slide in a roadmap deck.
A workable starting point
Treat this as a hardware and protocol question, not just a software patch— ML-KEM/ML-DSA/SLH-DSA's larger keys and signatures can overflow fixed buffers, bootloader partitions, and handshake budgets that were sized for RSA/ECC; audit those constraints before committing to a migration timeline. Default to ML-KEM-768 and ML-DSA-65 unless you have a specific reason not to— these are NIST's own recommended-default security category (3), balancing margin against size/performance cost; drop to the smaller sets only where measured resource constraints force it. Reach for SLH-DSA only where a structurally independent signature scheme is worth its much larger signature size— e.g., as a long-lived root-of-trust or firmware-signing backup where lattice-cryptography risk diversification matters more than bandwidth. Build a crypto-agility story now, not at the 2030 deadline— IR 8547's deprecate-then-disallow structure gives a multi-year runway, but firmware and hardware product cycles are long enough that waiting until 2029 to start is not a safe plan for a product shipping today. Track NIST's still-moving PQC roadmap— FN-DSA (the Falcon-derived FIPS 206) and HQC (a fourth-round KEM selected in 2025) are additional standards in progress; don't assume ML-KEM/ML-DSA/SLH-DSA are the final word on NIST's approved PQC algorithm set.
SoftWSP's device and firmware security assessments review whether a product's crypto stack and update/boot chain can actually accommodate a post-quantum migration — buffer sizes, handshake budgets and key-management design — not just whether the right algorithm names appear in a spec sheet: see Device & Firmware Security.
This guide summarizes NIST's own published FIPS 203, 204 and 205 texts, NIST's August 2024 announcement, and NIST IR 8547's final (October 2026) transition guidance; it is not a substitute for the full standards or for cryptographic implementation review.
Sources
- NIST: FIPS 203, Module-Lattice-Based Key-Encapsulation Mechanism Standard (final, 13 August 2024) — full text, Abstract, Tables 1-3
- NIST: FIPS 204, Module-Lattice-Based Digital Signature Standard (final, 13 August 2024) — full text, Table 1 (parameters), Table 2 (sizes)
- NIST: FIPS 205, Stateless Hash-Based Digital Signature Standard (final, 13 August 2024) — full text, Table 2 (parameter sets)
- NIST: "NIST Releases First 3 Finalized Post-Quantum Encryption Standards" (13 August 2024 announcement — rationale, Moody/Locascio quotes, migration advice)
- NIST IR 8547: Transition to Post-Quantum Cryptography Standards (final, October 2026; Moody, Perlner, Regenscheid, Robinson, Cooper) — deprecation/disallowal tables
- NIST: Post-Quantum Cryptography project page (timeline, FN-DSA/FIPS 206 and HQC status, "can and should be put into use now")
Frequently asked questions
What are FIPS 203, 204 and 205, and when were they published?
Three Federal Information Processing Standards NIST published on 13 August 2024, the first finalized outputs of NIST's Post-Quantum Cryptography Standardization project (running since 2016). FIPS 203, "Module-Lattice-Based Key-Encapsulation Mechanism Standard," specifies ML-KEM (derived from CRYSTALS-Kyber) for establishing a shared secret key, stating ML-KEM "is believed to be secure, even against adversaries who possess a quantum computer." FIPS 204, "Module-Lattice-Based Digital Signature Standard," specifies ML-DSA (derived from CRYSTALS-Dilithium) for digital signatures. FIPS 205, "Stateless Hash-Based Digital Signature Standard," specifies SLH-DSA (based on SPHINCS+) as a structurally different backup signature scheme. All three are published by NIST's Information Technology Laboratory; as FIPS publications they carry no named individual authors, are approved by the Secretary of Commerce, and — per each standard's own Applicability clause — their "adoption and use ... are available to private and commercial organizations" even though FIPS formally applies to U.S. federal systems.
What parameter sets does each standard define, and how large are the keys/signatures?
Each standard defines three (ML-KEM, ML-DSA) or twelve (SLH-DSA) parameter sets spanning NIST security categories 1, 3 and 5. Per FIPS 203 Table 3: ML-KEM-512 uses an 800-byte encapsulation key, 1,632-byte decapsulation key and 768-byte ciphertext (category 1); ML-KEM-768 uses 1,184 / 2,400 / 1,088 bytes (category 3, and NIST's own recommended default); ML-KEM-1024 uses 1,568 / 3,168 / 1,568 bytes (category 5). Per FIPS 204 Table 2: ML-DSA-44 uses a 1,312-byte public key, 2,560-byte private key and 2,420-byte signature (category 2); ML-DSA-65 uses 1,952 / 4,032 / 3,309 bytes (category 3); ML-DSA-87 uses 2,592 / 4,896 / 4,627 bytes (category 5). Per FIPS 205 Table 2, SLH-DSA's twelve parameter sets (SHA2- or SHAKE-based, each in a small-signature "s" or fast-signing "f" variant) have much smaller keys (32-64 bytes) but far larger signatures: 128-bit variants run 7,856 bytes (128s) or 17,088 bytes (128f); 192-bit variants run 16,224 or 35,664 bytes; 256-bit variants run 29,792 or 49,856 bytes.
Why does NIST need three different standards instead of one?
Because they serve different functions and rest on different mathematical hardness assumptions, which is itself a risk-management choice. FIPS 203 (ML-KEM) solves key establishment; FIPS 204 (ML-DSA) and FIPS 205 (SLH-DSA) both solve digital signatures but are intentionally built on unrelated math: ML-DSA, like ML-KEM, relies on structured (module) lattice problems, while SLH-DSA relies only on the security of underlying hash functions. NIST's own August 2024 announcement frames FIPS 205 explicitly as a hedge — "an alternative to ML-DSA ... based on a different math approach ... in the event that ML-DSA turns out to be vulnerable" — so a future cryptanalytic break of lattice-based assumptions would not take down every NIST-approved post-quantum signature scheme at once. NIST computer scientist Dustin Moody was quoted encouraging early adoption: "We encourage system administrators to start integrating them into their systems immediately, because full integration will take time."
What are the migration deadlines, and do they apply outside the U.S. federal government?
NIST IR 8547, "Transition to Post-Quantum Cryptography Standards" (final, October 2026; authors Dustin Moody, Ray Perlner, Andrew Regenscheid, Angela Robinson and David Cooper, NIST Computer Security Division), sets concrete dates for today's quantum-vulnerable algorithms: RSA, (EC)DSA/EdDSA, and finite-field/elliptic-curve Diffie-Hellman and MQV at the 112-bit security level are **deprecated after 2030 and disallowed after 2035** under NIST standards and guidance; schemes at ≥128-bit security skip deprecation and are **disallowed outright after 2035**. IR 8547 ties this to National Security Memorandum 10, which set 2035 as the government-wide target, and notes OMB direction for agencies' most sensitive systems to adopt PQC for key establishment by 31 December 2030 and for signatures by 31 December 2031. These dates formally bind NIST publications and U.S. federal procurement, not private industry directly — but because FIPS 140-3/CMVP validation and many national/sector regulatory regimes reference NIST's approved-algorithm lists, vendors selling into regulated or government-adjacent supply chains should treat the same 2030/2035 horizon as a de facto product-roadmap deadline.
In this cluster
