NIST Post-Quantum Cryptography Standards Migration Guide

The NIST post-quantum cryptography standards migration is the process by which organisations replace classical asymmetric algorithms, most critically RSA, ECDH and ECDSA, with cryptographic schemes that remain secure against attacks from both classical and quantum computers. In August 2024, NIST published FIPS 203, FIPS 204 and FIPS 205 as the world’s first finalised post-quantum cryptographic standards, ending years of evaluation and creating a concrete baseline for regulated sectors.

The four post-quantum algorithms and what they do

NIST’s standardised portfolio assigns distinct cryptographic functions to four algorithms, each designed to resist the specific computational advantages that quantum processors would bring.

ML-KEM / CRYSTALS-Kyber (FIPS 203)

ML-KEM is a key encapsulation mechanism built on module learning-with-errors (MLWE) lattice mathematics. It replaces RSA-based key transport and elliptic-curve Diffie-Hellman (ECDH) in scenarios where two parties need to establish a shared secret, such as TLS handshakes, encrypted email session keys and VPN tunnel establishment. FIPS 203 defines three parameter sets: ML-KEM-512, ML-KEM-768 and ML-KEM-1024. For most government and financial sector use cases, ML-KEM-768 offers the recommended balance of security and performance.

ML-DSA / CRYSTALS-Dilithium (FIPS 204)

ML-DSA is a digital signature scheme, also lattice-based, that replaces RSA-PKCS#1 and ECDSA for authentication, code signing, document signing and certificate issuance. FIPS 204 defines three levels: ML-DSA-44, ML-DSA-65 and ML-DSA-87. Because signature verification speed and signature size both matter in high-volume contexts such as financial transaction processing or PKI certificate chains, organisations should benchmark the parameter sets against their throughput requirements before committing to a level.

SLH-DSA / SPHINCS+ (FIPS 205)

SLH-DSA is a stateless hash-based signature scheme. Its security rests on the hardness of inverting cryptographic hash functions rather than on lattice problems, making it mathematically independent from the lattice family. This algorithmic diversity is strategically important: if a future structural weakness is found in lattice constructions, hash-based signatures remain unaffected. SLH-DSA is best suited for use cases where signature volume is low and long-term verifiability is critical, such as firmware signing, root-of-trust certificates and long-lived legal documents.

FALCON (FIPS 206, forthcoming)

FALCON is a lattice-based signature scheme that produces significantly smaller signatures and public keys than ML-DSA, at the cost of more complex implementation requirements. NIST is finalising FALCON as FIPS 206. Its compact output makes it attractive for constrained environments such as IoT devices, embedded controllers and smart cards. However, the implementation complexity means it carries higher risk of side-channel vulnerabilities in custom code; regulated sectors should treat it as a specialist option rather than a general default.

FIPS formalisation and regulatory adoption timeline

The three published standards create an enforceable baseline that procurement contracts, audit frameworks and national technical guidelines can now explicitly reference.

NIST completed its multi-year post-quantum standardisation process in August 2024, publishing FIPS 203, FIPS 204 and FIPS 205 as final standards. In the United States, federal agencies are already subject to OMB Memorandum M-23-02, which required quantum-readiness asset inventories by May 2023 and mandates prioritised migration of high-value systems. NIST Dustin Moody, mathematician and PQC project lead at the NIST Computer Security Division, has stated: “The threat of a cryptographically relevant quantum computer is real enough that we cannot wait until one is built to begin the migration. The time to act is now.”

For European organisations, the German BSI Technical Guideline TR-02102 already recommends hybrid deployment of PQC algorithms alongside classical ones, treating it as current best practice rather than a future aspiration. ENISA has issued similar transition guidance. Under DORA, NIS-2 and GDPR, the obligation to apply “state-of-the-art” cryptographic protection means regulators will increasingly scrutinise whether organisations have begun PQC migration, particularly for data subject to long retention periods.

A practical migration roadmap for government agencies and financial institutions

Effective PQC migration is not a single cutover; it is a phased programme that runs hybrid classical-PQC configurations during the transition and replaces legacy algorithms only when the full dependency chain is ready.

Phase 1: Cryptographic inventory (months 1 to 6)

Before any algorithm can be migrated, the organisation must know where cryptography lives. This means cataloguing every certificate, every TLS endpoint, every VPN gateway, every code-signing pipeline and every application that performs asymmetric operations. Many regulated organisations discover during this phase that they have hundreds of certificates with unknown owners, legacy SOAP services using XML-DSig with RSA-1024, and third-party SaaS integrations that handle key exchange entirely outside internal control. The inventory must capture algorithm type, key length, data classification of what each cryptographic control protects, and the expected confidentiality lifetime of that data.

Phase 2: Hybrid deployment for high-risk assets (months 6 to 18)

The first migration target is any system protecting data with a confidentiality lifetime beyond five years. In practice this means: TLS termination for externally facing services (deploy hybrid ML-KEM-768 plus X25519 key exchange), VPN gateways (implement IETF RFC 9370 for multiple key exchanges in IKEv2, which explicitly enables hybrid classical-PQC tunnel establishment), and PKI roots and intermediates that will issue long-lived certificates. Hybrid mode means both the classical and the PQC key exchange run simultaneously; the connection is secure as long as at least one component remains unbroken. This is the recommended approach by BSI TR-02102 and is operationally achievable today using the Open Quantum Safe project’s liboqs library, which provides a production-tested open-source C implementation of the NIST-standardised algorithms with integrations available for OpenSSL 3.x, BoringSSL and WolfSSL.

