Four vignettes from a future that is already being assembled, one stolen packet at a time.

These are fiction. The data collection already isn't.

The Strategy Has a Name

It is called Harvest Now, Decrypt Later (HNDL) — and it is not a thought experiment. It is a documented intelligence strategy in which nation-state actors systematically intercept and store encrypted communications today, with the explicit intention of decrypting them once quantum computing matures.

The logic is brutally simple. Encryption has an expiry date — not because the algorithms weaken over time, but because the computational power available to attackers increases. Data that is impenetrable in 2026 may be trivially readable by 2035. And unlike a stolen password, which can be changed, intercepted data cannot be un-intercepted.

If the data is still valuable when the encryption breaks, the harvest was worth the wait.

This Is Not Theoretical

Intelligence agencies have the infrastructure, the budgets, and the strategic motivation. The Snowden revelations in 2013 confirmed that:

• The NSA processed intercepted data at 150 sites worldwide as of 2008
• GCHQ had tapped over 200 fibre-optic cables belonging to seven telecommunications companies by 2012
• Vast amounts of encrypted internet data that had previously been discarded were being stored following a cryptographic breakthrough around 2010

And the interception has only become more targeted since then.

Traffic Rerouting: The Physical Layer

Harvesting does not always require compromising an endpoint. Sometimes, the traffic itself is simply rerouted.

In February 2016, researchers from the US Naval War College and Tel Aviv University documented a campaign by China Telecom. Using BGP hijacking — exploiting the trust-based routing protocol that governs internet traffic between major networks — China Telecom diverted traffic between Canada and Korean government sites through Chinese infrastructure for approximately six months. The data was copied, then forwarded to its original destination with minimal delay. Separate incidents targeted traffic to a major Anglo-American bank in Milan and communications involving Microsoft, Apple, Facebook, and Google.

In April 2020, Russia's state-owned Rostelecom hijacked more than 8,800 internet traffic routes from over 200 networks, including Google, Amazon, Facebook, Akamai, Cloudflare, and more. The incident lasted approximately one hour. Whether accidental or deliberate remains officially disputed — but the data traversed Russian infrastructure regardless of intent.

In November 2024, two submarine cables in the Baltic Sea were disrupted. The EU's top diplomat stated the incidents involving Russia and China were "no mere coincidence." These cables carry approximately 95% of intercontinental data traffic.

This is not hypothetical. These are documented events.

How Close Is Q-Day?

Q-Day is the term for the moment a quantum computer becomes powerful enough to break widely used public-key encryption (RSA, ECC). The timeline has been accelerating:

The Global Risk Institute places a significant probability of RSA-2048 being broken by the mid-2030s. IBM's roadmap targets fault-tolerant quantum computing by approximately 2030.

To put this in perspective: the number of qubits needed to break RSA has dropped from 20 million (2019) to under 100,000 (2026). That is a 200x reduction in seven years.

AES-256 remains quantum-resistant in practice — Grover's algorithm reduces its effective strength to 128 bits, which is still computationally infeasible. But RSA and ECC — the algorithms protecting your TLS connections, your VPN tunnels, your email encryption, your digital signatures — are the primary targets.

The Response Has Already Started

In August 2024, NIST published the first three post-quantum cryptography (PQC) standards:

• FIPS 203 — ML-KEM (formerly CRYSTALS-Kyber): Key encapsulation for secure key exchange
• FIPS 204 — ML-DSA (formerly CRYSTALS-Dilithium): Digital signatures for authentication
• FIPS 205 — SLH-DSA (formerly SPHINCS+): Hash-based digital signatures as a backup — based on entirely different mathematics, so if lattice-based algorithms are broken, this remains secure

The NSA's CNSA 2.0 now mandates quantum-safe algorithms for national security systems, with the first compliance deadline — January 2027 for new systems — less than a year away.

Who Is Already Implementing PQC?

The migration is not a future event. It is happening now:

• Signal deployed post-quantum key exchange (PQXDH) in September 2023, and introduced the Triple Ratchet protocol (SPQR) for post-quantum ratcheting in October 2025. PQC is now required for all new Signal conversations.
• Apple shipped PQ3 for iMessage in March 2024 (iOS 17.4), with keys rotating every 50 messages or 7 days at minimum. Within four days of the iOS release, PQC traffic from iOS devices jumped from 2% to 11%.
• Chrome 131 (November 2024) ships hybrid post-quantum TLS (X25519MLKEM768) enabled by default.
• Firefox 135 (February 2025) enables ML-KEM by default.
• Cloudflare reports that post-quantum encrypted traffic nearly doubled through 2025, from 29% at the start of the year to 52% by December — crossing the majority threshold.

