Harvest Now, Decrypt Later: Why Post-Quantum Crypto Is a 2026 Problem

You’re a compliance lead at a European bank. Today you encrypt a client’s tax filing under TLS 1.3 with RSA-2048 and send it to a US-hosted analytics service. Every regulation you have to satisfy says the bytes left safely. They arrived safely. They sit in someone else’s storage safely.

Now imagine a copy of those bytes — recorded somewhere along the route by a foreign intelligence service, a hostile insider at the cloud provider, or one of the legal capture pipelines we wrote about in The CLOUD Act and Your AI Research. That copy sits on a tape. The tape costs almost nothing to keep around. Twelve years from now a sufficiently large quantum computer reads the tape, factors RSA-2048 in an afternoon, and knows everything you sent today.

The crypto you’re using is fine for now. The data has a longer lifetime than the crypto. That gap is the whole problem.

Why this isn’t a 10-year problem

The threat has a name: harvest now, decrypt later. An adversary patient enough to record encrypted traffic today and store it doesn’t need to break your encryption now — they need to break it eventually.

The math that secures the public internet rests on two problems: factoring large numbers, and computing discrete logarithms. RSA, ECC, Diffie-Hellman, your TLS handshake, your code-signing certificates, every encrypted backup that wraps a data key — all of it. Peter Shor showed in 1994 that a sufficiently large quantum computer solves both in polynomial time. The catch is you need a cryptographically relevant quantum computer — a CRQC, in the jargon — large enough and stable enough to actually run Shor’s algorithm on a 2048-bit modulus. Nobody has built one. Published estimates put it somewhere in the 2030s, with wide error bars.

That’s the wrong number to plan around. The number that matters is the useful lifetime of the data you’re encrypting today. A medical record stays confidential for the patient’s lifetime. A tax filing sits in a decade-plus retention window. Trade secrets, client lists, M&A diligence, source code for a long-running product — none of these get less valuable on the calendar your encryption depends on.

The NSA noticed. CNSA 2.0 tells national-security vendors to use post-quantum crypto exclusively by 2033 at the latest, category by category, with the overall transition expected to be complete by 2035 — not because a CRQC is arriving next year, but because the procurement and deployment cycle for crypto is a decade long. Anything sealed before the migration completes is still exposed.

Your data has its own clock. We made the same point a different way in Data Sovereignty, Not Residency: where bytes physically sit matters less than what forces can eventually compel them. Add quantum to that list of forces, and the answer is the same. Bytes you let out of your control today are still under threat from things you can’t predict on a clock you don’t set.

What’s actually standardized today

NIST ran a six-year competition that started in 2016 with 82 submissions and ended in 2022 with four winners. NIST published the first PQC standards in August 2024 under their final FIPS names. You’ll see both naming conventions in the wild — the old project names and the new FIPS names.

Here’s what each one does, in working terms:

Kyber, now ML-KEM (FIPS 203). A key encapsulation mechanism — the new way to do the secret-key handshake at the start of a TLS session. Lattice-based, specifically based on the Module Learning With Errors problem. Small enough and fast enough to be a drop-in for current ECDH in most protocols. This is the one your TLS stack will pick up first.

Dilithium, now ML-DSA (FIPS 204). A digital signature algorithm. Same lattice family as Kyber, also based on Module-LWE. The general-purpose signature you’ll use to sign software, certificates, and JWTs once your stack supports it. Bigger keys than Ed25519 — about 1.3 KB public key versus 32 bytes — but still practical.

SPHINCS+, now SLH-DSA (FIPS 205). A signature scheme too, but built on a completely different foundation: the security of cryptographic hash functions like SHA-256. No lattices, no number theory — just hash-tree gymnastics. The price is size: signatures run 8 to 50 KB depending on parameter set. You don’t use this for everything. You use it for things where you absolutely cannot afford a lattice break — long-lived root certificates, signed firmware that ships once and lives forever.

FrodoKEM. A more conservative lattice KEM than Kyber, based on plain LWE without the algebraic structure that makes Module-LWE efficient. Larger keys (about 9 KB public key), slower, but with fewer structural assumptions to attack. NIST kept it on the table as a backup; ISO standardized it separately. Worth knowing about for stacks that prioritize security margin over wire efficiency.

The headline tradeoffs:

Algorithm	Math family	Use	Public key	Notes
ML-KEM (Kyber)	Lattice — Module-LWE	Key exchange	800–1,568 B	Primary KEM, fast
ML-DSA (Dilithium)	Lattice — Module-LWE	Signatures	1,312–2,592 B	Primary signature
SLH-DSA (SPHINCS+)	Hash-based	Signatures	32–64 B	Tiny key, big signature, high confidence
FrodoKEM	Lattice — plain LWE	Key exchange	~9 KB	Conservative backup

Three of the four primary picks are lattice-based. That’s worth pausing on.

Why one math family isn’t enough

Three out of four standardized algorithms rest on essentially the same hardness assumption: that high-dimensional lattice problems with a particular algebraic structure remain hard. If a future cryptanalytic break hits Module-LWE, three of your four standardized tools fall over together.

This isn’t paranoia. It happened, in public, in 2022.

SIKE — Supersingular Isogeny Key Encapsulation — was a Round 4 candidate in NIST’s process. Isogeny-based, an entirely different math family from the lattice picks. It had survived ten years of cryptanalysis. NIST kept it in the running specifically because it was not a lattice scheme and would give the world a non-lattice fallback. In July 2022, Wouter Castryck and Thomas Decru published an attack that broke SIKE’s lowest NIST-level parameter set in about an hour on a single CPU core — and even the hardest published parameter set, SIKEp751, fell within about a day. The break used algebraic geometry that hadn’t been on anyone’s radar.

