QNSP

Two threats from one machine

Your encrypted traffic is being harvested right now. Your authentication breaks the day a CRQC arrives.

Adversaries don't need a quantum computer to start the harvest — they only need it to finish. The collection phase has been running for years; the decryption phase will start when cryptographically-relevant quantum computers (CRQCs) arrive. Cloudflare and Google now publicly anchor on Q-Day 2029, compressed from the prior NIST 2030–2035 window. The same machine that decrypts the harvested traffic also forges every classical signature still in production — TLS certs, code signing, JWTs, 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). Cloudflare, Google, and the broader infrastructure community spent the first half of 2026 re-anchoring the conversation on the second threat: 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

Three 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.

2030

NIST SP 800-208 deprecates classical algorithms.

NIST SP 800-208 sets a timeline that disallows RSA, ECDSA, and other quantum-vulnerable algorithms in new federal systems. CISA and the NSA have issued aligned guidance for critical infrastructure.

2029 (compressed)

Q-Day per the 2026 vendor reframe.

Cloudflare and Google now publicly anchor on a 2029 Q-Day estimate, compressed from the prior NIST 2030–2035 window. The trailing-edge NIST window remains the conservative bound, but the leading-edge public-vendor estimate has moved in. A cryptographically-relevant quantum computer at any point in this 2029–2035 range breaks all classical key exchange and all classical signatures.

What HNDL actually is

Harvest-now, decrypt-later, in three steps

  1. 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.
  2. Wait. Quantum computing capability advances. A cryptographically-relevant quantum computer (CRQC) — one large enough and stable enough to factor RSA-2048 in hours — is the threshold. The mainstream estimate is 2030–2035; conservative estimates are sooner.
  3. 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. QNSP'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. QNSP's edge gateway terminates hybrid PQC TLS by default; @qnsp/qnsp wraps payloads with ML-KEM-768 alongside 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

QNSP gives you a NIST-aligned PQC stack with no infrastructure to operate

89 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 on every Enterprise tier. Hybrid PQC TLS at the edge gateway. One SDK per language across TypeScript, Python, Go, and Rust.

Start free →Run the live PQC sandboxRead the platform overview

Sources

Verifiable references