The browser you are using to read this article may already be negotiating post-quantum key exchange.

What Should Your Organisation Do Now?

You do not need a quantum computer to be affected by the quantum threat. You need only to have data that is worth something in ten years and an attacker with patience.

1. Build a Cryptographic Inventory

Map every system that uses encryption: TLS certificates, VPN configurations, SSH keys, database encryption, API authentication, file encryption, email encryption. Many organisations have no visibility into their full cryptographic footprint — especially "shadow" certificates and legacy configurations.

2. Classify Data by Lifespan

Identify data that must remain confidential for 10+ years: intellectual property, health records, legal documents, financial records, client personal data, strategic communications. This data is most vulnerable to HNDL. If your data's confidentiality lifespan exceeds the estimated timeline to Q-Day, you are already at risk.

3. Assess Your Vendor Ecosystem

Make quantum readiness a line item in security reviews with cloud providers, software vendors, and compliance partners. Ask explicitly: what is your PQC migration roadmap?

4. Update Browsers and TLS Stacks

Ensure your organisation deploys Chrome 131+, Firefox 135+, and Edge with current updates. These already negotiate hybrid post-quantum TLS by default. Verify that your servers and load balancers support the new key exchange mechanisms.

5. Adopt Hybrid Encryption Where Available

The recommended approach is "hybrid" — combining classical algorithms (X25519) with quantum-resistant ones (ML-KEM-768). This maintains backward compatibility while adding quantum protection. If the post-quantum algorithm proves flawed, the classical algorithm still protects you.

6. Monitor Compliance Timelines

NSA CNSA 2.0 mandates PQC for new national security systems by January 2027. NIST's full migration timeline extends to 2035. The EU is expected to follow with sector-specific requirements. Organisations in regulated industries — financial services, healthcare, critical infrastructure — should expect compliance pressure within the next 2-3 years.

7. Run a Quantum Readiness Assessment

Treat this like Y2K — but with a longer runway and higher stakes. Conduct a structured assessment of your cryptographic exposure, migration complexity, vendor dependencies, and timeline requirements.

The Uncomfortable Truth

Every encrypted email you sent last year, every VPN tunnel you established, every TLS-protected file transfer — if the traffic was intercepted, the encryption is a countdown timer, not a lock.

The question is not whether quantum computers will break current encryption. The NIST standards, the NSA mandates, the Signal and Apple deployments, the 52% of Cloudflare traffic already using PQC — all of these confirm that the industry has accepted this as inevitable.

The question is whether your organisation's data will still be worth protecting when it happens.

If the answer is yes, the time to act is not when quantum computers arrive. It is now — while the encryption you deploy today still has value tomorrow.

Agent Müller, Nikos, the shipping company, and Maria are fictional. The BGP hijacking campaigns, the intelligence programmes, the NIST standards, the qubit counts, and the migration timelines are not. The harvest is real. The clock is running.

Addendum — 30 July 2026: the second clock

The threat model above assumes one clock: the adversary harvests today and waits for a quantum computer. A second clock has since become visible. In July 2026, Anthropic's Frontier Red Team published results in which a frontier model discovered mathematical weaknesses in cryptographic algorithms — not implementation bugs. Two attacks were developed, each in roughly a week and at roughly $100,000 in API cost. One reduced the attack cost on HAWK-256, a third-round candidate in NIST's call for additional post-quantum signatures, from 2⁶⁴ to 2³⁸. Another improved the best known attack on 7-round AES-128 by 200–800×. Neither result touches anything you operate: 7-round AES is not AES, whose full cipher has ten rounds and remains unbroken; HAWK is a candidate, not a deployed standard; and the AES result still requires 2¹⁰⁵ chosen plaintexts, which is not achievable. The significance is not that a cipher fell. It is that the cost of finding new cryptanalysis is now quotable in dollars and days.

That changes two things in the plan above. First, Harvest Now, Decrypt Later was priced in hardware — qubits, error rates, dates in the 2030s. Cryptanalytic progress scales with budget rather than physics, and for an actor already funding interception, $100,000 is not a constraint; the interval between harvest and decryption should be treated as shorter and less predictable than a purely quantum timeline implies. Second, has your vendor adopted post-quantum cryptography is no longer a sufficient question. Ask which algorithm, and whether that algorithm is under active analysis — HAWK is the concrete example. This is also the strongest available argument for crypto-agility: not as a convenience for one migration, but as the control that matters, because the algorithm you migrate to may itself be revised. And it is worth stating plainly what these results are not: no production system was broken, and the HAWK finding is the NIST process performing its intended function — surfacing weaknesses before deployment rather than after. Prefer standards-track algorithms with published cryptanalysis over anything bespoke.