NIST finalised three post-quantum cryptography standards in August 2024: FIPS 203 (ML-KEM, based on CRYSTALS-Kyber), FIPS 204 (ML-DSA, based on CRYSTALS-Dilithium), and FIPS 205 (SLH-DSA, based on SPHINCS+). These standards define the algorithms that will replace RSA and elliptic curve cryptography as quantum computers mature to the point where Shor's algorithm can break asymmetric encryption at scale. NIST recommends beginning the transition away from RSA and ECC before 2030. CNSS Policy 15 mandates that National Security Systems complete the transition by 2033.
The Harvest Now, Decrypt Later Threat
The urgency of post-quantum cryptography migration is not only a function of when cryptographically relevant quantum computers will be available. It is also a function of how long the data encrypted today must remain confidential. The harvest now, decrypt later threat is active today: adversaries are collecting encrypted network traffic with the intention of decrypting it when capable quantum computers are available. For healthcare data that must remain confidential for decades, financial records subject to long retention requirements, and classified government information, the relevant question is not whether quantum computers exist today but whether they will exist within the data's required confidentiality window.
HIPAA, FISMA, and financial services data retention requirements create situations where data encrypted in 2024 must remain confidential through 2030 or beyond. For this data, the migration to post-quantum cryptography is already overdue from a risk management perspective, regardless of the regulatory deadline.
The Cryptographic Inventory Problem
The primary engineering challenge of post-quantum migration is not implementing the new algorithms. ML-KEM and ML-DSA are available in major cryptography libraries including OpenSSL 3.x, BoringSSL, and the AWS libcrypto fork. The challenge is finding every place in the enterprise technology stack where RSA or ECC is used. The cryptographic surface area of a large enterprise includes: TLS certificates and the CAs that issue them, SSH keys, code signing certificates, JWT signing keys, database connection encryption, storage encryption key wrapping, HSM-managed keys for financial transactions, IPsec VPN configurations, and application-level signature generation in countless forms.
Most organisations do not have a current inventory of their cryptographic assets. Discovering the inventory requires active scanning -- network traffic analysis to identify TLS cipher suites in use, static analysis of application code for hardcoded cryptographic calls, infrastructure configuration review, and vendor documentation review for third-party systems. This inventory is the necessary prerequisite for migration planning and is typically a multi-month effort for a large enterprise.
Crypto-Agility Architecture
The architectural pattern that makes post-quantum migration tractable without rewriting every system that uses cryptography is crypto-agility: designing cryptographic operations behind configurable interfaces rather than hardcoding algorithm choices in application code. A crypto-agile architecture has a central cryptography service or library that all applications use for cryptographic operations, with the algorithm selection driven by configuration rather than code. When the configuration changes from RSA-2048 to ML-KEM, every application that uses the central service gets the updated algorithm without requiring application changes.
Crypto-agility cannot be retrofitted easily into applications that call cryptographic primitives directly. The migration effort for non-agile applications includes not only the algorithm change but the refactoring required to introduce the abstraction layer. For large enterprise codebases, this refactoring effort often dominates the total migration cost.
Hybrid Cryptography During the Transition
During the migration period, hybrid cryptography -- combining classical and post-quantum algorithms in the same key exchange or signature operation -- provides security against both classical and quantum attackers. A hybrid TLS handshake that combines X25519 (classical elliptic curve) with ML-KEM provides protection even if one of the algorithms is broken. NIST and NSA guidance endorses hybrid approaches during the transition period for high-value data. The TLS 1.3 specification supports hybrid key exchange through the supported_groups extension, and several major TLS libraries have implemented hybrid group configurations.
Regulatory and Compliance Timelines
Beyond the NIST 2030 recommendation and the CNSS 2033 mandate, financial services and healthcare regulators are beginning to address post-quantum requirements. The ECB has issued guidance to European banks on post-quantum readiness. DORA Article 6 ICT risk management requirements can be interpreted to require that firms assess and plan for quantum computing risks to their cryptographic controls. FedRAMP continuous monitoring will require FIPS 203/204/205 implementation for CSPs serving US federal agencies. Firms that begin the cryptographic inventory and crypto-agility architecture work now will have the lead time to meet these regulatory deadlines without crisis-mode remediation.
EU AI Act: What CTOs Actually Need to Do Before August 2026
The Vendor Rescue Pattern: How to Recover a Failed Implementation in 12 Weeks
The LLM Hallucination Problem in Regulated Environments: What 'Acceptable Error Rate' Actually Means
The engineering behind this article is available as a service.
We have done this work — not advised on it, not reviewed documentation about it. If the problem in this article is your problem, the first call is with a senior engineer who has solved it.