NIST published FIPS 203 (ML-KEM, standardizing CRYSTALS-Kyber), FIPS 204 (ML-DSA, standardizing CRYSTALS-Dilithium), and FIPS 205 (SLH-DSA, standardizing SPHINCS+) on August 13, 2024. This ended an eight-year standards process that began with NIST's 2016 call for proposals. For the security architecture teams at financial institutions, the publication date marks the transition from "post-quantum is research" to "post-quantum has standards" — and triggers a different set of procurement decisions.
This article covers what the finalization actually means for bank procurement timelines, what the algorithm designations tell you about parameter choices, and what the gap between "standard finalized" and "hardware certified to that standard" means for institutions trying to plan a migration calendar.
What changed on August 13, 2024
Before the August 2024 publication, CRYSTALS-Kyber and CRYSTALS-Dilithium existed as NIST finalist algorithms — widely implemented in open-source libraries, studied extensively by the cryptographic research community, but not formally standardized by NIST. The distinction matters for financial institution procurement because:
- Regulatory guidance from FFIEC, OCC, and FDIC references NIST-standardized algorithms. "NIST finalist algorithm" does not carry the same regulatory weight as a published FIPS standard.
- Vendor CMVP validation submissions can only test against finalized standard specifications. CMVP certificates for Kyber and Dilithium implementations require the finalized FIPS 203/204 specifications as the test basis, not the earlier round submission specifications.
- Internal security policy at most financial institutions distinguishes between "approved algorithm" and "under evaluation." A NIST FIPS publication creates the basis for updating internal policy to treat ML-KEM and ML-DSA as approved algorithms.
What did not change on August 13, 2024: the mathematical algorithms themselves. FIPS 203 ML-KEM is the same CRYSTALS-Kyber construction that cryptographers have been analyzing since 2017, with minor implementation clarifications. Security architects who have been following the NIST process have had seven years to develop confidence in the algorithm's hardness properties. The publication date is an administrative event, not an algorithmic breakthrough.
Algorithm names and parameter sets: the procurement-relevant details
FIPS 203 designates three parameter sets for ML-KEM:
- ML-KEM-512: security category 1 (equivalent to AES-128). Module lattice dimension k=2.
- ML-KEM-768: security category 3 (equivalent to AES-192). Module lattice dimension k=3.
- ML-KEM-1024: security category 5 (equivalent to AES-256). Module lattice dimension k=4.
FIPS 204 designates three parameter sets for ML-DSA:
- ML-DSA-44: security category 2. (Previously Dilithium-2.)
- ML-DSA-65: security category 3. (Previously Dilithium-3.)
- ML-DSA-87: security category 5. (Previously Dilithium-5.)
NSA CNSA 2.0 guidance for national security systems specifies ML-KEM-1024 and ML-DSA-87 — the highest parameter sets in each family. The rationale: for long-lived key material (keys that will be in service for 10+ years), using the highest parameter set provides a buffer against future cryptanalytic advances in lattice algorithms. For financial institutions holding long-lived signing keys (certificate authorities, master key encryption keys), ML-DSA-87 is the appropriate target. For session key establishment (TLS handshake key exchange), ML-KEM-1024 is appropriate.
When evaluating HSM vendors, verify that the vendor's PQC implementation explicitly supports the FIPS 203/204 designated parameter sets (ML-KEM, ML-DSA) rather than the earlier draft Kyber/Dilithium specifications. The algorithm variants are not wire-compatible — a system that generates ML-KEM-1024 ciphertexts cannot be decapsulated by a system implementing the earlier Kyber-1024 NIST submission. The distinction matters for any multi-vendor environment or any integration with external counterparties.
The gap between standard finalization and hardware certification
FIPS 203 and 204 are published. CMVP certificates for hardware implementing these standards in isolation do not yet exist as of the publication of this post. This is the most practically important thing for bank procurement teams to understand.
The CMVP process — as described in more detail in our earlier post on FIPS 140-3 validation roadmaps — requires an NVLAP-accredited laboratory to test the module against the relevant FIPS standards and NIST Special Publication test vectors, then submit results to NIST for review. For algorithms newly standardized in August 2024, the ACVTS test vectors for ML-KEM and ML-DSA became available in 2024, and NVLAP laboratories began accepting submissions for testing against these standards in late 2024 and 2025. CMVP certificates are issued after NIST review, which typically takes 3 to 6 months after successful laboratory testing.
The practical implication: the first FIPS 140-3 certificates listing ML-KEM-1024 and ML-DSA as approved algorithms on a hardware module are likely to appear in late 2026 or 2027. A bank that initiates an HSM procurement process today, specifying "must have FIPS 140-3 certificate listing ML-KEM-1024" as a mandatory requirement, will find no compliant products available. The procurement specification needs to be written differently: "hardware designed for FIPS 140-3 Level 3 validation with ML-KEM-1024 support, with vendor-documented NVLAP engagement and CMVP submission timeline."
What the finalization changes about your procurement RFP
For institutions beginning HSM procurement in 2025 or 2026, the standard finalization changes several things:
Algorithm specification language: The RFP can now specify ML-KEM-1024 (FIPS 203) and ML-DSA-65 or ML-DSA-87 (FIPS 204) by their formal designations, not "post-quantum algorithm candidates." Vendors must confirm compliance with the published standard specifications, not with earlier draft submissions.
ACVTS test vector compliance: NIST's Automated Cryptographic Validation Testing System now has approved test vectors for ML-KEM and ML-DSA. Vendors can be required to provide ACVTS validation results demonstrating that their implementation produces correct outputs for all published test vectors. ACVTS results are not the same as CMVP certification, but they are objective evidence that the implementation is algorithmically correct per the FIPS 203/204 specifications.
Hybrid mode requirements: IETF drafts for hybrid TLS (X25519+ML-KEM-1024) have been updated to reference the FIPS 203 ML-KEM designation rather than the earlier Kyber designations. When specifying hybrid TLS support, reference the finalized FIPS 203 parameter set nomenclature to avoid ambiguity.
Internal policy approval pathway: Many institutions have internal cryptographic algorithm approval processes that require FIPS publication before adding an algorithm to the approved list. With FIPS 203 and 204 published, the formal approval pathway for ML-KEM and ML-DSA should now be clear and can be initiated.
FIPS 205 (SLH-DSA): relevant or not for banking?
FIPS 205 standardizes SLH-DSA (SPHINCS+), a hash-based signature scheme that does not rely on lattice hardness assumptions. Hash-based signatures are valuable for cryptographic diversity — if a future lattice cryptanalysis result weakens ML-DSA, SLH-DSA provides an alternative. The practical limitation for payment infrastructure: SLH-DSA signature sizes range from 7,856 bytes (SLH-DSA-SHAKE-128f) to 49,856 bytes (SLH-DSA-SHAKE-256s), compared to ML-DSA-65's 3,293 bytes. For protocols with message size constraints — ISO 8583 financial messages, SWIFT MT-series messages — SLH-DSA signatures exceed protocol field lengths.
SLH-DSA is appropriate for certificate signing (where signature size is not a per-transaction constraint) and for long-lived high-value signing keys where cryptographic diversity justifies the performance overhead. For transaction-level signing in payment infrastructure, ML-DSA-65 or ML-DSA-87 is the practical choice.
The August 2024 NIST publication is the starting line, not the finish line. The migration work — HSM procurement, PKCS#11 integration, key hierarchy migration, certificate chain updates — is ahead of every financial institution that has not yet begun. The standard being finalized removes the last reasonable argument for waiting.