Phase 3: Signature migration and code signing (months 12 to 30)

Digital signatures have broader dependencies than key exchange because they touch PKI hierarchies, timestamping authorities, document signing workflows and software supply chains. ML-DSA should replace ECDSA in new certificate issuance as CAs add support. For firmware and software signing, SLH-DSA is the preferred option due to its hash-based security independence. This phase also includes migrating application-level cryptography: APIs that sign JWTs, services that verify client certificates and systems that use XML or CMS signatures.

Phase 4: Legacy deprecation (months 24 to 48)

Once hybrid operation has been validated and monitoring confirms that no production traffic relies solely on deprecated algorithms, organisations can begin disabling RSA and ECDH in TLS configurations, revoking classical-only certificates and enforcing PQC-only tunnels on internal high-sensitivity segments.

Protocol and library support: what is ready and what is not

The migration landscape is uneven. TLS 1.3 over HTTPS is the most mature: OpenSSL 3.x with the OQS provider supports hybrid key exchange in production, and major browsers including Chrome have trialled X25519Kyber768 hybrid key exchange. SSH implementations lag behind; OpenSSH does not yet ship PQC key exchange by default, though patches exist. IPsec VPNs that implement RFC 9370 are increasingly available, but many enterprise firewall vendors have not yet shipped firmware with ML-KEM support. Encrypted email (S/MIME and OpenPGP) remains almost entirely on classical algorithms. Organisations should map protocol readiness against their asset inventory to identify gaps where hybrid protection cannot yet be deployed and where compensating controls such as additional network segmentation or access restrictions are necessary.

Prioritising the cryptographic estate

Not all cryptographic assets carry equal urgency. The prioritisation logic follows two axes: the sensitivity of the data protected and the expected lifetime of that data. A session token for a web login that expires in one hour carries negligible quantum risk. A digitally signed court order archived for thirty years carries extreme risk because its authenticity may be challenged in a future where forging its signature is computationally feasible.

High-priority targets for immediate action: long-lived PKI root certificates, VPN infrastructure for staff handling classified or legally privileged information, encryption of database backups containing personal health or financial records, and any cross-border data transfer mechanism relying on asymmetric key exchange. Medium priority: internal service-to-service TLS, application-level JWT signing and developer code signing certificates. Lower priority, but still requiring a documented roadmap: legacy internal LDAP over TLS, monitoring agent communications and development environment tooling.

Procurement language for RFPs and vendor contracts

Compliance officers and IT decision-makers can use the following concrete requirements in tender specifications and contract schedules. First, require vendors to maintain a documented cryptographic inventory and to disclose it on request as part of annual security attestation. Second, specify that TLS termination endpoints must support ML-KEM hybrid key exchange referencing FIPS 203 by a defined date, such as 1 January 2027 for new contracts. Third, require that any code signing or certificate issuance service must migrate to ML-DSA (FIPS 204) or SLH-DSA (FIPS 205) for all new issuance within the contract term. Fourth, include a right-to-audit clause covering cryptographic controls and algorithm versions. Fifth, require that VPN and remote-access gateways demonstrate RFC 9370 compliance or a documented equivalent. Vendors who cannot provide a credible written PQC migration plan with milestones should be treated as carrying unacceptable long-term cryptographic risk, particularly in sectors subject to DORA operational resilience requirements or NIS-2 incident reporting obligations.

FAQ

What is the difference between ML-KEM and ML-DSA, and do I need both?

ML-KEM (FIPS 203) establishes shared secrets for encrypting data in transit or at rest. ML-DSA (FIPS 204) authenticates parties and verifies the integrity of documents or code. Most organisations need both: ML-KEM to replace RSA and ECDH in key exchange, and ML-DSA to replace RSA and ECDSA in signatures.

When must regulated European organisations comply with post-quantum requirements?

There is currently no single EU law with a hard PQC deadline, but the BSI TR-02102 already recommends PQC deployment alongside classical algorithms. DORA, NIS-2 and GDPR require state-of-the-art cryptography, which regulators will increasingly interpret to include PQC for long-lived sensitive data. Proactive migration of high-risk asset classes before 2028 is the broadly recommended target across European cybersecurity agency guidance.

What is a harvest-now-decrypt-later attack and why does it matter today?

A harvest-now-decrypt-later attack involves an adversary recording encrypted traffic today and decrypting it once a sufficiently powerful quantum computer becomes available. Data with a confidentiality lifetime beyond five to ten years, including healthcare records, legal documents, government communications and financial transaction histories, is already at risk from this threat model regardless of current quantum computer capabilities.

Can I deploy hybrid classical-PQC TLS without replacing my entire infrastructure?

Yes. TLS 1.3 supports hybrid key exchange combining X25519 with ML-KEM-768 using IETF-defined code points. OpenSSL 3.x with the OQS provider from the Open Quantum Safe project supports these hybrid cipher suites in production. Connections fall back to classical security for peers that do not support PQC, so incremental deployment is safe and does not require a flag-day cutover.

What procurement language should I use to require PQC readiness from vendors?

RFPs should require: a current cryptographic inventory disclosed on request; TLS endpoints supporting ML-KEM hybrid key exchange by a stated date referencing FIPS 203; code signing migrated to ML-DSA or SLH-DSA within the contract term; annual written attestation of migration progress; RFC 9370-compliant VPN gateways; and a right-to-audit clause covering cryptographic controls. Vendors unable to provide a documented migration plan with milestones should be considered as carrying unacceptable long-term risk.