FIPS 203, 204, and 205: An Enterprise Implementation Decision Map

Knowing what each standard requires is the first problem. The second problem, which most organisations discover only after completing a cryptographic inventory, is sequencing. Which standard do you implement first? Which deployments are independent and which create dependencies that block later migration steps? In every project I have worked on, these questions arrive in the wrong order: teams start researching ML-KEM before they have established whether their TLS certificate migration depends on the same PKI hierarchy rebuild that their code signing migration requires. It usually does. Starting in the wrong place creates rework.

This article covers the decision sequencing logic, not the algorithm specifications. For the technical specifications (parameter set sizes, mathematical foundations, NIST Security Categories) see our detailed coverage of what each FIPS standard requires. This article picks up where that one leaves off.

The Three Forces Driving Sequencing

Sequencing is not arbitrary. Three forces operate simultaneously on any implementation programme, and ignoring any one of them produces a plan that breaks on contact with reality.

HNDL exposure profile. Harvest Now, Decrypt Later (HNDL) attacks target confidentiality, the capture of encrypted data today for retrospective decryption once a cryptographically relevant quantum computer (CRQC) exists. This threat applies to key exchange, not to signatures. A signature breach allows forgery; it does not decrypt previously recorded sessions. NIST IR 8547 (Initial Public Draft, 2024) frames the sequencing consequence directly: organisations should prioritise ML-KEM (FIPS 203) migration for key establishment ahead of signature migration, because the confidentiality exposure is present-tense while signature forgery risk remains future-tense. For organisations holding data with long retention requirements (financial records with decade-long audit obligations, health records, classified communications), the Mosca inequality applies: if the sensitivity horizon of the data exceeds the expected CRQC arrival date, the migration is already overdue for those data categories (Mosca, M., "Cybersecurity in an Era of Quantum Computing," IEEE Security & Privacy, 16(5), 2018).

FIPS 140-3 CMVP validation availability. A vendor may ship an ML-KEM-capable library before that library achieves CMVP validation under FIPS 140-3. In regulated environments (US federal agencies, DoD contractors under DFARS/CMMC, and NSS-adjacent systems under CNSA 2.0), the requirement is a validated module, not just an algorithm-approved library. For EU financial entities under DORA and organisations subject to NIS2, relevant national regulatory guidance should be consulted, as equivalent requirements may apply under national implementations. These are not the same thing. The NIST Cryptographic Module Validation Programme (CMVP) validates specific implementations; CMVP validation coverage for PQC algorithms is still maturing as of mid-2026. A sequenced approach reduces the risk of building on a non-validated module by prioritising the algorithm and use case for which validated modules are currently available.

Protocol dependency chains. Some migrations are independent; some create dependencies. TLS key exchange (ML-KEM) and TLS certificate authentication (ML-DSA) are separate protocol components. IETF RFC 8446 specifies them independently, and either can be migrated independently in terms of protocol architecture: the key_share extension and the Certificate message in RFC 8446 are distinct. PKI hierarchy migration is not independent: a root CA signed with RSA cannot issue a trust chain that terminates in an ML-DSA-compliant leaf. The migration order is root CA first, intermediate CA second, subscriber certificate third. Discovering this dependency in the middle of a leaf certificate rotation programme is expensive.

Implementation Decision Map

The table below maps each common use case to its primary standard, sequencing priority, dependency, and the IETF specification governing integration. IETF documents referenced are active Internet-Drafts or published RFCs on the standards track as of May 2026; status should be verified at the IETF Datatracker before procurement decisions rest on them.

FN-DSA (FIPS 206), derived from the FALCON submission, produces significantly smaller signatures than ML-DSA. FN-DSA-512 generates 666-byte signatures (FIPS 206, Table 1) versus 2,420 bytes for ML-DSA-44. For IoT devices with constrained flash or bandwidth, this matters. The trade-off is implementation complexity: FN-DSA's rejection sampling and randomness requirements are more demanding than ML-DSA's, making implementation errors more consequential. For constrained environments where those implementation constraints can be met, FN-DSA is the migration target for signatures.

The CMVP Gate

FIPS 140-3 is the cryptographic module validation standard administered by NIST and CCCS through the Cryptographic Module Validation Programme. A module on the CMVP validated modules list has been independently tested to confirm it correctly implements the specified algorithm. CMVP validation is not an audit checkbox applied after deployment. It is a procurement criterion that must appear in vendor RFPs from the start.

The distinction matters because vendor support for an algorithm and CMVP validation of that vendor's implementation are not the same thing. A TLS library may advertise ML-KEM support. If it is not on the CMVP validated list, it is not compliant for use in environments requiring FIPS 140-3 validated modules: US federal systems, DoD contractor environments under DFARS and CMMC, and NSS-adjacent systems under CNSA 2.0. Using a non-validated module for PQC is not compliant regardless of the algorithm being FIPS-approved.

