Why Post-Quantum Cryptography Can’t Wait: The Case for Acting Before Quantum Computers Arrive

March 1, 2026

Waiting for a “Q-day” announcement is risky. Adversaries can harvest encrypted data now and decrypt it later, long before you notice—especially data with multi-year confidentiality needs. Meanwhile, standards are finalized, government timelines are published, and mainstream platforms already ship post-quantum protections. Start migration planning now.

The threat is present-tense, not sci-fi

Harvest-now, decrypt-later (HNDL) attacks collect ciphertext today, banking on future decryption when quantum capability matures. That puts long-lived data—contracts, health records, source code, M&A files—at immediate risk.
U.S. agencies (CISA/NSA/NIST) explicitly warn organizations to create a quantum-readiness roadmap now, emphasizing inventories and prioritization precisely because HNDL is already happening.

Key point: Your risk is a function of data lifespan, not the date a large quantum computer is built. If the data must stay secret for 5–15 years, the window to protect it is today.

The standards are done—and the ecosystem is moving

NIST finalized the first three post-quantum cryptography (PQC) standards in August 2024: FIPS 203 (ML-KEM) for key establishment, FIPS 204 (ML-DSA) for signatures, and FIPS 205 (SLH-DSA) as a hash-based signature alternative.
CNSA 2.0 (NSA) sets federal/NSS transition expectations into the 2030s (e.g., new acquisitions compliance, phase-outs, and algorithm deprecations), which spill into vendor roadmaps and supply chains.
Browsers/CDNs already ship hybrids: Chrome enabled hybrid ML-KEM in TLS 1.3/QUIC; Cloudflare deploys X25519MLKEM768 across its network and tracks origin readiness—evidence that PQC is no longer a lab exercise.

“But quantum computers aren’t here yet…” — Why that argument fails

Data outlives devices. If attackers record today’s traffic and decrypt in 5–10 years, confidentiality is still lost. This is exactly why CISA/NSA/NIST stress beginning inventories and migration planning now.
Upgrading crypto takes years. Past transitions (MD5→SHA-1→SHA-256, TLS 1.0/1.1 deprecations) took longer than expected; PQC is larger in scope. Government timelines reflect that reality.
You’re not first. OpenSSH added hybrid post-quantum KEX; secure messengers are adopting hybrid handshakes (e.g., Signal’s PQXDH); MLS (RFC 9420) standardizes scalable E2EE for groups—your migration will stand on well-trod ground.

What changes—and what doesn’t

Broken by quantum: public-key schemes based on factoring/discrete logs (RSA, DH, ECDH/ECDSA). These must be replaced in handshakes and signatures to avoid future compromise. U.S. guidance highlights this in quantum-readiness materials.
Barely affected: symmetric crypto and hashes (AES/SHA-2/SHA-3) typically need only stronger parameters, not replacement. Focus your effort where it matters: key exchange and signatures.

Signals that “later” is already too late

Standards finalized—no need to wait: ML-KEM/ML-DSA/SLH-DSA are production-ready profiles, not proposals.
Mainstream deployments: Chrome’s ML-KEM rollout and Cloudflare’s hybrid TLS are in production, protecting traffic at Internet scale.
Policy momentum: CNSA 2.0 timelines and procurement guidance will force compliance across government suppliers and adjacent industries. Start now to avoid rushed, fragile transitions.

A 12-month action plan (pragmatic and staged)

Quarter 1 — Inventory & risk framing

Build a cryptography bill of materials: where do RSA/ECC appear (TLS, SSH, S/MIME, code-signing, PKI, backups, messaging)? Prioritize long-lived data and external-facing services. (This mirrors CISA/NSA/NIST’s roadmap.)

Quarter 2 — Quick security wins

Enable hybrid TLS 1.3 (X25519+ML-KEM) at the edge and gateways; monitor for middlebox issues and fallbacks—Chrome/Cloudflare experience shows this is tractable.
Start pilot E2EE for high-risk collaboration: use standards-based group E2EE (MLS, RFC 9420) and adopt hybrid handshakes (e.g., PQXDH-style) where applicable.

Quarter 3 — Identity & signing

Add PQC-ready signatures in your pipeline: test ML-DSA (or dual-signing) for software releases; consider SLH-DSA/LMS/XMSS for firmware/boot and high-assurance cases. (All standardized or NIST-approved.)

Quarter 4 — Scale-out & governance

Bake CNSA 2.0-aligned milestones into vendor contracts and SLAs; require partner roadmaps; track % hybrid handshakes, % PQC-signed artifacts, and legacy retirement.

Executive FAQ

“Can’t we wait for ‘real’ quantum computers?”
No. Attackers don’t need them to steal the ciphertext today; they only need them later to break it. That’s the HNDL model federal guidance warns about.

“Are these algorithms stable enough?”
Yes—NIST FIPS are final and backed by years of public review; agencies and industry are deploying hybrids at Internet scale right now.

“What if we break compatibility?”
Use hybrid approaches first (classical + PQC) to maintain compatibility while gaining future confidentiality—Chrome’s rollout and Cloudflare’s network are living proofs.

The takeaway

Quantum computing’s timeline is uncertain; your exposure window isn’t. Standards, guidance, and real deployments exist today. A reasonable plan—inventory → hybrid TLS → PQC-ready E2EE and signatures → governance—lets you protect high-value data before attackers can read it, and long before auditors force you to scramble.

References

CISA/NSA/NIST: Quantum-Readiness: Migration to Post-Quantum Cryptography (roadmap, HNDL rationale).
NIST FIPS 203/204/205: ML-KEM, ML-DSA, SLH-DSA (Aug 2024).
NSA CNSA 2.0: algorithm selections and transition expectations.
Browser/CDN deployments: Chrome’s ML-KEM rollout; Cloudflare X25519MLKEM768 deployment and monitoring.
E2EE standards: Messaging Layer Security (MLS), RFC 9420.
Hybrid adoptions elsewhere: OpenSSH hybrid KEX; Signal’s PQXDH handshake.