That’s the model for how mathematical assumptions die. Not with a slow grinding of better attacks. With a clever new technique that nobody saw coming, dropping by an order of magnitude what cryptographers thought was the best known attack.

NIST is keeping non-lattice candidates in the pipeline for exactly this reason. Code-based KEMs — Classic McEliece (which has stood for over forty years), HQC, selected in March 2025, and BIKE (still under analysis) — give a fallback that doesn’t share lattice assumptions. The point isn’t that lattices are weak. It’s that betting an entire crypto stack on a single mathematical family is the kind of concentration risk a sovereign wealth fund wouldn’t accept on its bond portfolio.

For a procurement question, this turns into: does your stack let you run more than one signature scheme in parallel? Does it support algorithm negotiation, or is one algorithm baked in?

Hybrid mode is the actual migration path

The one thing you should not do is rip out RSA tomorrow and replace it with Kyber. Here’s why.

The lattice picks are well-studied but they haven’t had four decades of attack the way RSA has. If something nasty turns out to be true about Module-LWE in 2028, you don’t want the only thing standing between your traffic and the world to be the algorithm that just fell.

The standard answer is hybrid. You combine a classical algorithm with a post-quantum one, and the session is secure as long as either is unbroken. In TLS this looks like X25519MLKEM768 — an X25519 ECDH handshake combined with ML-KEM. The session key is derived from both. Break Kyber, X25519 still holds. Break X25519, Kyber still holds. Break both, and you have bigger problems than this article.

This isn’t hypothetical. Cloudflare defaulted hybrid Kyber for connections to its edge in 2023 and saw it become roughly a third of their TLS traffic within a year. Apple’s iMessage PQ3 shipped hybrid Kyber in iOS 17.4. AWS KMS now offers hybrid post-quantum TLS endpoints. Signal added hybrid PQ to its ratchet. Chrome and Firefox negotiate hybrid Kyber by default with any server that supports it.

For a buyer, hybrid mode is the practical middle. It’s the migration step you take now — before you’re sure the lattice picks will hold for thirty years, while the rest of the stack catches up. It costs a few extra kilobytes per handshake. It buys protection against the harvest-now adversary today, with a graceful fallback if the math turns out wrong.

The vendor question becomes: do you support hybrid Kyber, on which endpoints, and what’s the timeline to extend it to the rest? Phrased that way, it’s a procurement question with a clear answer, not a research project.

What to do now

1. Inventory your data by lifetime, not just by sensitivity. What still has to be confidential in 2035? Those are the bytes a harvest-now adversary cares about today.

2. Ask vendors three specific questions. What algorithm. What security level (NIST levels 1–5). What hybrid mode, on which endpoints, by when. “We’re post-quantum ready” without those three answers is marketing — push back like you would on any other procurement claim. Our European Sovereign Cloud Teardown covers the same vendor-question discipline for a different layer of the stack.

3. Enable hybrid Kyber on TLS endpoints you control. OpenSSL 3.5, BoringSSL, Cloudflare, and AWS all support it now. The deployment risk is low — clients that don’t support PQ negotiate the classical algorithm, same as before.

4. Avoid stacks that hard-code one algorithm. Crypto agility — the ability to swap algorithms without rewriting everything that depends on them — matters more than picking the perfect algorithm today. SIKE is the lesson.

5. Plan for diversity in long-lived signatures. Code-signing for firmware that ships once and lives a decade. Root certificates. Long-term archive seals. These are the places a hash-based fallback alongside your lattice signature is worth the extra bytes.

6. Track NIST Round 4. HQC is now selected for standardization as a code-based KEM. Additional signature schemes are landing through 2026 — beyond the lattice family — and onramp planning gets easier the earlier you start watching them.

7. Don’t reach for stateful hash signatures (XMSS, LMS) for general use. They’re real and standardized, but the failure mode is brutal: reuse a key once, and you lose the signature scheme. Stick to NIST’s stateless picks unless you have a specialized need and a key-management team that won’t blink.

A worked example

The argument above is generic, deliberately. Vendor specifics have to be checked against each vendor’s actual posture. But it’s easier to ask the procurement-grade questions when you’ve seen one set of answers written out, so here is ours.

LumaVista’s research platform runs end-to-end-encrypted across multiple Go backends with six distinct cryptographic layers in the data path. From 18 May 2026, three of those layers — the TLS handshake, the per-device key envelope, and the at-rest snapshot envelope — operate in hybrid X25519 + ML-KEM-768 mode. The remaining three are symmetric (XChaCha20-Poly1305 at 256-bit keys), where Grover’s algorithm leaves around 128 bits of effective security, the de facto post-quantum symmetric floor.

What the platform does not claim, and says so explicitly: the Web PKI certificate chain remains classical until public CAs ship PQ certs (CA/B Forum roadmap, 2027–2028); backup material captured before the rotation cutover contains classical-only wrapping and is purged from LumaVista-controlled storage on a 90-day operational commitment; nothing in the cryptography defends against malware on the user’s device. Each of those carve-outs is exactly the kind of detail you should expect to see, and push for, on a vendor procurement form.

The full architecture and threat model — seven adversary classes, layer-by-layer coverage matrix, byte-level envelope format, the operational retention destruction commitment — is documented in our Multi-Backend Architecture with Layered Post-Quantum Encryption whitepaper. It’s the kind of document a CISO can quote back at us, which is the point.

Quantum computers don’t have to exist yet to be a procurement problem. The data already does.