CMVP validation coverage for ML-KEM, ML-DSA, and SLH-DSA is increasing but incomplete as of mid-2026. The live search at the NIST CMVP validated modules database (csrc.nist.gov) is the authoritative current state; the article cannot cite a specific count here because the list updates continuously. A vendor that has achieved CMVP validation for ML-KEM may not yet have ML-DSA validation. Sequencing your deployment by CMVP availability as well as technical readiness is a real operational constraint, not a theoretical one.

SLH-DSA Versus Stateful Hash-Based Signatures

SLH-DSA (FIPS 205) is a stateless scheme. Each key pair can sign an unlimited number of messages without maintaining state between operations. This is not true of XMSS and LMS, the stateful hash-based schemes specified in NIST SP 800-208 (October 2020). Stateful schemes track which one-time keys have been used; key reuse destroys security. On devices without secure non-volatile state storage (embedded controllers, air-gapped HSMs without secure persistent counters), XMSS and LMS carry operational risk that SLH-DSA does not.

NIST SP 800-208's stateful schemes are not deprecated. They remain appropriate where state management is feasible and controlled: air-gapped HSMs with secure counters, TPMs with reliable persistent storage. The choice is not "better versus worse" but "stateless versus stateful operational model." SLH-DSA removes the state management hazard, which is why it is the default recommendation for firmware signing on embedded devices and for root CA keys where operational simplicity is a higher priority than raw performance.

SLH-DSA's signing and verification are slower than ML-DSA's, and its signatures are larger. For high-throughput over-the-air update pipelines, ML-DSA-65 is the more practical choice. The firmware signing decision in the table above reflects this: use case and operational profile drive the choice, not a categorical preference for either algorithm.

Three Misconceptions That Create Rework

"Implement all three simultaneously." Not realistic in regulated environments. Each standard requires cryptographic library support with CMVP validation, protocol-level IETF I-D integration, testing, rollback planning, and interoperability verification. Attempting simultaneous deployment across ML-KEM, ML-DSA, and SLH-DSA fragments attention across three distinct integration workstreams and makes root-cause analysis harder when integration failures occur. The standard recommendation (KEM first, primary signature second, diversity signature third) is not conservatism. It is blast-radius management.

"Pick whichever algorithm your vendor supports." Vendor support for a PQC algorithm does not equal CMVP validation, does not equal interoperability with the rest of your protocol stack, and does not equal parameter set alignment with your regulatory requirements. CNSA 2.0 mandates ML-KEM-1024 and ML-DSA-87. A vendor shipping ML-KEM-768 may be appropriate for most enterprise deployments but not for NSS-adjacent ones. Selecting based on vendor availability before checking CMVP status, IETF I-D support, and parameter set requirements creates vendor lock-in and a compliance debt that is expensive to unwind.

"ML-KEM is a drop-in replacement for RSA-OAEP." The interface is different at the application layer. RSA-OAEP directly encrypts a content encryption key or small data payload using the recipient's public key. ML-KEM generates a shared secret and a ciphertext; the recipient decapsulates to recover the shared secret, which is then used to derive a symmetric key for data encryption. Code calling RSA-OAEP cannot simply substitute ML-KEM without modifying the surrounding key management logic and the CMS wrapping structure. IETF draft-ietf-lamps-cms-kyber specifies the correct ML-KEM integration pattern in CMS. The necessary changes are defined; they are not trivial to drop in.

The Three-Phase Programme

A practical sequencing model for most enterprises runs across three phases, with the acknowledgement that large organisations will have Phase 2 work commencing before Phase 1 is complete.

Phase 1 is ML-KEM for all confidentiality channels: TLS key exchange, VPN key agreement, S/MIME key transport, and storage key wrapping for long-retention data. This addresses the HNDL exposure profile directly. Phase 2 is ML-DSA for signing infrastructure: PKI hierarchy rebuild (root CA, then intermediates, then subscribers), code signing pipeline migration, S/MIME message authentication, and IKE_AUTH certificate migration. Phase 3 is SLH-DSA for diversity anchors: root CA trust anchors where algorithm diversity beyond MLWE is operationally required, and long-lived firmware signing keys for high-consequence, low-throughput deployments.

Within each phase, CMVP validation availability is the real sequencer. The technical work and the validation state of available modules do not always move in lockstep.

To map these priorities against your specific protocol inventory, the NIST PQC Algorithm Selector walks through your environment variables and returns a sequenced recommendation based on your use case portfolio.