The algorithm selection phase is over. NIST published FIPS 203, FIPS 204, and FIPS 205 on 13 August 2024, alongside a fourth standard, FIPS 206. Eight years of public evaluation, 69 initial submissions, and four evaluation rounds produced a set of answers that are now stable, published, and mandated by federal compliance frameworks. The question most security architects face is not whether to migrate but which standard applies to which workload and what each one actually requires.

The three primary standards divide cleanly by function. FIPS 203 covers key encapsulation. FIPS 204 and FIPS 205 cover digital signatures. They are not competing alternatives for the same job. A migration programme that treats them as interchangeable options has misread the specification.

NIST FIPS 203, 204, and 205 at a Glance Three-column comparison showing FIPS 203 ML-KEM for key encapsulation, FIPS 204 ML-DSA for digital signatures, and FIPS 205 SLH-DSA for hash-based signatures. Each column shows the standard number, algorithm name, cryptographic basis, primary use cases, and parameter set range. NIST FIPS 203 / 204 / 205: Function and Scope Published 13 August 2024. Three separate standards, three distinct functions. FIPS 203: ML-KEM FIPS 204: ML-DSA FIPS 205: SLH-DSA FUNCTION Key encapsulation FUNCTION Digital signatures FUNCTION Digital signatures CRYPTOGRAPHIC BASIS Module-LWE (lattice) CRYPTOGRAPHIC BASIS Module-LWE (lattice) CRYPTOGRAPHIC BASIS Cryptographic hash functions PRIMARY USE CASES TLS 1.3, SSH, IPsec IKEv2 PRIMARY USE CASES X.509 certs, code signing, auth tokens PRIMARY USE CASES Root CA, long-term trust anchors, supply chain ENTERPRISE DEFAULT ML-KEM-768 ENTERPRISE DEFAULT ML-DSA-65 ENTERPRISE DEFAULT SLH-DSA-SHA2-128s CNSA 2.0: ML-KEM-1024 CNSA 2.0: ML-DSA-87 CNSA 2.0: SLH-DSA-SHA2-256s ≠ ≠
The three NIST PQC standards address different cryptographic operations and are not interchangeable. FIPS 203 replaces RSA/ECDH in key exchange. FIPS 204 replaces RSA-PSS/ECDSA in signatures. FIPS 205 provides hash-based signature diversity where algorithm independence matters more than signature size.

FIPS 203: ML-KEM and the Key Exchange Problem

FIPS 203 specifies ML-KEM (Module-Lattice-Based Key-Encapsulation Mechanism), standardised from the Kyber competition submission. The standard name is ML-KEM. "Kyber" is the submission name and should not appear in compliance documentation or procurement language. The naming ambiguity creates genuine risk in policy contexts.

ML-KEM is a key encapsulation mechanism, not a general-purpose asymmetric cipher. It establishes a shared symmetric key between two parties over an untrusted channel without transmitting the key itself. The private key holder decapsulates the ciphertext to recover the shared secret; anyone else sees a random-looking value. The primary deployment contexts are TLS 1.3 key exchange, SSH key agreement, and IPsec IKEv2: any protocol where RSA or ECDH currently handles key establishment.

The security foundation is the Module Learning With Errors problem, a structured variant of the Learning With Errors (LWE) problem that Regev (2005, Journal of the ACM) showed to be at least as hard as worst-case lattice problems. No known quantum or classical polynomial-time algorithm solves MLWE. That is the hardness assumption the standard rests on.

FIPS 203 defines three parameter sets, each mapped to a NIST Security Category:

Parameter set NIST Security Category Public key (bytes) Ciphertext (bytes)
ML-KEM-512 Category 1 (AES-128 equivalent) 800 768
ML-KEM-768 Category 3 (AES-192 equivalent) 1,184 1,088
ML-KEM-1024 Category 5 (AES-256 equivalent) 1,568 1,568

For most enterprise deployments, ML-KEM-768 is the practical starting point. The size overhead versus ECDH is manageable in TLS handshakes, and the Category 3 security margin is appropriate for data without extreme long-term sensitivity requirements. NSA's Commercial National Security Algorithm Suite 2.0 (CNSA 2.0, September 2022) mandates ML-KEM-1024 for national security systems, with timelines running from immediate deployment for new systems through to 2030-2033 for legacy infrastructure. UK NCSC guidance (2024) supports ML-KEM-768 or higher as the baseline for UK organisations.

FIPS 204: ML-DSA and the Primary Signature Standard

