In August 2024, NIST published the first three finalised post-quantum cryptography (PQC) standards — ML-KEM (FIPS 203), ML-DSA (FIPS 204), and SLH-DSA (FIPS 205) — completing a decade of standardisation work. The algorithms are ready. The deadlines are published. The only open question is whether organisations will act in time.
For anyone doing business with the US federal government or operating within regulated sectors, the most immediate hard deadline is now less than nine months away: on 1 January 2027, the NSA’s Commercial National Security Algorithm Suite 2.0 (CNSA 2.0) requires that all new acquisitions of National Security System (NSS) equipment default to quantum-resistant cryptography. After that date, procuring hardware or software that relies on RSA, ECDH, or ECDSA for NSS environments without a documented exception will be non-compliant.
The Harvest Now, Decrypt Later Problem
The urgency of post-quantum migration is not limited to preparing for a future quantum computer. It is immediate. Sophisticated state-sponsored adversaries are already operating at scale under what is known as the “harvest now, decrypt later” (HNDL) strategy: intercepting and archiving encrypted communications today, with the intention of decrypting that traffic once a sufficiently powerful quantum computer becomes available.
Any data encrypted today that must remain confidential beyond the expected arrival of cryptographically relevant quantum computers — typically estimated in the 5–15 year range, though some threat intelligence assessments place it closer — is already at risk. This is especially acute for long-lived sensitive data: intellectual property, source code, classified communications, patient health records, and financial agreements.
The Standards and What They Replace
The three finalised NIST standards address the two principal use cases where quantum computers threaten current cryptography:
ML-KEM (FIPS 203) — formerly CRYSTALS-Kyber — replaces RSA and ECDH for key encapsulation and key exchange. It is the primary mechanism for establishing shared secrets in encrypted communications.
ML-DSA (FIPS 204) — formerly CRYSTALS-Dilithium — replaces RSA and ECDSA for digital signatures. This affects code signing, certificate authorities, authentication tokens, and any protocol that uses signed assertions.
SLH-DSA (FIPS 205) — a hash-based signature algorithm providing a conservative, non-lattice-based alternative for high-assurance signing applications.
NIST has signalled that it intends to deprecate RSA, ECDH, and ECDSA from its standards by 2035, with high-risk environments expected to migrate substantially earlier.
Who Is Affected Beyond the Federal Government
The CNSA 2.0 requirements technically apply to National Security Systems — defence, intelligence community, and classified government infrastructure. However, the practical blast radius is substantially wider:
- Federal contractors and defence suppliers face supply chain requirements that effectively extend CNSA 2.0 compliance obligations. Procurement contracts for NSS-adjacent systems will increasingly specify CNSA 2.0 compliance as a condition.
- Financial institutions and critical infrastructure face emerging regulatory pressure from NIST IR 8547 and sector-specific guidance that aligns with or references the federal migration timeline.
- Any organisation with data retention obligations beyond 2035 should treat the NIST deprecation timeline as their effective hard deadline — but given implementation complexity, that means beginning now.
Industry analysts project the post-quantum cryptography services and technology market will exceed $15 billion by 2030, with organisations expected to allocate 2–5% of annual IT security spend over a four-year migration window.
Why Migration Takes Longer Than Expected
Organisations that have not started frequently underestimate the scope of cryptographic migration. The challenge is not simply swapping one algorithm for another in a configuration file. The barriers include:
Cryptographic inventory is incomplete. Most large organisations cannot enumerate all locations where RSA, ECDH, or ECDSA are used: TLS certificates, VPN configurations, code signing pipelines, SSH keys, encrypted databases, custom application crypto, and hardware security modules all require separate assessment.
Hybrid cryptography is necessary during transition. Standard migration guidance recommends deploying hybrid key exchange (combining classical and post-quantum algorithms) during the transition period, so that a failure in either algorithm does not leave communications unprotected. This requires protocol-level changes in TLS implementations, VPN clients, and custom applications.
Hardware HSMs may not be upgradeable. Hardware security modules and cryptographic accelerators often have firmware or hardware limitations that prevent post-quantum algorithm support. Organisations may need hardware replacement cycles rather than software updates.
Algorithm agility must be built in. Even after migration to NIST’s initial standards, cryptographic agility — the ability to swap algorithms without redesigning the system — must be designed into architectures to handle future deprecations.
Recommended Actions
- Begin a cryptographic asset inventory immediately. Identify every location in your infrastructure where RSA, ECDH, or ECDSA are used: TLS certificates, VPNs, SSH, code signing, JWTs, and custom application cryptography. Commercial CryptoAgility or SBOM tooling can accelerate this.
- Classify data by sensitivity lifetime. Data that must remain confidential for more than 10 years requires the most urgent migration. Prioritise those systems for initial PQC deployment.
- Evaluate HSM upgrade paths. Contact hardware security module vendors now regarding FIPS 203/204 support timelines. Budget for hardware replacement if needed.
- Update TLS and VPN configurations to hybrid mode. Where infrastructure supports it, enable hybrid key exchange (e.g., X25519MLKEM768 in TLS 1.3) as an immediate risk reduction measure.
- Engage procurement teams. Any new technology acquisition in the next 12 months should include a contractual requirement for CNSA 2.0 or FIPS 203/204 support.
The organisations that will meet the 2027 deadline are those that started their cryptographic inventory in 2026. The question for security architects today is not whether to migrate — that was settled when NIST published its standards — but whether to migrate on a planned timeline or under emergency conditions.