The wait is over. On 13 August 2024, NIST published four post-quantum cryptographic standards: FIPS 203 (ML-KEM), FIPS 204 (ML-DSA), FIPS 205 (SLH-DSA), and FIPS 206 (FN-DSA). Eight years, 69 submissions, four evaluation rounds. The algorithm selection phase is closed. What remains is the migration.
Enterprise security teams are now in the implementation phase, not the monitoring phase. The question is no longer "which algorithm will NIST select?" It is "how do we migrate our estate to these algorithms, against which compliance deadline, and in what order?" This article provides the reference an architect or CISO needs to answer those questions without reading four separate FIPS publications, three national security memoranda, and a draft NIST internal report.
The Four Standards: What Each One Does
The four standards address three cryptographic primitives. One key encapsulation mechanism and three digital signature algorithms. There is currently no NIST-standardised post-quantum asymmetric encryption algorithm separate from the KEM construction. Enterprises needing asymmetric encryption use ML-KEM for key transport.
FIPS 203: ML-KEM (Module-Lattice-Based Key-Encapsulation Mechanism)
ML-KEM replaces RSA and elliptic-curve Diffie-Hellman in key exchange. The deployment contexts are TLS 1.3 key exchange, SSH key agreement, IPsec IKEv2, and any protocol where two parties need to establish a shared symmetric key. Three parameter sets: ML-KEM-512 (NIST Category 1), ML-KEM-768 (Category 3, enterprise default), ML-KEM-1024 (Category 5, required under CNSA 2.0 for national security systems). Key sizes: ML-KEM-768 public key is 1,184 bytes; ciphertext is 1,088 bytes.
FIPS 204: ML-DSA (Module-Lattice-Based Digital Signature Algorithm)
ML-DSA is the primary replacement for RSA-PSS, ECDSA, and EdDSA. Deployment contexts: X.509 certificate signing, code signing, document signing, authentication tokens (JWT, SAML). NIST explicitly recommends ML-DSA as the first digital signature algorithm organisations should adopt. Three parameter sets: ML-DSA-44 (Category 2), ML-DSA-65 (Category 3, enterprise default; public key 1,952 bytes, signature 3,293 bytes), ML-DSA-87 (Category 5, required under CNSA 2.0). For context: an ML-DSA-65 signature is approximately 50 times larger than a P-256 ECDSA signature. Certificate chain sizes increase materially during migration, and protocol testing is required before production deployment.
FIPS 205: SLH-DSA (Stateless Hash-Based Digital Signature Algorithm)
SLH-DSA's security depends on hash function properties, not lattice algebra. If the MLWE assumption underlying ML-KEM and ML-DSA were ever weakened, SLH-DSA remains secure. The trade-off is signature size: 7,856 bytes for SLH-DSA-SHA2-128s at Category 1, rising to 29,792 bytes for SLH-DSA-SHA2-256s at Category 5. SLH-DSA is not a high-throughput signature scheme. Its purpose is algorithm diversity in contexts where signature size is not the binding constraint: root CA private key operations, long-term trust anchors, and code signing for critical infrastructure.
FIPS 206: FN-DSA (Module-Lattice-Based Digital Signature Algorithm from FALCON)
FN-DSA uses NTRU lattice problems and produces smaller signatures than ML-DSA. It is more complex to implement safely due to Gaussian sampling requirements. Recommended where signature or key size is the binding constraint, particularly in embedded or constrained environments. FN-DSA is not the recommended starting point for general enterprise migration. ML-DSA and ML-KEM are the priority workstream for most organisations.
The Compliance Landscape
Three points are frequently misconstrued in compliance conversations, and getting them wrong damages credibility with audit and legal teams. First: the NIST standards are requirements for US federal agencies under FISMA, not guidance. Second: CNSA 2.0 applies specifically to national security systems and extends its obligations through the US defence supply chain. Third: NCSC guidance and ETSI TS 119 312 are authoritative but not statutory mandates for commercial organisations outside the US. The compliance argument for those organisations runs through NIS2 and DORA's broader ICT risk obligations.
United States
NSM-10 (National Security Memorandum, The White House, May 2022) directed federal agencies to identify quantum-vulnerable systems and begin migration immediately. The mandate is explicit: the work should start now, not at Q-Day. NSA CNSA 2.0 (September 2022) sets specific requirements for national security systems: ML-KEM-1024 for key encapsulation and ML-DSA-87 for digital signatures, with implementation timelines from 2025 for new systems and 2030-2033 for legacy infrastructure depending on system type. NIST IR 8547 (Initial Public Draft, 2024) targets the deprecation of RSA and elliptic-curve algorithms in federal use: deprecated for new systems after 2030; disallowed entirely, including legacy interoperability, after 2035. Organisations in the US defence supply chain under DFARS clauses and CMMC requirements operate within the scope of CNSA 2.0 even if they are not federal agencies.
United Kingdom
UK NCSC guidance (2024) endorses FIPS 203, 204, and 205 for UK organisations and recommends alignment with NIST standards for interoperability with US and allied systems. NCSC does not impose mandatory timelines on commercial organisations but is unambiguous that PQC preparation is a current-term obligation, not a future-planning exercise. UK government systems and critical national infrastructure operators face additional obligations under the National Cyber Security Strategy and NCSC GovAssure programme.
European Union
ETSI TS 119 312 V1.4.1 (October 2023) provides the European algorithm framework, aligned with NIST's selections, for electronic signatures and seals. The NIS2 Directive (entered into force January 2023, member state transposition deadline October 2024) and the EU Cyber Resilience Act (2024) require in-scope organisations to implement state-of-the-art security measures. For systems handling sensitive long-lived data, quantum-vulnerable cryptography is increasingly classified as below that standard given the Harvest Now, Decrypt Later (HNDL) threat: the practice of capturing encrypted data today for decryption once a cryptographically relevant quantum computer (CRQC) exists. DORA (Digital Operational Resilience Act, effective January 2025) imposes ICT risk management obligations on EU financial entities, including cryptographic risk, that create planning obligations relevant to PQC migration even where the regulation does not name post-quantum cryptography explicitly.
What Migration Actually Involves
Migration to post-quantum cryptography is not a software update. It is a multi-year programme. Treating it as the former is how organisations discover, eighteen months into the project, that they are still in the inventory phase.
The sequence recommended by NIST and CISA (joint advisory, August 2023) has four stages: cryptographic inventory, risk prioritisation, hybrid transition deployment, and full migration. Each stage is a dependency for the next. An organisation that has not completed a cryptographic inventory cannot meaningfully prioritise, because it does not know which systems are affected.
Cryptographic inventory (mapping every certificate, key pair, protocol, and library using RSA, ECC, or Diffie-Hellman across the infrastructure) takes six to twelve months for a mid-sized enterprise in every project I have worked on. That is before a single algorithm is changed. The inventory phase is where most projects either stall entirely (Crypto Paralysis, the condition that sets in when the scope of hidden RSA dependencies expands beyond the initial estimate) or establish the foundation that makes the rest of the programme tractable.
The emerging discipline of Cryptographic Bill of Materials (CBOM), a structured inventory of all cryptographic assets in a software or system estate analogous to the Software Bill of Materials (SBOM), is the foundation for any serious migration programme. CISA and NIST are developing CBOM guidance. Organisations that have completed a CBOM are significantly better positioned for prioritised migration because they know exactly which systems are affected, not approximately.
Hybrid deployment (running a classical algorithm and a post-quantum algorithm in parallel, so that security is maintained if either has an undiscovered weakness) is the recommended transition state from NCSC, BSI (TR-02102-1, 2024), and ANSSI. NIST IR 8547 and the IETF hybrid KEM drafts (draft-ietf-tls-hybrid-design) provide the protocol specifications. For most enterprises, the first two hybrid deployments are TLS key exchange using ML-KEM-768 alongside X25519, and new certificate issuance incorporating ML-DSA-65. Both address the broadest attack surface and can be piloted without requiring the entire estate to migrate simultaneously.
NIST estimates that a large federal agency migration, once fully resourced, takes three to five years to complete. Enterprise estates that are larger, older, or more heterogeneous should plan for the upper end of that range or beyond. The compliance deadlines are in 2030 and 2035. The inventory and planning work that precedes active migration needs to be underway now.
Where to Start
Post-quantum cryptography runs on existing hardware. No quantum computers, no quantum infrastructure, no specialised hardware beyond what any enterprise already operates. This is a frequent source of confusion: PQC migration is a software and protocol programme. The algorithms in FIPS 203, 204, and 205 are implemented in OpenSSL 3.x (via the oqs-provider plugin), BoringSSL, liboqs (Open Quantum Safe project), and PyCryptodome. Browser vendors including Google Chrome and Apple Safari deployed experimental ML-KEM support in 2024 (Google Security Blog, September 2024). Enterprise hardware security module vendors including Thales, Entrust, and Utimaco have announced PQC support roadmaps; organisations integrating HSMs into their migration programme should verify current certification status against vendor documentation before procurement.
The practical priority sequence for most enterprises is this. Begin with the cryptographic inventory. Treat it as a standalone, resourced programme deliverable with its own milestone and reporting, not a preliminary to the real work. Use the CBOM framework as the output format. Once the inventory is complete, the risk prioritisation (driven by data sensitivity, retention period, and HNDL exposure window) determines the migration sequence. The compliance deadline for federal contexts is 2030 for deprecation of RSA and ECC in new systems. For enterprises holding data with a ten-year or longer confidentiality horizon, the HNDL risk window means the urgency is ahead of that date, not at it.
A structured risk assessment identifies which systems in your estate face the highest HNDL exposure and maps migration urgency against your specific data retention profiles. QSECDEF's PQC Risk Assessment tool runs this analysis against your organisation's inputs and returns a prioritised action plan.