FIPS 204 specifies ML-DSA (Module-Lattice-Based Digital Signature Algorithm), standardised from the Dilithium submission. ML-DSA is the primary digital signature standard in the suite and NIST's recommended default for most enterprise applications, including certificate signing, code signing, document signing, and authentication protocols. The migration target is any context where RSA-PSS, ECDSA, or EdDSA currently provides signature or authentication functionality.

The mathematical foundation is the same MLWE problem underlying ML-KEM. This is deliberate: a migration programme can be built around a single lattice-based hardness assumption, simplifying the cryptographic architecture. The trade-off, addressed in the section below, is that a breakthrough against MLWE would affect both ML-KEM and ML-DSA simultaneously.

FIPS 204 defines three parameter sets:

Parameter set NIST Security Category Public key (bytes) Signature (bytes)
ML-DSA-44 Category 2 1,312 2,420
ML-DSA-65 Category 3 1,952 3,293
ML-DSA-87 Category 5 2,592 4,595

ML-DSA-65 is the enterprise default for most applications. ML-DSA-87 is required under CNSA 2.0 for national security systems.

The size increase relative to ECDSA is the figure that stops architects. A P-256 ECDSA signature is 64 bytes. An ML-DSA-65 signature is 3,293 bytes: roughly 50 times larger. This matters in contexts where signature size or bandwidth is a constraint. TLS certificate chains, particularly those with intermediate CA certificates, grow substantially during migration. Protocol testing for ML-DSA in certificate infrastructure is not optional; it is load-bearing work. The overhead is manageable in most deployment contexts, but it requires capacity planning, not assumption.

FIPS 205: SLH-DSA and the Diversity Requirement

FIPS 205 specifies SLH-DSA (Stateless Hash-Based Digital Signature Algorithm), standardised from the SPHINCS+ submission. SLH-DSA is the most conservatively founded standard in the suite. Its security depends entirely on the properties of cryptographic hash functions (SHA-256, SHA-512, and SHAKE variants) rather than any structured algebraic problem. The security argument, established in Bernstein et al.'s SPHINCS+ specification (2022), is straightforward: if the underlying hash function is collision-resistant, SLH-DSA signatures are secure. There is no MLWE assumption to break.

This is why NIST standardised SLH-DSA alongside ML-DSA rather than instead of it. FIPS 204 and FIPS 205 are not interchangeable in the same use case. They serve complementary purposes. If a theoretical weakness in MLWE is discovered (which has not happened, but is the relevant failure mode to plan against), ML-DSA deployments are affected and SLH-DSA deployments are not. Algorithm diversity is the explicit rationale.

The trade-off is signature size. FIPS 205 defines 12 parameter sets across three hash function families and two performance modes (small signatures vs fast signing). Selected figures:

Parameter set NIST Security Category Signature (bytes) Signing speed
SLH-DSA-SHA2-128s Category 1 7,856 Slow
SLH-DSA-SHA2-128f Category 1 17,088 Fast
SLH-DSA-SHA2-256s Category 5 29,792 Slow

CNSA 2.0 mandates SLH-DSA-SHA2-256s for national security systems. For enterprise use, the appropriate parameter set depends on the specific application. The 's' suffix denotes small signatures at the cost of slower signing; 'f' denotes fast signing at the cost of larger signatures. SLH-DSA-SHA2-128s at 7,856 bytes is still four times larger than the largest ML-DSA parameter set. SLH-DSA-SHA2-256s at 29,792 bytes is not a candidate for any throughput-constrained application.

The use cases for SLH-DSA are specific. Root certificate authority key operations, long-term trust anchors, and software supply chain code signing are where SLH-DSA belongs: contexts where signature size is not the binding constraint and algorithm diversity against a lattice-problem weakness is the security priority. High-throughput authentication, TLS certificate chains, and document signing pipelines are not its terrain. In every migration programme I have worked on, this distinction is where the most expensive deployment errors originate.

What the Three Standards Do Not Cover

FIPS 203, 204, and 205 are not the complete NIST PQC suite. FIPS 206, standardised simultaneously, specifies FN-DSA (Module-Lattice-Based Digital Signature Algorithm from the FALCON submission), which uses NTRU lattice problems and produces smaller signatures than ML-DSA at the cost of more complex, sampling-sensitive implementation. FN-DSA fills a niche (primarily firmware signing and embedded environments where signature size is the binding constraint) but is not the recommended starting point for general enterprise migration.

None of the three primary standards specify hybrid classical/post-quantum constructions. Operating ML-KEM-768 in parallel with X25519 during the transition period, so that security is maintained if either algorithm has an undiscovered weakness, requires the protocol-level specifications in NIST IR 8547 (Initial Public Draft, 2024) and the IETF hybrid KEM drafts (draft-ietf-tls-hybrid-design). ETSI TS 103 744 provides European alignment on hybrid deployment. The three FIPS standards define the algorithms. The transition documents define the migration architecture.

