Quick Answer
Harvest now, decrypt later (HNDL) is when an attacker records your encrypted traffic today and stores it to decrypt years from now, once a quantum computer can break RSA and elliptic-curve cryptography. If anything you send over the wire needs to stay secret past roughly 2030 — health records, financial data, government secrets, long-lived credentials — it is already exposed, because the ciphertext can be captured now.
The single most effective defense you can deploy today is TLS 1.3 with hybrid post-quantum key exchange (X25519 + ML-KEM-768). It is standards-based, backwards compatible, and ships on by default in OpenSSL 3.5. Turning it on protects the confidentiality of today's traffic against tomorrow's quantum computer.
Watch: Harvest Now, Decrypt Later Explained
What "harvest now, decrypt later" actually means
Most attacks need to succeed in real time. HNDL does not. The adversary's bet is patience: capture encrypted traffic now, keep it, and wait for the cryptography protecting it to fall.
The key-exchange step of a TLS handshake — the part that establishes the shared session key — currently relies on elliptic-curve Diffie-Hellman (X25519) or RSA. Both are breakable by a sufficiently large quantum computer running Shor's algorithm. When that machine arrives, every session key an attacker recorded becomes recoverable, and the traffic it protected can be decrypted in bulk.
The uncomfortable part: the attack has already started. You cannot un-send the packets that left your network last year. So the relevant question is not "when will quantum computers break TLS" — it is "how long does my data need to stay confidential, and will that window still be open when the machine exists?"
This is why agencies and CAs are moving now, years ahead of any working cryptographically-relevant quantum computer.
Are you actually at risk? A 30-second test
Run one heuristic — the confidentiality lifetime of your data. Ask what you transmit that must still be secret in 2030 and beyond.
If the answer is "nothing," HNDL is a low priority for you. If the answer is anything on this list, you are a target today:
Health and genetic records (confidentiality obligations measured in decades)
Financial account data, trading positions, and long-term contracts
Government, defense, and intelligence material
Long-lived secrets such as private keys, root credentials, and API tokens with multi-year validity
Personal data covered by GDPR/CCPA that you must protect for the life of the data subject
These are the "long-lived sensitive data" sectors that harvesting campaigns prioritize, because the payoff survives the wait. If you operate in one, the recording is plausibly already happening.
The timeline that matters
You do not need a quantum computer to exist today for HNDL to be a problem today — but the migration deadlines are what turn it from theory into a project plan.
August 2024
NIST finalized the first post-quantum standards — ML-KEM (FIPS 203, key encapsulation), ML-DSA (FIPS 204, signatures), and SLH-DSA (FIPS 205, hash-based signatures).
2025 – 2033
NSA's CNSA 2.0 suite phases in, with software and firmware signing leading and web, cloud, networking, and operating systems expected to prefer CNSA 2.0 through the late 2020s and reach an exclusive end-state by 2033.
By 2029
Major platform vendors including Google and Microsoft target their PQC transitions.
2029 – 2035
The broad migration window that Google, Cloudflare, NIST, and the EU all point to for the wider ecosystem.
The gap between "standards exist" (done) and "everything is migrated" (years away) is exactly the window HNDL exploits. PKI migrations are slow; the recording is not.
The most effective thing you can do today: hybrid key exchange
Protecting confidentiality against HNDL does not require new certificates or a forklift upgrade. It requires fixing the key exchange, and that fix is available now.
The mechanism is a hybrid group that runs a classical and a post-quantum key exchange side by side and combines both into the session key. The current standard pairing is X25519MLKEM768: classical X25519 plus ML-KEM-768. An attacker has to break both to recover the key — so it is no weaker than what you run today, and it defeats a future quantum attacker who can only break the classical half.
As of OpenSSL 3.5 (April 2025), X25519MLKEM768 is offered by default as a TLS 1.3 keyshare — no patching, no third-party providers. Go, recent Apple operating systems, and other major stacks have enabled it by default as well. Cloudflare reports that by mid-September 2025 roughly 43% of human-generated connections to its edge were already protected by hybrid post-quantum key agreement.
Check what you have
Confirm your OpenSSL is 3.5 or newer — that is the linkage that gives you the group:
openssl version
Then test whether a server will actually negotiate the hybrid group:
openssl s_client -connect example.com:443 -groups X25519MLKEM768 </dev/null 2>/dev/null | grep -i "Negotiated"
A protected endpoint returns Negotiated TLS1.3 group: X25519MLKEM768. If it falls back to plain X25519, the server does not yet support hybrid.
Turn it on
On nginx built against OpenSSL 3.5, offer the hybrid group first and keep classical X25519 as a fallback for older clients:
ssl_protocols TLSv1.3; ssl_ecdh_curve X25519MLKEM768:X25519;
The fallback matters: hybrid is backwards compatible because a client that does not understand the group simply negotiates X25519 as it always did. You lose nothing for old clients and gain HNDL protection for modern ones.
Confirm the exact directive and group string for your specific build — some distributions ship OpenSSL 3.5 under a vendored name, and HAProxy and Apache expose the setting differently.
One real-world caution: Google shipped hybrid PQ key exchange in Chrome 124, then temporarily rolled it back after enterprise middleboxes that hard-coded assumptions about handshake size broke on the larger ClientHello. If your users sit behind legacy TLS-inspecting proxies, test before you mandate. The fix for the ecosystem is the same as the fix for your own infrastructure: stop assuming handshakes are small.
Why the certificate half is harder
Hybrid key exchange solves confidentiality. It does not solve authentication — proving the server is who it claims to be, which is the certificate's job. And this is where post-quantum gets genuinely difficult.
Post-quantum signature algorithms produce much larger keys and signatures than RSA or ECDSA. That is a real problem for the Web PKI, because a TLS handshake ships the entire certificate chain on every new connection. Naively swapping X.509 certificates to post-quantum signatures would bloat handshakes enough to hurt performance, bandwidth, and connection stability at scale.
Merkle Tree Certificates: the size fix
The emerging answer is Merkle Tree Certificates (MTCs). Instead of issuing certificates one at a time and signing each individually, an MTC certificate authority issues them in batches, with a single post-quantum signature covering thousands of certificates at once. Clients get a compact inclusion proof rather than a full heavyweight signature per certificate, which keeps handshakes small even with post-quantum signatures underneath.
This is not hypothetical. On June 3, 2026, Let's Encrypt committed publicly to MTCs as its path to post-quantum authentication, with a staging environment able to issue Merkle Tree Certificates in the second half of 2026 and a production-ready target of 2027. Chrome has signaled MTCs as its preferred approach, and Cloudflare and Google have been testing the mechanism on live traffic.
Practical takeaway: MTCs lean on infrastructure you may already be moving toward for the short-lifetime deadlines — ACME for automated issuance, plus transparency logging and revocation tooling. The automation you build for short-lived certificates is the same automation that will carry them. Watch the staging rollout — you do not deploy MTCs today, but the groundwork is being laid now.
What to do now: a practitioner checklist
Enable hybrid PQ key exchange on your TLS 1.3 endpoints
Use X25519MLKEM768 with classical X25519 as fallback. The highest-impact, lowest-risk step against HNDL — doable this quarter.
Inventory your long-lived-secret data flows
Map what you transmit that must stay confidential past 2030, and prioritize those paths for hybrid key exchange first.
Build crypto-agility now
Short-lived certificates and automated renewal via ACME let you swap algorithms in days, not quarters. Use ARI (ACME Renewal Information, RFC 9773) so your client responds to early-renewal signals automatically. If you still renew by hand, automate first.
Track the milestones that apply to you
CNSA 2.0 timelines if you touch government systems, the CA/Browser Forum lifetime reductions everyone faces, and the Let's Encrypt MTC staging rollout in the second half of 2026. None of this is dramatic — HNDL is a real threat with an undramatic, available mitigation.
FAQ
QIs my data already stolen?
AIf you handle long-lived sensitive data and have not been using post-quantum key exchange, assume some traffic could have been recorded. You cannot recall it — but enabling hybrid key exchange now stops the exposure from growing.
QDo I need post-quantum certificates today?
ANo. Confidentiality (key exchange) is the urgent, deployable half and is available now. Authentication (certificates) is still stabilizing; Merkle Tree Certificates are in staging, not production. Fixing key exchange today buys you the time to migrate certificates when the standards land.
QIs hybrid key exchange safe and standards-based?
AYes. It combines a NIST-standardized algorithm (ML-KEM, FIPS 203) with classical X25519, so it is strictly no weaker than what you run today. It is on by default in OpenSSL 3.5 and widely deployed across major TLS stacks.
QWill it break old clients?
ANo. Clients that do not understand the hybrid group fall back to classical X25519 automatically. The main exception is legacy middleboxes that assume small handshakes — test if you run TLS-inspecting proxies.
Related Guides
Post-Quantum Cryptography
ML-KEM, ML-DSA, SLH-DSA — the NIST standards and what your PKI team needs to do before 2035.
ACME Protocol
How Let’s Encrypt and ACME automate certificate issuance. The foundation for crypto-agile renewal.
ARI Readiness Guide (RFC 9773)
ACME Renewal Information lets servers signal early renewal. Essential for responding fast when algorithms change.
The 47-Day Certificate Timeline
Short-lived certificates and the automation they require — the same infrastructure MTC issuance will use.
Go deeper on post-quantum cryptography
Our full guide covers ML-KEM, ML-DSA, and SLH-DSA in detail — algorithm choices, migration timelines, and practical steps for your PKI team.