Post-Quantum Cryptography Is Coming. Here's What Your Organization Needs to Do Before 2030

In August 2024, NIST published its first finalized post-quantum cryptographic standards: ML-KEM (FIPS 203), ML-DSA (FIPS 204), SLH-DSA (FIPS 205), and FN-DSA (FIPS 206). The announcement was widely covered. The response from most organizations was to add it to a future security roadmap and move on to more immediate priorities.

That's the wrong call, and the reason comes down to a threat that doesn't wait for the migration to be complete. Understanding the actual risk — and the specific steps required to address it — is what separates organizations that will manage this transition well from those that will be scrambling in 2029.

The threat model: harvest now, decrypt later

The standard argument for urgency around quantum-resistant cryptography goes like this: cryptographically relevant quantum computers don't exist yet, so why rush? The answer is the "harvest now, decrypt later" (HNDL) attack, and it makes the timeline of quantum computer development largely irrelevant to today's migration decisions.

Nation-state adversaries and sophisticated criminal organisations are recording encrypted traffic today — TLS sessions, VPN tunnels, encrypted file transfers — and storing it for decryption once a quantum computer capable of running Shor's algorithm at scale exists. The data being encrypted today with RSA-2048 or ECDSA P-256 includes long-lived sensitive information: health records, financial transactions, intellectual property, classified communications. If that data needs to remain confidential for 10 to 20 years, the relevant question is not "when will quantum computers break RSA?" but rather "is a capable quantum computer possible within the confidentiality window of the data I'm encrypting today?"

Most credible estimates put cryptographically relevant quantum computing (CRQC) at 8 to 15 years away. The most pessimistic credible estimates put it at 5 to 7 years. The harvest is happening now. The clock runs from the moment data is captured, not from the moment a quantum computer is switched on.

The four NIST standards and what they're for

ML-KEM (FIPS 203) — based on the CRYSTALS-Kyber algorithm — is a Key Encapsulation Mechanism designed to replace RSA and ECDH in key exchange. This is the most immediately important standard for most organisations: TLS 1.3 key exchange, VPN session setup, and secure messaging protocols all rely on key exchange mechanisms that ML-KEM replaces.

ML-DSA (FIPS 204) — based on CRYSTALS-Dilithium — is a digital signature algorithm replacing RSA and ECDSA for signing. It's relevant wherever authentication depends on signatures: code signing, certificate issuance, document signing, SSH authentication.

SLH-DSA (FIPS 205) — based on SPHINCS+ — is a stateless hash-based signature scheme. It's slower and produces larger signatures than ML-DSA but has a security proof based solely on hash function security, making it a valuable backup algorithm if a vulnerability is found in lattice-based schemes. Recommended for cases requiring long-term signature verification (years to decades).

FN-DSA (FIPS 206) — based on FALCON — is a signature scheme with smaller signature sizes than ML-DSA, useful in bandwidth-constrained environments. It requires careful implementation to avoid side-channel attacks, making it lower priority for most organisations compared to ML-DSA.

The migration priority order for most organisations: ML-KEM first (protect key exchange in transit), then ML-DSA (protect authentication), then consider SLH-DSA for long-lived signatures. FN-DSA is for specialised environments.

What CISA and NIST have actually required

NIST Special Publication 1800-38C (December 2024) provides migration guidance for TLS 1.3 and recommends specific hybrid key exchange configurations: X25519MLKEM768 (ML-KEM-768 combined with X25519) for immediate deployment. Hybrid modes run classical and post-quantum key exchange simultaneously — if either is secure, the session is secure — allowing organisations to deploy PQC without betting everything on the new algorithms before they've had more time in the field.

CISA's 2025 guidance to federal civilian agencies set two milestones: complete cryptographic inventory by end of 2026, and complete migration of priority systems by end of 2030. "Priority systems" means systems handling classified information, critical infrastructure control, and systems processing personally identifiable information at scale.

For the private sector, these are not legal mandates. But regulated industries are already seeing the requirements migrate: financial services regulators in the EU have incorporated PQC readiness into their 2026 DORA technical standards. HIPAA guidance updated in 2025 references NIST PQC standards for healthcare systems handling long-retention records. The procurement requirements are ahead of you: if you supply to federal agencies, PQC-capable systems will be a contract requirement before 2028.

Where to start: the cryptographic inventory

The first and most underestimated step is knowing what cryptography you're currently running. Most organisations do not have a complete picture of where RSA and ECDSA are in use across their systems. The inventory is harder than it sounds because cryptographic primitives are embedded in application libraries, network infrastructure, PKI systems, hardware security modules, and third-party software.

The inventory process should produce a list of: all certificates and their algorithms, all key exchange mechanisms in use (by protocol and system), all code signing and document signing infrastructure, all HSMs and their algorithm support, and all third-party vendors whose cryptographic capabilities affect your security posture.

Tools that help: NIST's National Cybersecurity Center of Excellence has published a PQC migration project with open-source tooling. Vendors including Keyfactor, AppViewX, and Venafi have released certificate inventory tools with PQC migration mapping. Network scanning tools like Qualys and Tenable have added PQC detection capabilities. The point is not to have a perfect inventory immediately — it's to have a defensible starting point.

What's deployable today

Several major systems already support post-quantum key exchange in hybrid mode:

OpenSSH 9.0 (released April 2022) uses sntrup761x25519 for key exchange by default. While this predates the final NIST standards and uses a different algorithm, it demonstrates the pattern: hybrid key exchange works in production and has for years.

TLS 1.3 with X25519MLKEM768 is supported in Chrome 131 (released November 2024), Firefox 132, and OpenSSL 3.5. Cloudflare enabled PQC hybrid key exchange for all traffic in September 2024. Apple enabled ML-KEM hybrid key exchange in iMessage in February 2025 as part of PQ3 Protocol, replacing the PQXDH scheme launched in 2024.

The practical starting point for most organisations in 2026: enable X25519MLKEM768 in your TLS termination layer (load balancers, API gateways, CDN configurations) and update your internal PKI roadmap to include ML-DSA certificate issuance capability by 2028. Neither of these requires organisational heroics — they're configuration changes and PKI planning work that can begin immediately.

The organisations that will struggle in 2029 are those treating this as a future problem. The ones that handle it well are doing inventory now, deploying hybrid key exchange at the edge, and building vendor requirements that include PQC into procurement cycles starting today.