What the Attack Actually Is
The harvest-now, decrypt-later attack is not speculative. The operational pattern is straightforward: an adversary captures encrypted network traffic today, stores it at scale, and waits until cryptographically relevant quantum computers mature enough to break RSA and elliptic curve Diffie-Hellman (ECDH). The attacker does not need quantum computing capability now. They need storage capacity and patience, both of which are cheap.
For organizations protecting data with long confidentiality requirements, this matters immediately. An interbank transaction encrypted with RSA-2048 in 2024 that carries a 10-year legal confidentiality obligation becomes exposed the moment a capable quantum adversary arrives, regardless of when the data was captured. The collection is happening now. The decryption happens later.
The Timeline Calculation That Most Risk Assessments Get Wrong
The standard risk framing treats quantum computing as a future trigger: "quantum computers do not exist yet, so we have time." This framing ignores the data lifecycle dimension. The correct question is not "when will quantum computers break RSA?" but "how long must this data remain confidential, and will that period overlap with quantum computing maturity?"
Consider the exposure window for a mid-size private bank in Southeast Asia. Core banking system communications are encrypted with 2048-bit RSA. Some of those session keys protect records that carry 15-year retention obligations under local financial regulation. Current consensus from public research suggests cryptographically relevant quantum computers (CRQCs) in the 5-10 year range for RSA-2048 attacks. If an adversary began capturing that bank's interbank traffic in 2024, the data collected will still be within its confidentiality window when the quantum threat matures. The exposure is not future: it started when the collection started.
The calculation has three variables: data longevity, migration lead time, and quantum computing maturity. Most risk models treat only the third variable as uncertain. The first two are controllable, but only if organizations start acting now.
Which Network Types Face the Highest Exposure
Not all encrypted traffic has equal harvest-now exposure. The risk is highest where three conditions coincide: long data confidentiality requirements, identifiable high-value payloads, and adversaries with long collection mandates and storage resources.
Financial services communication sits at the top of this exposure profile. Interbank settlement messages, SWIFT wire traffic, and payment authorization flows are finite in volume (making selective collection practical), carry identifiable counterparty information, and have regulatory confidentiality obligations that extend years beyond the transaction date.
Critical infrastructure telemetry is a different but equally serious case. Power grid SCADA communications are lower in transaction frequency than financial traffic, but the operational intelligence embedded in control system telemetry, grid topology data, and substation configuration messages is strategically sensitive on a multi-year horizon. An adversary who can decrypt historical telemetry gains insight into grid architecture that informs future disruption planning.
Government diplomatic communications and signals intelligence channels present obvious long-horizon confidentiality requirements. Less discussed are the supply chains around these communications: the infrastructure vendors, the third-party integrators, and the upstream network providers whose encrypted traffic touches sensitive data without being classified themselves.
RSA and ECC Are Specifically Vulnerable, Not Encryption Generally
It is worth being precise about what quantum computers break and what they do not. Shor's algorithm, which is the theoretical basis for quantum attacks on public-key cryptography, targets the mathematical problems underlying RSA (integer factorization) and elliptic curve key exchange (discrete logarithm on elliptic curves). It does not meaningfully weaken well-implemented symmetric ciphers like AES-256, which are instead affected by Grover's algorithm at roughly a quadratic speedup, requiring doubling of key lengths to maintain equivalent security.
This distinction matters for migration planning. The components of your key exchange layer, certificate infrastructure, and TLS handshake that depend on RSA and ECDH are the immediate exposure surface. Your AES-256 encrypted bulk data, once a quantum-safe key has been established, is not the problem. Migration work is concentrated in the key establishment layer, which is a more tractable scope than replacing all cryptographic components simultaneously.
NIST's post-quantum cryptography standardization process finalized FIPS 203 (ML-KEM, based on CRYSTALS-Kyber) and FIPS 204 (ML-DSA, based on CRYSTALS-Dilithium) in 2024. These are public standards, available to any implementer. They specifically target this exposure: lattice-based key encapsulation and digital signatures that resist attacks from both classical and quantum adversaries. The challenge is not algorithmic availability but deployment coordination across complex infrastructure.
What Satellite QKD Addresses That Software PQC Cannot
Post-quantum cryptographic algorithms like ML-KEM are a critical component of the migration, but they share a property with the algorithms they replace: their security is based on computational hardness assumptions. If those assumptions are wrong, or if implementation flaws are discovered, the security guarantee fails.
Quantum key distribution works on different physics. In QKD, keys are distributed as quantum states (typically photon polarization in the BB84 protocol or entangled photon pairs in E91-based systems). Any interception attempt disturbs the quantum state and is detectable. The security guarantee is information-theoretic, not computational: it does not depend on the difficulty of solving a mathematical problem, but on the laws of quantum mechanics. A sufficiently powerful adversary cannot eavesdrop on a QKD key exchange without leaving measurable evidence.
For harvest-now exposure, this matters because QKD-distributed keys cannot be retroactively compromised by a future quantum computer. Traffic encrypted with a QKD-distributed session key is not vulnerable to the harvest-now attack: the key was never transmitted in a form that an adversary could record and later decrypt.
We are not suggesting that QKD replaces software PQC. These are complementary components of a complete migration. Software PQC handles the certificate layer, authentication, and cases where QKD channel infrastructure is not present. QKD provides the highest-assurance key establishment for the highest-exposure data paths where physical channel infrastructure can be deployed.
Starting the Migration Without Waiting for Certainty
Two practical observations from infrastructure security teams running early migration planning exercises.
First, the cryptographic agility layer is the highest-leverage early investment. This means building key management infrastructure that can accept key material from multiple sources (classical ECDH, ML-KEM, QKD) and route it to the right encryption context without requiring changes to downstream application code. Organizations that do this work now spend their later migration effort on connecting new key sources, not on reengineering application cryptographic interfaces.
Second, the inventory problem is underestimated. Before you can migrate, you need a complete map of where RSA and ECDH are in use: not just TLS certificates (which certificate transparency logs help with), but SSH host keys, code signing keys, hardware security module key hierarchies, and application-layer encryption that goes outside the standard certificate infrastructure. This inventory work takes longer than most teams expect and has no shortcut. Starting it now is independent of any decision about which quantum-safe algorithms to deploy.
The harvest-now threat creates an unusual security dynamic: the cost of waiting accrues continuously, but the consequences are deferred. That mismatch is why most organizations have not started. It is also why the ones that have started will be in a fundamentally different position when the quantum computing milestone arrives.
