QubitAC — Harvest-Now, Decrypt-Later: What to Migrate First

The Attack Is Already Happening

Harvest-Now, Decrypt-Later (HNDL) is not a future risk. It is a present one. Nation-state adversaries are intercepting and archiving encrypted traffic today, specifically targeting data whose value will outlast the time it takes to build a sufficiently powerful quantum computer.

The implication is uncomfortable: your migration deadline is not Q-Day. It is right now, for any data that must remain confidential beyond the next 5–15 years. Traffic captured today will sit in cold storage until a cryptographically relevant quantum computer exists. Then it gets decrypted in bulk.

You don't need to finish migrating everything before Q-Day. You need to stop generating harvestable traffic before Q-Day. That's a much earlier deadline — and it applies selectively, based on what you're protecting.

Why "Migrate Everything" Is the Wrong Frame

Most organizations, when they hear "post-quantum migration," imagine a sprawling multi-year project: find every RSA key, every TLS endpoint, every certificate, and replace them. That instinct leads to paralysis. The asset surface is enormous and the urgency feels abstract.

The right frame is not completeness; it's exposure. Not all encrypted data carries the same HNDL risk. A TLS session protecting a public webpage carries near-zero long-term confidentiality value. A session carrying patient records, financial terms, or state secrets is an entirely different exposure profile.

The question to answer for every system is: if this traffic were decrypted in 10 years, what is the damage? That answer determines where you move first.

⚠ The Core Mistake

Prioritizing PQC migration by technical footprint ("we have 40,000 RSA keys, let's start there") instead of by confidentiality lifetime. Volume is not the same as risk. Start with lifetime, not count.

The Four Migration Tiers

Below is a concrete prioritization framework. Move through these tiers in order. Tier 1 is harvestable now and damaging forever. Tier 4 can wait — the blast radius is bounded and near-term.

1

Long-lived confidentiality data

Migrate immediately — highest HNDL exposure

Any data whose confidentiality must hold for more than 5–10 years is harvestable today and vulnerable at Q-Day. This includes health records, legal communications, financial agreements, strategic IP, classified or sensitive government data, and long-term personal data under GDPR-class retention.

These are the assets HNDL adversaries specifically target. Sessions using static RSA key exchange are the worst case: the session key is protected only by the server's long-term RSA private key, so every recorded session using that key can be decrypted with a single private key derivation at Q-Day. Sessions using ECDHE are also quantum-vulnerable (Shor's algorithm breaks the elliptic curve discrete log), but each session used a fresh ephemeral key pair, so each requires its own separate quantum computation rather than a single master key recovery. Both warrant migration; RSA key exchange is the more urgent priority within Tier 1.

Health records (HL7/FHIR) Legal & financial comms Strategic IP in transit Government classified data Long-term personal data

2

Trust anchors — root CAs and signing keys

Migrate before Q-Day — systemic blast radius

Root certificate authorities and long-lived signing keys are not a confidentiality risk; they are an integrity risk. This is distinct from HNDL. The threat is not retroactive decryption of recorded traffic; it is that once a cryptographically relevant quantum computer exists, an adversary can derive your CA's private signing key from its public key and forge certificates going forward. There is no "harvest now" phase for CA signing keys, but the "decrypt later" moment (Q-Day) is when the forgery attack becomes possible.

The blast radius is systemic: a quantum adversary who derives your root CA private key can forge any certificate in your hierarchy — creating fraudulent TLS certificates, code-signing certificates, or identity certificates that relying parties accept as legitimate. Existing issued certificates are not retroactively invalidated, but the adversary gains the ability to impersonate any entity your CA vouches for, going forward from Q-Day. Migrating to ML-DSA (Dilithium) signatures for root and intermediate CAs before Q-Day closes this permanently.

Root CAs Intermediate CAs Code signing keys Firmware signing Document signing infrastructure

3

Identity and authentication systems

Migrate before Q-Day — durable credential risk

Authentication systems that rely on long-lived asymmetric keys have a compounding risk: the public key is observable in traffic or retrievable from public directories, and a quantum adversary who records that material can later derive the private key via Shor's algorithm. This enables impersonation, session hijacking, or unauthorized access — not at the time of capture, but at Q-Day.

SSH host keys are a particular concern: widely deployed, rarely rotated, and their public keys are trivially observable in network traffic. SSH uses the host private key for server authentication, not for encrypting session content. An adversary who collects that public key can derive the host private key at Q-Day and impersonate that server going forward — forging authentication to fool clients into trusting a fake host. Zero-trust architectures that rely on asymmetric device identity are similarly exposed.

SSH host keys Long-term API credentials Device attestation certs FIDO2 / WebAuthn keys VPN authentication

4

General TLS endpoints — public-facing web traffic

Plan now, migrate before Q-Day — bounded blast radius

General web traffic under TLS (your public website, marketing pages, low-sensitivity API endpoints) carries short-lived session data. Even if harvested and later decrypted, the confidentiality damage is limited: a shopping session from 2026 is not strategically valuable in 2035.

This tier still needs migration before Q-Day, but it is not where HNDL pressure is most acute today. You have time to migrate this tier as part of a normal infrastructure cadence; the urgency is measured in years, not months. The exception: if any of these endpoints carry longer-lived session tokens or authentication data, reclassify them to Tier 3.