Stateful hash-based signatures, specifically XMSS and LMS, which use hash-based constructions with stateful key management, are covered separately in NIST SP 800-208 (October 2020). These are not replacements for FIPS 205; they serve different use cases and come with their own operational requirements around state management.

Deployment Decision Framework

The interaction between algorithm, parameter set, compliance framework, and use case is where migration planning becomes concrete. The table below maps the primary enterprise deployment contexts against the appropriate standard and parameter set:

Use case Standard Enterprise default CNSA 2.0 requirement
TLS 1.3 key exchange, SSH, IPsec IKEv2 ML-KEM (FIPS 203) ML-KEM-768 ML-KEM-1024
X.509 certificate signing, code signing, authentication tokens ML-DSA (FIPS 204) ML-DSA-65 ML-DSA-87
Root CA operations, long-term trust anchors SLH-DSA (FIPS 205) SLH-DSA-SHA2-128s SLH-DSA-SHA2-256s
Firmware signing, constrained embedded environments FN-DSA (FIPS 206) Per NCSC guidance CNSA 2.0 specifies per system type
Algorithm Selection Decision Flow: FIPS 203, 204, 205 A decision flowchart guiding the selection of NIST PQC algorithms. Starting from the question of whether the operation is key exchange or authentication/signing, it branches to ML-KEM for key exchange and then to ML-DSA versus SLH-DSA for signatures based on whether the use case prioritises signature size or algorithm independence. Algorithm Selection Decision Flow Which FIPS standard for which workload What operation? Key exchange / encryption? YES ML-KEM FIPS 203 PARAMETER SET Enterprise: -768 CNSA 2.0: -1024 TLS / SSH / IKEv2 NO (signing) Algorithm independence priority? NO ML-DSA FIPS 204 PARAMETER SET Enterprise: -65 | CNSA: -87 YES SLH-DSA FIPS 205 PARAMETER SET Root CA / CNSA: -SHA2-256s ML-DSA and SLH-DSA are not interchangeable
Algorithm selection follows function, not preference. ML-KEM addresses key exchange; ML-DSA and SLH-DSA both address signatures but serve different risk profiles. Selecting one signature standard does not fulfil the requirement for the other.

The Compliance Picture

The regulatory position varies by jurisdiction and sector, but the direction is uniform across every major standards body.

For US federal agencies, FIPS algorithms are required under FISMA, and the migration mandate is in NSM-10 (The White House, May 2022): prioritised systems by 2030, with CNSA 2.0 specifying ML-KEM-1024 and ML-DSA-87 for national security systems. NIST IR 8547 (Initial Public Draft, 2024) sets the RSA and ECC deprecation timeline for federal use: deprecated for new systems after 2030, disallowed entirely including legacy interoperability after 2035. Organisations with US federal contracts or supply chain obligations should note that CNSA 2.0 compliance requirements extend through the defence industrial base.

UK NCSC guidance (2024) endorses FIPS 203, 204, and 205 for interoperability with US and allied systems and recommends Category 3 or higher as the baseline for commercial organisations. NCSC does not impose binding timelines on the commercial sector, but its position is unambiguous: post-quantum migration is a current-term priority.

In Europe, ETSI TS 119 312 V1.4.1 (October 2023) provides the European framework for algorithm suitability in electronic signatures and seals, aligned with the NIST selections. ETSI's Quantum Safe Cryptography working group publications provide the technical basis for EU organisations assessing compliance obligations under NIS2 and related frameworks.

Three misconceptions are worth addressing directly before any migration programme begins. First: ML-KEM, ML-DSA, and SLH-DSA are not interchangeable options. They address different cryptographic operations and the selection of one does not replace the need for the others. Second: "Kyber," "Dilithium," and "SPHINCS+" are competition submission names. Using them in policy, procurement, or compliance documentation introduces ambiguity. The correct names are ML-KEM, ML-DSA, and SLH-DSA. Third: waiting for Round 4 alternate candidates (BIKE, HQC) to be standardised is not a risk-neutral position when HNDL attacks are ongoing and regulatory deadlines are fixed. FIPS 203, 204, and 205 are stable, production-ready, and already mandated.

Selecting the right parameter set for a given deployment depends on your organisation's security category requirements, regulatory obligations, and protocol context. QSECDEF's NIST PQC Algorithm Selector works through these variables and returns a recommendation for each use case in your environment.