Post-Quantum Cryptography: What You Need to Know Now
Post-Quantum Cryptography: What You Need to Know Now
In August 2023, NSA, CISA, and NIST issued joint quantum-readiness guidance warning of what intelligence professionals had long assumed: nation-state adversaries are conducting harvest-now-decrypt-later operations against encrypted U.S. government and defense-industrial-base traffic. The encrypted communications being collected today will be readable the moment a cryptographically relevant quantum computer comes online --- and the data need not expire for that to matter. A classified cable with a 25-year confidentiality requirement intercepted in 2024 only needs to survive until 2049. The consensus timeline for a capable quantum computer falls well within that window.
On June 22, 2026, that warning became a mandate. Executive Order 14409 directed federal agencies to migrate to quantum-resistant cryptography and complete cryptographic modernization across national security systems. The question is no longer whether your organization will migrate. It is whether you will finish before the data you are protecting today becomes readable by an adversary who has already collected it.
Why the Clock Started Before the Computer Exists
Harvest-Now, Decrypt-Later Is Not Theoretical
The "harvest-now, decrypt-later" (HNDL) threat model describes adversaries collecting encrypted traffic today and storing it for future quantum decryption. This is not speculation about future capabilities --- it is a description of present-day operations. Intelligence agencies, advanced persistent threat groups, and nation-state signals intelligence programs have the storage capacity and collection infrastructure to stockpile encrypted communications at scale.
The implication is stark: data that must remain confidential for 10+ years is already at risk. CUI with a 25-year retention requirement. Classified national security information. Long-duration trade secrets. Protected health information. Financial records with extended regulatory retention. If the secrecy requirement extends beyond 2035, the PQC migration timeline is not "someday." It was yesterday.
How Current Cryptography Breaks
Modern public-key cryptography relies on the computational difficulty of specific mathematical problems:
- RSA: Security depends on the difficulty of factoring the product of two large prime numbers. Shor's algorithm, published in 1994, solves this in polynomial time on a quantum computer.
- Elliptic Curve Cryptography (ECC): Security depends on the elliptic curve discrete logarithm problem. Also solved by Shor's algorithm.
- Diffie-Hellman (DH/ECDH): Security depends on the discrete logarithm problem. Also vulnerable.
These are not edge cases. RSA, ECC, and DH/ECDH underpin TLS (every HTTPS connection), SSH (every remote administration session), VPN protocols, code signing, the entire PKI trust model, digital signatures, encrypted email, and cryptocurrency. When a cryptographically relevant quantum computer (CRQC) exists, the trust infrastructure of digital communication becomes vulnerable simultaneously.
Timeline Estimates
| Source | Estimated CRQC Timeline |
|---|---|
| NSA (CNSA 2.0) | Migration required by 2035 for most national security systems |
| NIST PQC project | Standards finalized 2024; migration should begin immediately |
| Global Risk Institute | 50% probability of CRQC by 2037 (2023 expert survey) |
| National Academies | Highly unlikely within a decade; longer-term arrival too uncertain to predict (2019 report, still broadly cited) |
The consistent message: begin migration now, complete migration before 2035, assume HNDL attacks are already occurring.
NIST Post-Quantum Cryptography Standards
After an 8-year evaluation process that began in 2016, NIST finalized three PQC standards in August 2024.
FIPS 203: ML-KEM (Module-Lattice-Based Key Encapsulation Mechanism)
Purpose: Key encapsulation --- securely establishing shared secret keys between parties. Replaces RSA key exchange and ECDH key agreement.
Based on: CRYSTALS-Kyber. Security relies on the Module Learning With Errors (MLWE) problem, believed resistant to both classical and quantum attacks.
| Parameter Set | Security Level | Public Key Size | Ciphertext Size |
|---|---|---|---|
| ML-KEM-512 | NIST Level 1 (AES-128 equivalent) | 800 bytes | 768 bytes |
| ML-KEM-768 | NIST Level 3 (AES-192 equivalent) | 1,184 bytes | 1,088 bytes |
| ML-KEM-1024 | NIST Level 5 (AES-256 equivalent) | 1,568 bytes | 1,568 bytes |
Practical impact: Key sizes are larger than RSA/ECC equivalents but manageable. ML-KEM is fast --- key generation, encapsulation, and decapsulation are all significantly faster than RSA at comparable security levels.
FIPS 204: ML-DSA (Module-Lattice-Based Digital Signature Algorithm)
Purpose: Digital signatures --- authentication, integrity, and non-repudiation. Replaces RSA signatures, ECDSA, and EdDSA.
Based on: CRYSTALS-Dilithium. Security relies on MLWE and Module Short Integer Solution (MSIS) problems.
| Parameter Set | Security Level | Public Key Size | Signature Size |
|---|---|---|---|
| ML-DSA-44 | NIST Level 2 | 1,312 bytes | 2,420 bytes |
| ML-DSA-65 | NIST Level 3 | 1,952 bytes | 3,309 bytes |
| ML-DSA-87 | NIST Level 5 | 2,592 bytes | 4,627 bytes |
Practical impact: Signatures are substantially larger than ECDSA (64 bytes). Applications transmitting or storing large numbers of signatures --- certificate chains, code signing repositories, blockchain --- require capacity planning.
FIPS 205: SLH-DSA (Stateless Hash-Based Digital Signature Algorithm)
Purpose: Digital signatures with minimal, well-understood security assumptions. Intended as a diversification option.
Based on: SPHINCS+. Security relies only on the underlying hash function --- making it the most conservative PQC option. If lattice-based assumptions are ever broken, SLH-DSA remains secure.
Trade-off: Signatures up to 49,856 bytes at the highest security level. Signing is slower. Intended for certificate roots, long-lived signing keys, and use cases where algorithmic diversity outweighs size constraints.
Upcoming: FIPS 206 (Expected)
NIST is expected to standardize FN-DSA (Falcon) with smaller signatures than ML-DSA but more complex implementation. Organizations should not wait for it --- FIPS 203, 204, and 205 are sufficient to begin migration today.
Executive Order 14409 and Cryptographic Modernization
EO 14409, signed June 22, 2026, directs federal agencies toward quantum-resistant cryptography as part of a broader cryptographic modernization mandate. The order touches:
- Encryption of data at rest and in transit using current best practices --- which now explicitly includes PQC algorithms for new deployments.
- Zero Trust Architecture deployment, which relies on cryptographic authentication at every layer --- all of which must transition to quantum-resistant algorithms.
- Software supply chain security, including code signing and integrity verification, both of which require PQC-capable signing infrastructure.
- Cryptographic Bill of Materials (CBOM) requirements, documenting the cryptographic algorithms embedded in software dependencies --- a prerequisite for knowing what needs to migrate.
EO 14409 transforms PQC from a forward-looking best practice into a compliance requirement with deadlines.
NSA CNSA 2.0 Timeline
The NSA's Commercial National Security Algorithm Suite 2.0 defines PQC adoption timelines for national security systems:
| Capability | Required Algorithm | Required By |
|---|---|---|
| Software/firmware signing | LMS or XMSS (SP 800-208 hash-based) | 2025 (preferred immediately) |
| Web browsers/servers (TLS) | ML-KEM-1024, ML-DSA-87 | 2025 |
| Traditional networking (VPN, routers) | ML-KEM-1024, ML-DSA-87 | 2026 |
| Operating systems | ML-KEM-1024, ML-DSA-87 | 2027 |
| Custom/legacy applications | PQC algorithms as applicable | 2033 |
| Complete migration of all NSS | All PQC | 2035 |
For defense contractors and federal agencies, these timelines are requirements, not aspirations. The 2025 and 2026 dates are already here.
The PQC Migration Process
Step 1: Cryptographic Inventory
You cannot migrate what you have not inventoried. Catalog algorithms in use (RSA-2048, ECDSA P-256, Ed25519, etc.), where they are used (TLS endpoints, SSH, VPN, code signing, encryption at rest), key sizes and parameters, certificate chains and expiration dates, third-party dependencies (libraries, HSMs, cloud APIs), and data retention periods that determine HNDL risk exposure.
Step 2: Risk Assessment
Prioritize by data sensitivity and lifespan (CUI with 25-year retention outranks session tokens), exposure to HNDL (data on public networks is more vulnerable to collection than air-gapped systems), and criticality (national security and financial systems take priority).
Step 3: Algorithm Selection
For most organizations: ML-KEM-768 (FIPS 203) for key agreement in TLS, IPsec, SSH --- ML-KEM-1024 for the most sensitive applications. ML-DSA-65 (FIPS 204) for general-purpose signatures. SLH-DSA (FIPS 205) as a diversification option for certificate roots and long-lived signing keys.
Step 4: Hybrid Deployment
During transition, hybrid schemes combine classical and PQC algorithms. A TLS handshake uses both ECDH and ML-KEM; the shared secret derives from both. Hybrid deployment provides security against both classical and quantum attacks and guards against undiscovered classical vulnerabilities in the new PQC algorithms.
Step 5: Full Migration
Once PQC algorithms are validated through hybrid deployment, transition to PQC-only. This requires upstream and downstream PQC support, HSM/hardware upgrades, updated compliance documentation, and performance validation at scale.
The Contrarian Take: Most Organizations Are Over-Indexing on Timeline Uncertainty
Here is the opinion that gets pushback at conferences: the timeline debate is a distraction that serves the interests of organizations who want to delay. Whether CRQC arrives in 2033 or 2040 is irrelevant to the migration decision. The migration itself takes 3-7 years for a large organization. CNSA 2.0 deadlines are already passing. HNDL is already happening. The only scenario where delay is rational is one where your data has zero long-term confidentiality value --- and if that were true, you would not be encrypting it in the first place. Organizations spending energy debating "when" are avoiding the harder question of "how" --- and every quarter of delay is a quarter of intercepted traffic that cannot be retroactively protected.
Challenges
Larger Key and Signature Sizes. ML-KEM public keys are 3-5x larger than RSA-2048. ML-DSA signatures are 40-70x larger than ECDSA. This affects TLS handshake latency, certificate chain size, IoT/constrained devices, and storage requirements.
Performance Differences. ML-KEM is generally faster than RSA but uses more bandwidth. ML-DSA signing is faster than RSA but verification is slower than ECDSA. SLH-DSA signing is significantly slower than both alternatives. Performance testing with realistic workloads is essential.
Algorithm Maturity. FIPS 203 and 204 are based on lattice problems that have been studied extensively but are newer than the decades-long track record of RSA/ECC. This is why FIPS 205 (hash-based, minimal assumptions) exists for diversification and why hybrid deployment is recommended.
Interoperability. PQC cannot happen in isolation. Every communicating system must also support PQC --- creating coordination challenges with cloud providers, certificate authorities, HSM vendors, software vendors, and partner organizations.
Key Takeaways
- EO 14409 (signed June 22, 2026) makes PQC migration a federal mandate, not a best practice.
- Harvest-now-decrypt-later operations are active today. Data with 10+ year confidentiality requirements is already at risk.
- FIPS 203 (ML-KEM), 204 (ML-DSA), and 205 (SLH-DSA) are finalized. There is nothing to wait for.
- CNSA 2.0 timelines for software signing and TLS have already arrived (2025). Network equipment deadlines hit 2026.
- Start with cryptographic inventory. You cannot migrate what you have not cataloged.
- Hybrid deployment (classical + PQC) is the recommended transition strategy --- it de-risks migration without sacrificing quantum resistance.
FAQ
How soon do we need to start PQC migration?
If you handle data with confidentiality requirements extending beyond 2035 --- and most federal contractors do (CUI retention, classified material, long-duration contracts) --- migration should already be underway. CNSA 2.0 required PQC for software signing and TLS by 2025. The full migration deadline is 2035. Given that enterprise PQC migration takes 3-7 years, organizations starting in 2027 are already on a compressed timeline.
Does PQC break existing systems during migration?
Not if you use hybrid deployment. Hybrid schemes (classical + PQC simultaneously) maintain backward compatibility while adding quantum resistance. Both algorithms must be broken for the communication to be compromised. This is why NIST and NSA both recommend hybrid as the transition strategy --- you gain protection without breaking interoperability with systems that have not yet migrated.
What about symmetric cryptography --- is AES-256 quantum-safe?
Largely yes. Grover's algorithm gives quantum computers a quadratic speedup against symmetric ciphers, effectively halving the security level (AES-256 becomes AES-128 equivalent against quantum attack). AES-256 remains secure. AES-128 should be phased out for high-value data. The urgent migration is public-key cryptography (key exchange, digital signatures) --- the systems protected by RSA, ECC, and DH that Shor's algorithm breaks completely.
What is a Cryptographic Bill of Materials (CBOM) and do we need one?
A CBOM catalogs every cryptographic algorithm, key size, and protocol used in your software and its dependencies --- the same concept as an SBOM but focused on cryptographic primitives. EO 14409 requires understanding your cryptographic posture as a prerequisite for migration. Without a CBOM, you cannot identify what needs to migrate, what is already quantum-safe, or where vulnerable algorithms are hiding in third-party dependencies. Yes, you need one.
Can we just wait for our cloud provider to handle PQC?
Partially. Major cloud providers are implementing PQC for TLS and key management at the infrastructure layer. But PQC migration extends beyond infrastructure: code signing keys, stored encrypted data, custom protocols, partner integrations, embedded/IoT devices, and application-layer cryptography all require your own migration effort. Your cloud provider handles their layer; you handle yours. And you still need the inventory and CBOM regardless.
How Advisedly Helps
Advisedly includes a post-quantum cryptography readiness module built against Executive Order 14409 and CNSA 2.0 timelines. The platform provides a cryptographic inventory tracker that catalogs your organization's cryptographic assets and produces a CBOM. From that inventory, your team builds a structured PQC migration plan --- tracking readiness across 18 PQC algorithm categories and mapping progress against CNSA 2.0 deadlines. The module supports FIPS 203, 204, and 205 and integrates PQC readiness into your broader compliance posture alongside frameworks like FedRAMP, CMMC, and NIST 800-171. Contact us at begin@advisedly.ai to see how far your cryptographic inventory is from quantum-ready.