Two threats from one machine
Your encrypted traffic is being harvested right now. Your authentication breaks the day a CRQC arrives.
Adversaries do not need a quantum computer to collect encrypted traffic now; they would need a cryptographically relevant quantum computer (CRQC) to decrypt quantum-vulnerable public-key protection later. No authoritative date for such a machine exists. The migration deadline is clearer: NIST and the UK NCSC point toward completing the transition by 2035, with high-risk systems moving earlier. The same future machine would also undermine classical public-key authentication - TLS certificates, code signing, JWTs, and audit anchors.
Anything encrypted today with classical RSA-2048, ECDH P-256, or Ed25519 - TLS sessions, S/MIME mail, signed JWTs, KMS-protected secrets, document vaults - has a finite confidentiality lifetime. If your data is valuable for more than ~3 years (financial records, medical records, defense communications, IP), the prudent assumption is that an adversary already has a copy of the ciphertext and is patient enough to wait for the quantum decryption hardware. And the same Shor-capable machine that breaks the encryption simultaneously breaks every classical signature still in use - including the signatures binding your software supply chain, your TLS identity, and your audit chains together.
The under-discussed half of the threat
Authentication is the faster failure mode
Most PQC writing focuses on encrypted-data confidentiality (HNDL). The second threat is authentication: the same Shor's algorithm that breaks RSA encryption also forges RSA, ECDSA, and Ed25519 signatures. Once a CRQC exists, an attacker can mint:
- Forged TLS certificates that pass classical CA-chain validation - perfect man-in-the-middle for any pre-PQC endpoint.
- Forged code-signing signatures - software updates that look authentic to every classical verifier.
- Forged JWTs and SAML assertions - including the long-lived ones still cached in your federation infrastructure.
- Forged audit-chain anchors - the historical record of who-did-what becomes unreliable evidence the day a CRQC exists.
Encrypted-data harvest is a problem about past ciphertext: prevention is impossible because the adversary already has the data; the only mitigation is to migrate forward and accept the residual risk. Authentication forgery is a problem about future validation: every signature you mint today with RSA / ECDSA / Ed25519 becomes forgeable the day Q-Day arrives. ML-DSA and SLH-DSA signatures minted today remain unforgeable. The migration window is the same; the consequences of missing it are different.
The timeline
Four dates that matter
2024
NIST finalized the first PQC standards.
FIPS 203 (ML-KEM, key encapsulation), FIPS 204 (ML-DSA, signatures), and FIPS 205 (SLH-DSA, hash-based signatures) are official US government standards. There are now production-ready post-quantum algorithms with NIST's name on them.
2026
The US Department of War set a five-year migration clock.
The DoW CIO memorandum (October 2026) mandates PQC hardening across the department within five years, requires that migration never downgrade security - explicitly excluding pre-shared keys, symmetric key distribution and quantum key distribution as substitutes - and creates a rapid-intake process for industry PQC solutions. Its PQC Strategy followed in June 2026 under Executive Order 14412. NIST published the final IR 8547 schedule on 27 October 2026. Sources: linkedin.com/pulse/post-quantum-cryptography-dow-cio-qud5c and csrc.nist.gov/pubs/ir/8547/final.
By 2028
Complete discovery and an initial migration plan.
The UK NCSC recommends that organizations discover cryptographic dependencies, define migration goals, and complete an initial migration plan by 2028.
By 2035
Complete the post-quantum migration.
NIST IR 8547 (final, October 2026) and the NCSC timeline both use 2035 as the general completion target, while calling for higher-risk systems to transition earlier. The report is explicit that this window does not move the federal deadlines sitting under it: high value assets and high impact systems need PQC key establishment by 31 December 2030 and digital signatures by 31 December 2031 (EO 14412 + OMB M-26-15), with TLS 1.3 required by 2 January 2030 (EO 14306). This is a migration target, not a prediction of when a CRQC will exist.
What HNDL actually is
Harvest-now, decrypt-later, in three steps
- Harvest. Nation-state actors and well-funded criminal groups record encrypted internet traffic at peering points, between data centers, and from compromised endpoints. The ciphertext is stored. The cost of storage is negligible compared to the value of breakable archives.
- Wait. Quantum computing capability advances. A cryptographically-relevant quantum computer (CRQC) - one large enough and stable enough to factor RSA-2048 in a practical timeframe - is the threshold. Its arrival date is uncertain, which is why migration guidance is based on risk and lead time rather than a claimed Q-Day forecast.
- Decrypt. Run Shor's algorithm against the harvested ciphertext. Anything encrypted with classical RSA, ECDH, or DSA becomes readable. Sessions, vaults, signed assertions - all of it.
Who's affected
If your data has a confidentiality lifetime over 5 years, you are.
Finance & banking
Settlement records, trade history, customer KYC documents, M&A data rooms. Regulated retention windows of 7+ years are the norm; harvested ciphertext becomes plaintext well within that window.
Healthcare & life sciences
Patient records (HIPAA: minimum 6-year retention; many states require 25+), clinical trial data, genomic sequences. Genomic data is the canonical worst case - confidential for the patient's lifetime.
Defense & intelligence
Classified communications, signal intelligence archives, mission planning artifacts. Adversary patience is unbounded; harvested traffic from 2020 read in 2032 is still actionable.
Legal & professional services
Privileged client communications, deal documents, litigation discovery. Attorney-client privilege doesn't expire; encrypted email from 2025 read in 2033 is still privileged content.
Critical infrastructure
Industrial control system commands, OT telemetry, grid coordination traffic. CISA's PQC migration guidance specifically calls out critical-infrastructure operators.
Identity & authentication providers
Long-lived signed assertions (SAML, OIDC ID tokens with non-trivial lifetimes), session tickets stored for forensics, federated audit chains. Once an old signature can be forged, the authentication trail is unreliable.
What a NIST-aligned migration looks like
A four-stage plan
1. Discover
Build a Cryptographic Bill of Materials (CBOM): every place classical crypto appears in your stack - TLS terminators, KMS keys, signed JWTs, document vaults, S/MIME, application-layer encryption, third-party SDKs. QNSI's apps/crypto-inventory-service auto-discovers from the codebase, the running fleet, and connected cloud accounts.
2. Prioritise by data lifetime
Sort the CBOM by how long the data underneath needs to remain confidential. Anything with a lifetime > 5 years is high priority - that's the data the adversary is most likely to harvest. Anything < 1 year is lower priority; the CRQC arrives after the data has lost value.
3. Migrate to hybrid PQC
Hybrid PQC (classical + ML-KEM concatenated key exchange) is the transition pattern most enterprises adopt. It's quantum-safe today and remains classical-safe if any single PQC algorithm is later weakened. QNSI's edge gateway terminates an explicitly selected hybrid PQC TLS target; @heossihq/qnsi defines ML-KEM-768 classical AEAD.
4. Sign post-quantum from day one
Long-lived signatures (code signing, audit-chain signatures, SAML/OIDC assertions) should switch to ML-DSA or SLH-DSA before retirement of the existing classical signing key. A signature created in 2026 with RSA-2048 is forgeable by whoever owns the CRQC in 2032 - by then the signature is no longer evidence.
Start the migration
QNSI gives you a NIST-aligned PQC stack with no infrastructure to operate
90 PQC algorithms across 14 families. ML-KEM and ML-DSA on every plan including Free. SLH-DSA on Strict and Maximum crypto-policy tiers. CBOM and PQC readiness-scoring contracts for eligible plans. Hybrid transport at the edge remains an evidence-gated deployment claim. One SDK per language across TypeScript, Python, Go, Rust, and JVM/Android.
Sources
Verifiable references
- FIPS 203 (ML-KEM) - NIST final standard for module-lattice key encapsulation, August 2024.
- FIPS 204 (ML-DSA) - NIST final standard for module-lattice digital signatures, August 2024.
- FIPS 205 (SLH-DSA) - NIST final standard for stateless hash-based signatures, August 2024.
- NIST PQC project page - ongoing standardisation status for additional KEMs and signatures (BIKE, SPHINCS+ variants, MAYO, CROSS, UOV, SNOVA).
- NIST SP 800-208 - recommendation for stateful hash-based signature schemes, the migration timeline reference.
- CISA - Post-Quantum Cryptography Initiative - federal civilian agency PQC migration program.
- NSA Cybersecurity Advisory CNSA 2.0 - Commercial National Security Algorithm Suite 2.0, the PQC successor to CNSA 1.0.