Public web properties CDN edge termination Low-sensitivity APIs Marketing & docs sites

The Prioritization Matrix

Use this matrix when triaging your cryptographic asset inventory. Cross-reference confidentiality lifetime against blast radius to place each system in the right tier.

Asset type	Confidentiality lifetime	Blast radius if broken	HNDL priority
Health / legal / financial records	10–30+ years	Individual + regulatory	Tier 1 — Now
Root & intermediate CAs	N/A: integrity risk, not confidentiality	Entire PKI hierarchy (forward forgery)	Tier 2 — Before Q-Day
Code / firmware signing keys	Lifetime of signed artifacts	Supply chain integrity	Tier 2 — Soon
SSH host keys	Until rotated (often years)	Server impersonation	Tier 3 — Soon
Device attestation / VPN auth	Device lifetime	Network access, identity	Tier 3 — Soon
General TLS web traffic	< 1 session (minutes–hours)	Limited, session-scoped	Tier 4 — Plan
Ephemeral API tokens	Minutes	Minimal	Tier 4 — Later

What "Migrating" Actually Means

For Tier 1 (long-lived confidentiality data), migration means deploying hybrid key exchange: running a classical algorithm (ECDH) in parallel with a post-quantum KEM (ML-KEM / Kyber). The session key is derived from both; an adversary must break both algorithms to recover it. This is the approach Chrome, Firefox, and Cloudflare are already deploying in production.

For trust anchors (Tier 2), the migration is about signatures, not key exchange. Root and intermediate CAs don't do key encapsulation; they sign certificates. The migration here means issuing new roots and intermediates using ML-DSA (Dilithium) alongside your existing ECDSA/RSA hierarchy, then planning the trust distribution and transition window before your current roots expire. ML-KEM is not relevant to this tier.

For identity systems (Tier 3), it means auditing which credentials are derived from asymmetric operations, rotating long-lived keys that have been exposed in observable traffic, and moving to PQC-signed attestation for new device enrollments.

ℹ Hybrid is the right starting point

Pure PQC is not yet universally supported by clients and libraries. Hybrid classical + PQC gives you quantum resistance now without breaking compatibility. It is the NIST-recommended transition posture and what the major TLS stacks are shipping first.

Before You Can Migrate: You Need a CBOM

None of this prioritization is possible without knowing what you have. You cannot triage by confidentiality lifetime if you don't know which systems are using RSA key exchange versus ECDHE, which certificates are signed by which roots, or where long-lived credentials are being generated and exposed.

A Cryptographic Bill of Materials (CBOM) is a structured inventory of every cryptographic asset across your infrastructure, and it is the prerequisite. Without it, you're guessing. With it, you can map every asset to a tier and start migrating in priority order.

The QubitAC Scanner produces a CBOM as its output: run it against your TLS endpoints, and it surfaces the key exchange algorithms, certificate chains, protocol versions, and PQC readiness signal for each host. That's the starting inventory your Tier 1 decisions depend on.

✓ Start here

Run the QubitAC Scanner against your highest-sensitivity domains first, the ones carrying health, legal, or financial data. That CBOM output tells you exactly which sessions are using RSA key transport (immediate Tier 1 risk) versus ECDHE (still quantum-vulnerable but no static key exposure). That distinction drives your first concrete migration decision.

The Practical Migration Checklist

Classify your data by confidentiality lifetime Ask: if this were decrypted in 10 years, what is the damage? Health, legal, financial, and strategic data almost always belongs in Tier 1. This classification drives everything else.
Run a CBOM scan on Tier 1 systems first Identify which Tier 1 channels are using RSA key transport; these are your maximum HNDL exposure. Any session using static RSA key exchange today is in an adversary's archive.
Disable RSA key exchange on all Tier 1 endpoints immediately Enforce ECDHE-only cipher suites and disable RSA key transport cipher suites at every TLS termination point: servers, load balancers, and any middleboxes. Legacy stacks may need library upgrades first; audit your full termination inventory before assuming this is a simple change.
Deploy hybrid ML-KEM key exchange on Tier 1 TLS Enable X25519MLKEM768 on servers running OpenSSL 3.x, BoringSSL, or AWS-LC. Clients that support it will negotiate quantum-resistant sessions automatically; others fall back to classical ECDHE.
Audit and rotate long-lived keys that have been observable in traffic SSH host keys, VPN auth keys, and device attestation certificates expose their public keys in observable network traffic. A quantum adversary who captured that material can derive the corresponding private keys at Q-Day, enabling forward impersonation of those hosts and devices. For any keys also used in key encapsulation (not just signing), past captured sessions may also be decryptable. Rotate long-lived keys now and move to shorter rotation cycles going forward.
Begin the root CA transition planning Issuing ML-DSA root and intermediate certificates takes time; new roots need to be distributed and trusted before old ones expire. Start this process now so the transition window aligns with your existing PKI renewal cycles.
Treat Tier 4 as a normal infrastructure cadence item Public web traffic doesn't need emergency treatment. Track it in your CBOM, plan the migration into your regular TLS library upgrade cycle, and ensure TLS 1.3 is enforced as a prerequisite.