HNDL guide · updated 7 November 2026

Harvest now, decrypt later: what is exposed today

Harvest now, decrypt later means someone records your encrypted traffic today and keeps it until a quantum computer can break the key exchange that protected it. Only data that still matters on that day is at risk, so the question for you is which of your connections and files are exposed, and for how long. Below is a calculator for that, and what we found when we tested the HTTP clients on one Mac this week.

Read the guide Run Quantum Core

Recorded todayt = live

X + Y

harvest nowdecrypt laterZ yearsML-KEM

What the attack is

Nobody needs a quantum computer to start this attack. They need a copy of your encrypted traffic and the patience to store it. When a large enough quantum computer exists, Shor's algorithm breaks RSA and elliptic-curve key exchange, the stored sessions can be opened, and anything in them that is still secret is lost. CISA, NSA and NIST put it plainly in their joint quantum-readiness factsheet of August 2023: threat actors could be targeting data today that would still need protection in the future, using a "catch now, break later or harvest now, decrypt later" operation.

So the risk depends on how long your data has to stay secret, not on when the machine arrives. A session password that expires tonight is safe. Medical records, merger documents, source code, private keys sent over a link and anything under a long confidentiality agreement are not.

What it exposes, and what it doesn't

Exposed if recorded today	Not exposed to this attack
TLS sessions that used X25519, P-256 or RSA key exchange	Signatures, because a forged signature can't change a handshake that is already over
SSH sessions on classical key exchange	Data encrypted only with a symmetric key such as AES-256 that never crossed a classical key exchange
VPN tunnels set up with classical Diffie-Hellman	Sessions on a hybrid such as X25519MLKEM768 or mlkem768x25519-sha256
Email and files encrypted to an RSA or elliptic-curve public key	Passwords and tokens that expire before a quantum computer exists

NIST makes the same split in IR 8547: key establishment is exposed to harvest now, decrypt later, and signatures aren't, which is why its migration deadlines put key exchange first. Signatures still matter, of course, but for a different reason. They take longer to replace, and once a quantum computer exists, someone could forge new ones.

Work out your own exposure

Michele Mosca's rule, which NIST cites, uses three numbers. X is how many years your data must stay secret, Y is how many years your migration will take, and Z is how many years until a quantum computer can break today's key exchange. If X + Y is more than Z, some of what you send before the migration ends will still be secret on the day it can be read. Nobody knows Z, so try a few values. In 2015 Mosca put the chance of breaking RSA-2048 by 2031 at one in two.

X, years the data must stay secret Y, years your migration will take Z, years until a quantum computer can break it

With these numbers, 3 years of traffic is exposed: what you send from 2028 until your migration ends in 2031.

Let's use the default numbers to see how this works. Data that has to stay secret for 10 years, sent in 2028, is still secret until 2038, and a machine arriving 12 years from now gets there in 2038 as well. So everything you send between 2028 and the end of your migration in 2031 is at risk. And if Z is less than X, then traffic you're sending this week is already in that window.

What we found on one Mac, 7 November 2026

Browsers moved to hybrid key exchange a while ago, as the X25519MLKEM768 guide shows, so I expected scripts and command-line tools to lag behind. To see by how much, we sent the same request from each HTTP client on our test Mac (macOS 26.3.1) to functorfund.com/cdn-cgi/trace. Cloudflare's trace page reports the key exchange each connection actually used, in a line starting kex=.

Client	TLS library	Key exchange used
Swift URLSession (the system networking stack)	Apple	X25519MLKEM768
`/usr/bin/curl` 8.7.1, the one macOS ships	LibreSSL 3.3.6	X25519
Homebrew curl 8.17.0	OpenSSL 3.6.3	X25519MLKEM768
`/usr/bin/python3` 3.9.6, from the Command Line Tools	LibreSSL 2.8.3	X25519, and only TLS 1.2
Homebrew Python 3.14.2	OpenSSL 3.6.3	X25519MLKEM768
Node.js 26.7.0 `fetch`	OpenSSL 3.6.3	X25519MLKEM768
`/usr/bin/ssh`, from our SSH test the day before	OpenSSH 10.2p1	ecdh-sha2-nistp256

Apple says iOS 26 and macOS Tahoe 26 offer X25519MLKEM768 in TLS 1.3, and that matches what URLSession did. But the curl and Python that come with the Mac are built on old LibreSSL, so they stay classical, and the old Python didn't even reach TLS 1.3. Anything a cron job or deploy script sends through them can be harvested today. With the same machine and the same server, the result depended only on which binary ran first in the PATH.

You can check your own tools the same way against any site behind Cloudflare:

curl -s https://functorfund.com/cdn-cgi/trace | grep kex
python3 -c "import urllib.request as u; print(u.urlopen('https://functorfund.com/cdn-cgi/trace').read().decode())" | grep kex

What to do about it

First, find the connections that carry long-lived secrets. That includes service-to-service calls, backups, replication between data centres, VPNs and SSH, as well as the website. Second, move those to a hybrid key exchange: OpenSSL 3.5 or later for TLS, OpenSSH 9.9 or later for SSH, and current runtimes in place of the system copies. Third, keep a record, because the list changes every time someone adds a dependency. A CBOM is the usual format, and Quantum Core scans a repository on your machine and lists every classical key exchange it finds, with the file and line.

Is harvest now, decrypt later happening already?

No public case shows that a particular agency has stored a particular set of traffic for later decryption. The CISA, NSA and NIST factsheet treats it as a current threat, though, and recording traffic costs very little, so I'd plan as if it is.

Does AES-256 protect me?

AES-256 itself is not the weak point, and NSA's CNSA 2.0 keeps it. The weak point is the RSA or elliptic-curve exchange that agreed on the AES key. If that exchange can be broken later, the AES key can be recovered too.

Is a hybrid enough, or do I need pure post-quantum?

A hybrid is enough against this attack. The session key depends on both the classical secret and the ML-KEM secret, so a recorded session stays closed unless both are broken.

Do I need to re-encrypt data I already sent?

You can't. Whatever was recorded is out of your hands. You can only rotate any secrets that crossed those connections and are still valid, such as API keys and passwords.