Q-Day Has Not Happened. The Incident Already Has: Harvest Now, Decrypt Later

noreply@paragmali.com (Parag Mali) — Sat, 18 Jul 2026 00:00:00 GMT

No quantum computer can break RSA or ECC in 2026 -- and yet a long-lived secret you encrypt today may already be lost. The reason is **harvest now, decrypt later**: an adversary who records your encrypted traffic now has done the decisive, irreversible part, and a future quantum computer only finishes the job [@apple-pq3]. That makes the casualty a *deployment* choice -- protecting must-outlive-Q-Day data with a deprecated-but-still-live algorithm -- not a math break that has happened, and the fix (hybrid X25519 + ML-KEM key establishment) is executable today [@ietf-mlkem]. You cannot un-capture ciphertext, so the only defense is to change the deployment before the recording is made.

1. Q-Day Has Not Happened. The Incident Already Has

In 2026, no quantum computer on Earth can factor a 2048-bit RSA key. Not one. The cryptographers who design these systems will tell you so plainly, and they are right: RSA-2048 is unbroken, and the machine that would break it does not exist -- the most recent published analysis still describes hardware that has not been built [@gidney-2025]. And yet a secret you encrypt this morning, if it must stay secret for a decade, may already be lost.

That is not a contradiction. It is the whole story.

The adversary's decisive act is not decryption. It is capture. Someone who records your encrypted traffic today -- the key-exchange handshake and the ciphertext that follows -- has already done the irreversible part. The decryption can wait for a machine that arrives in five years, or fifteen, or thirty. This is the attack the security community calls harvest now, decrypt later, and the United States government now states its rationale in an executive order, warning of "adversaries collecting United States information now, and decrypting it later once large-scale quantum computers are operational" [@eo-14412]. Apple's engineers put the mechanics even more plainly.

Attackers "can collect large amounts of today's encrypted data and file it all away for future reference ... retain it until they acquire a quantum computer that can decrypt it in the future, an attack scenario known as Harvest Now, Decrypt Later." -- Apple Security Engineering and Architecture [@apple-pq3] An attack in which an adversary records encrypted traffic today -- the key-establishment handshake plus the ciphertext -- and stores it indefinitely, planning to decrypt it once a capable quantum computer exists. The decisive act is the capture, not the decryption, so the loss is decided at the moment of recording [@apple-pq3]. A quantum computer large enough and error-corrected enough to run Shor's algorithm against deployed public-key sizes such as RSA-2048 or Curve25519. No CRQC exists in 2026; the published figures for the qubits one would require are estimates on hardware that has not been built [@gidney-2025]. flowchart LR A[Today: adversary records handshake and ciphertext] --> B[Indefinite storage] B --> C[Q-Day: a CRQC runs Shor's algorithm] C --> D[Ciphertext decrypted] A -. the decisive, irreversible act .-> D

So the clock that matters is not "when does Q-Day arrive?" but "how long must this secret survive, and was it captured before I protected it?" The cryptographer Michele Mosca turned that question into an inequality years ago, and we will spend a whole section on it, because it is the spine of everything here: if the lifetime of your secret plus the time you need to migrate exceeds the time until a capable quantum computer exists, you are already exposed [@mosca-2018].

This is why this article belongs in a series about how cryptography breaks in real life -- and why it is the strangest entry in it. Every other casualty here is a break you can point to after the fact: a reused nonce, a padding oracle, a downgrade. This one is different in time. The mathematical weapon does not exist yet, and still the loss is being booked. That is the reconciliation this whole piece defends: the break is not a mathematical event that has happened. It is a deployment choice -- protecting data that must outlive Q-Day with a quantum-vulnerable, deprecated-but-still-live algorithm while someone records the ciphertext. The math finishes the job later. The deployment decides the outcome now.

Key idea: The loss is booked at capture time. Because an adversary who records your ciphertext today has already done the irreversible part, the casualty is decided by the deployment you shipped -- a quantum-vulnerable algorithm protecting data that must outlive Q-Day -- not by a mathematical break that has occurred.

One boundary before we begin. This is a story about confidentiality: recorded ciphertext, decrypted after capture. It is not the story of quantum forgery of digital signatures, which is a different problem on a different clock, and which we will keep scrupulously separate throughout. The mechanism of the eventual break -- how one machine running Shor's algorithm flattens RSA, Diffie-Hellman, and ECC at once -- is the subject of this article's structural sibling, "How Q-Day Breaks Everything: Shor's Algorithm and the Simultaneous Fall of RSA, Diffie-Hellman, and ECC." Here we need only its conclusion.

If the loss is booked the moment the ciphertext is captured, then the only question that matters is what you were doing at capture time. To answer it, we have to see that this idea is older than quantum computing.

2. "Store Now, Decrypt Later" Is Older Than Quantum

Long before anyone wired a lattice into TLS, intelligence agencies were already doing the first half of harvest now, decrypt later -- the harvesting. The behavior the quantum threat depends on is not speculative; it is documented, and it predates the quantum motive by years.

In March 2012, James Bamford reported in Wired that the National Security Agency was building a data center in Bluffdale, Utah -- roughly one million square feet built to intercept and store communications at a scale discussed in exabytes and beyond [@bamford]. The next year, the documents Edward Snowden supplied to journalists revealed Bullrun, a program to defeat and circumvent internet encryption alongside bulk interception and indefinite retention [@bullrun]. The through-line of both is the same: collect broadly, store indefinitely, and revisit the ciphertext later as your ability to read it improves.

The length of time a piece of data must remain secret to avoid harm. A session cookie has a confidentiality lifetime of minutes; a diplomatic cable, an intelligence source's identity, or a person's genome may need to stay secret for decades. It is the single most load-bearing quantity in the harvest-now-decrypt-later argument, because it decides whether a future decryption still matters.

Quantum computing did not invent this behavior. What it changed is the horizon. It introduced a specific future event -- a machine that can run Shor's algorithm -- that would retroactively unlock everything already collected under a quantum-vulnerable algorithm.

In 2015, and again in a 2018 journal version, Michele Mosca gave that horizon a decision rule. If $X$ is how long your data must stay secret, $Y$ how long your migration takes, and $Z$ the time until a capable quantum computer exists, then whenever $X + Y > Z$ you are already too late for that data [@mosca-2015]. He stated the corollary this article turns on in the same breath: "for systems that aim to provide long-term confidentiality, this migration should happen even sooner" [@mosca-2015]. The formal statement followed in IEEE Security & Privacy [@mosca-2018].

Here is where honesty matters more than rhetoric. It is tempting to collapse all of this into one dramatic claim -- "adversaries are harvesting your traffic right now for quantum decryption" -- that the public evidence does not support at that strength. The responsible version is layered.

flowchart TD A[Documented threat model: NSA, CISA, NIST, EO 14412] --> D[HNDL risk to long-lived data] B[Documented general collect-and-store precedent: Utah Data Center 2012, Bullrun 2013] --> D C[Rational-actor inference for the specifically quantum motive: no public smoking gun] --> D The "adversary is recording now" premise is three separate claims, and they do not carry equal weight.

(a) A documented threat model. The agencies that set cryptographic policy -- NSA, CISA, and NIST jointly, and now an executive order -- name harvest now, decrypt later explicitly and build the entire migration around it [@cisa-qr] [@eo-14412] [@nsa-press].

(b) A documented general precedent. Bulk interception and indefinite retention of encrypted traffic are established, documented practices, independent of quantum computing [@bamford] [@bullrun].

(c) A rational-actor inference. That some adversary is specifically recording ciphertext today in order to await a quantum computer is a reasonable inference from (a) and (b) -- it is exactly what a well-resourced intelligence agency would do -- but it remains an inference. There is no public smoking gun: no attributed, confirmed nation-state quantum-harvest program on the record. The argument does not need one. It needs only that the behavior is cheap, documented in general form, and officially treated as the reason to migrate.

Recent events keep the general precedent current without proving the quantum-specific one. The Salt Typhoon campaign, detailed in a 2025 joint advisory, compromised the lawful-intercept infrastructure of U.S. telecommunications carriers [@cisa-salt].Salt Typhoon is espionage against wiretap systems -- interception of communications for conventional intelligence. It is not a quantum-harvest operation, and nothing in the advisory characterizes it as one. It belongs here only as evidence that broad, nation-state interception is ongoing.

Note: Every claim in this article about "harvesting now" means the documented threat model, plus the documented general precedent, plus a rational-actor inference. It never means a proven, attributed, ongoing quantum-harvest operation, because none is public. The strength of the argument does not depend on one existing.

Mosca turned "someday" into an inequality you can run against your own data. But to run it, you first have to know exactly what a future quantum computer can and cannot touch -- because it is far less, and far more specific, than the word "encryption" suggests.

3. Why the Whole Public-Key Stack Is on the Clock -- and Symmetric Mostly Is Not

A single machine running Shor's algorithm would break RSA, finite-field Diffie-Hellman, DSA, and elliptic-curve cryptography -- all of them, together. The same machine would barely inconvenience AES-256. To see why the harvest targets one and not the other, and why that distinction is the difference between a five-minute fix and a decade-long migration, you have to separate two kinds of quantum speedup.

A quantum algorithm, published by Peter Shor in 1994, that factors integers and computes discrete logarithms in polynomial time [@shor-1994]. Because RSA rests on the hardness of factoring, and Diffie-Hellman and ECC rest on the hardness of discrete logarithms, one sufficiently large quantum computer running Shor breaks all of them at once. The full mechanism -- reducing both problems to quantum period-finding -- is developed in this article's structural sibling; here we use only the result [@shor-1997].

The reason RSA, DH, DSA, and ECC fall as a group is that they are variations on the same mathematical trick: a one-way function built from a hidden period or a hidden subgroup. Shor's algorithm is, at its core, a period-finder. Break that abstraction once and every primitive built on it goes down with it -- which is why "quantum-safe" cannot mean "a bigger RSA key." A 4096-bit RSA modulus falls to the same algorithm as a 2048-bit one; only the running time changes, and not by enough to matter [@shor-1997].

Symmetric cryptography is a different story, and the difference is a theorem, not an accident. Against a symmetric cipher or a hash, the best known quantum attack is Grover's algorithm, which delivers only a quadratic speedup -- it effectively halves the security level. A 256-bit key offers roughly 128 bits of security against a quantum search, which is still far out of reach.Grover's quadratic speedup is neutralized by doubling the key or lengthening the digest, and symmetric crypto scales cheaply: doubling the key size typically costs far less than half again the performance [@cf-pq2024]. This is why AES-256 and SHA-384/512 need no replacement [@cnsa-2]. That is exactly why the NSA's post-quantum suite keeps AES-256 and SHA-384/512 unchanged while replacing every public-key algorithm [@cnsa-2], and why NIST pins its post-quantum security categories to symmetric strengths Grover cannot reach [@cf-pq2024].

So the casualty is specific. It is not "encryption" in general. It is public-key key establishment: the handshake step where two parties agree on the symmetric key that will actually encrypt the data.

The step in a secure protocol where two parties agree on a fresh shared secret -- the symmetric session key -- that encrypts the rest of the conversation. In TLS this is the key-exchange portion of the handshake. It travels in the clear, which is exactly why an adversary can record it, and it is the specific thing harvest now, decrypt later targets.

Why key establishment and not the bulk-encrypted payload directly? Because the payload is protected by a symmetric key that Grover cannot recover -- but that key was itself agreed using a public-key exchange that Shor can break. Record the handshake and the ciphertext together, wait for a CRQC, run Shor against the recorded public values, recover the session key, and the whole conversation decrypts. The symmetric layer never had to fall; the key that unlocks it was handed over in a form the future machine can read.The same RSA or ECC key pair can serve key establishment (confidentiality) or signatures (authenticity). Only the confidentiality use is harvestable in advance. Signatures are a separate casualty, on a separate clock.

This sets the contract for the rest of the article, and it is a contract with two clocks.

Note: Confidentiality (harvest now, decrypt later). An adversary records ciphertext today and decrypts it after a future CRQC exists. The decisive act is now; the fix is post-quantum key establishment, deployable today. Authenticity (signature forgery). An adversary forges a signature. This requires a quantum computer at the moment of the attack -- you cannot forge tomorrow's signature by recording today's traffic. It is a real problem, but a later one, on a different clock. The two never share a single verdict.

The confidentiality casualty, then, is narrow and precise: public-key key establishment, recorded today, decrypted after Q-Day. The next question is what defenders did once they understood that -- and it turns out they have been racing this particular recording for the better part of a decade.

4. The Defense, Generation by Generation, Racing the Harvest

Here the usual shape of a "how it breaks" story inverts. There is no lineage of attacks to catalog, because the attack is future and singular -- one machine, not yet built. What has a lineage is the defense. And the first entry in that lineage is not a defense at all. It is the status quo, and its weakness is this article's entire thesis.

Generation 0: the harvestable baseline

Classical public-key key establishment -- RSA key transport, and in modern TLS 1.3 the elliptic-curve exchange X25519 -- is where the loss is booked. Two parties derive a shared secret from public values whose security rests on factoring or the discrete logarithm; the handshake, including those public values, crosses the wire in the clear.

Modern TLS already improved on the worst version of this. Ephemeral elliptic-curve Diffie-Hellman gives forward secrecy.

A property of ephemeral key exchange: because each session's secret is generated fresh and never transmitted, compromising a server's long-term private key later does not decrypt past recorded sessions. It defends against a future *key* compromise -- but not against a future break of the underlying *math*.

That last distinction is the whole game. Forward secrecy assumes the discrete-logarithm problem stays hard; Shor voids that assumption. As Cloudflare put it, encrypted traffic "can be harvested today, and decrypted with a quantum computer in the future" -- and against that recording, even forward secrecy does not help [@cf-pq2024]. An adversary who records the X25519 handshake plus the ciphertext has everything needed to recover the session key once a CRQC exists: Mosca's inequality booking a loss the moment $X + Y > Z$ [@mosca-2018]. Gen 0 is not broken today -- RSA-2048 is unbroken in 2026 -- but protecting must-outlive-Q-Day data with it while the recording runs is the deployment choice that decides the casualty.

If the loss is booked at capture time, the defense cannot wait for Q-Day. It has to put a quantum-resistant secret into the handshake before the recording is made.

Generation 1: the first hybrids

In 2016, Google ran the first real experiment: CECPQ1, a combination of X25519 with NewHope, a lattice key exchange, deployed live in Chrome and TLS by Matt Braithwaite and Adam Langley [@google-cecpq1] [@newhope].CECPQ stands for Combined Elliptic-Curve and Post-Quantum. The design principle is right there in the name: run both, and be no worse off than before even if the post-quantum half turns out to be worthless. Two years later came CECPQ2, pairing X25519 with an NTRU-based lattice scheme, HRSS [@langley-cecpq2].

The idea both shared is the one the entire lineage inherits: run a classical and a post-quantum exchange side by side and combine both secrets, so the session is no worse than before even if the post-quantum part is later found useless. Langley's rationale for shipping years ahead of any standard was itself a harvest-now-decrypt-later argument, and he drew the confidentiality-versus-authenticity line this article insists on, noting that the work "only addresses confidentiality, not authenticity," and that "confidentiality is more pressing since it can be broken retrospectively" [@langley-cecpq2].

NewHope, CECPQ1's post-quantum half, was only CPA-secure -- a weaker guarantee than usual. That was acceptable in TLS precisely because confidentiality keys there are ephemeral, used once and discarded [@newhope].

These were experiments, built to be thrown away. They used pre-standard primitives chosen before NIST had settled the field -- "destined to be replaced," in Langley's words [@langley-cecpq2]. What they proved is that a hybrid can ride real TLS at scale, surfacing the practical problems (larger handshakes, middlebox tolerance) that would dominate deployment. The field now needed a single, vetted primitive to put inside the hybrid.

Generation 2: the standardized primitive

On 13 August 2024, NIST published FIPS 203, standardizing ML-KEM -- the primitive every later deployment instantiates [@fips-203].

The Module-Lattice-Based Key-Encapsulation Mechanism, standardized as NIST FIPS 203 on 13 August 2024, based on the Module Learning-With-Errors problem. It comes in three parameter sets -- ML-KEM-512, ML-KEM-768, and ML-KEM-1024 -- and it is a key-encapsulation mechanism, explicitly not a Diffie-Hellman-style non-interactive key agreement [@fips-203].

"ML-KEM is the new name for Kyber" [@cf-pq2024]. The scheme was called CRYSTALS-Kyber during the NIST competition; in a 2026 voice the standardized name is ML-KEM, and that is the name used throughout here.

The structural point that shapes everything downstream: ML-KEM is a KEM, not a NIKE. Rather than two parties deriving a key from public values with no message in between (which is what Diffie-Hellman does), one party encapsulates a fresh secret to the other's public key and sends back a ciphertext. That single fact is why the deployed answer is a hybrid handshake and not a drop-in "post-quantum Diffie-Hellman." But a primitive sitting in a PDF protects no packet, and ML-KEM deployed alone is a single-primitive bet on a young standard -- a bet the next section shows can go badly. The prudent way to ship it is inside a hybrid.

Generation 3: protocol integration

This is where the standard becomes protection booked at capture time. For TLS 1.3, the IETF defined the hybrid group X25519MLKEM768: a client share of 1216 bytes -- a 1184-byte ML-KEM-768 encapsulation key concatenated with a 32-byte X25519 share -- combined into a 64-byte shared secret, at codepoint 0x11EC [@ietf-mlkem].

Secure messaging moved even earlier. Signal shipped PQXDH, "an upgrade to the X3DH specification," to all users on 19 September 2023 -- the first at-scale messenger to put post-quantum protection into initial key establishment [@signal-pqxdh]. Apple followed on 21 February 2024 with iMessage PQ3 [@apple-pq3]. And remote administration was not far behind: OpenSSH 9.9, released 2024-09-19, made the hybrid mlkem768x25519-sha256 exchange available by default [@openssh-99].

Every one of these derives the session key from both an X25519 secret and an ML-KEM secret, so it stays secure if either component holds. Each session negotiated this way is one the harvest can no longer bank on. What integration did not yet deliver was ubiquity: in 2024 these were defaults on some clients and servers, not all, and the surfaces most likely to hold long-lived secrets lagged furthest behind.

Generation 4: scale

Then the defaults arrived. OpenSSL 3.5, released 8 April 2025, changed its default TLS groups to include and prefer hybrid post-quantum KEM groups [@openssl-35]. With Chrome and Firefox defaulting to the hybrid on the client side and Cloudflare terminating it at the edge, adoption climbed from "nearly two percent" of Cloudflare's TLS 1.3 connections in early 2024, toward double-digit adoption by the end of that year [@cf-pq2024], to a majority of human web traffic by late 2025 [@cf-pq2025]. The exact figure, around 52 percent, is best read as a dated snapshot from live telemetry rather than a steady state [@cf-radar] [@heise] [@postquantum-com].

flowchart LR G0[Gen 0: classical-only X25519 and RSA, harvestable] --> G1[Gen 1: hybrid experiments CECPQ1 2016, CECPQ2 2018] G1 --> G2[Gen 2: standardized primitive ML-KEM / FIPS 203, 2024] G2 --> G3[Gen 3: protocol integration PQXDH, PQ3, OpenSSH 9.9, X25519MLKEM768] G3 --> G4[Gen 4: hybrid default across a majority of web traffic, 2025]

Generation	Year	Key idea	Representative	Status
Gen 0 -- harvestable baseline	1990s-present	Classical-only key establishment; forward secrecy only	RSA key transport, X25519 ECDHE	Still-live baseline [@cf-pq2024]
Gen 1 -- first hybrids	2016, 2018	Classical + pre-standard PQ, safe if either half holds	CECPQ1, CECPQ2	Historical [@langley-cecpq2]
Gen 2 -- the primitive	2024	A single vetted, standardized KEM (not a NIKE)	ML-KEM / FIPS 203	Active component [@fips-203]
Gen 3 -- integration	2023-2024	Wire the KEM into real handshakes as a hybrid	X25519MLKEM768, PQXDH, PQ3, OpenSSH 9.9	Active [@ietf-mlkem] [@signal-pqxdh] [@apple-pq3] [@openssh-99]
Gen 4 -- scale	2025	Hybrid on by default at internet scale	OpenSSL 3.5; majority of web traffic	Active frontier [@openssl-35] [@cf-pq2025]

Each generation closed one gap the last had left open: no vetted primitive, then no deployment, then no ubiquity. None closed the one gap that no later fix can close -- the ciphertext an adversary already captured. And one question still hangs over the whole catalog: why wrap a standardized post-quantum algorithm in a hybrid at all? Why not simply ship the newest, strongest post-quantum scheme on its own? A dead end from 2022 answers that better than any argument.

5. The Ten-Minute Break That Vindicated Hybrids

In July 2022, a post-quantum key-encapsulation mechanism named SIKE was broken. Not weakened -- broken, completely, its private key recovered from public data. The remarkable part was how. SIKE was not a fringe proposal; it was a NIST Round-4 candidate, a scheme that had survived years of public analysis in the world's most scrutinized cryptography competition. And it fell not to a quantum computer but to a mathematician with a laptop.

The attack "breaks SIKEp434, which aims at security level 1, in about ten minutes on a single core." -- Wouter Castryck and Thomas Decru [@sike-break]

Castryck and Decru found that the extra data SIKE's underlying protocol exchanged -- torsion-point images -- leaked enough structure to recover the secret key in heuristic polynomial time. Their implementation broke the security-level-1 parameter set in about ten minutes on one CPU core [@sike-break]. No error correction, no millions of qubits. Just mathematics that had been missed.

Now hold that against the problem this article has been building toward. You are deploying cryptography to protect data whose confidentiality must outlast a recording you cannot see and cannot un-make. If you bet everything on a single post-quantum scheme, and that scheme turns out to have a SIKE-shaped flaw discovered five years from now, every session you protected with it becomes retroactively readable -- and the ciphertext is already in someone's archive. Against a recording you cannot un-make, a single-primitive bet on a young standard is the one bet you cannot afford.

That is the whole argument for hybrids, and it fits in a sentence.

Key idea: Migration is a race against a recording you cannot see. Because you can never un-capture ciphertext, the only defense is to change the deployment before capture -- and the only change safe against both a future quantum computer and an undiscovered flaw in young post-quantum math is a hybrid that survives if either component holds.

Deriving one session key from two independent key exchanges -- a classical one such as X25519 and a post-quantum one such as ML-KEM-768 -- combined through a key-derivation function so the result stays secure as long as at least one of the two remains unbroken. It is a deliberate hedge in both directions: against a future quantum break of the classical half, and against an undiscovered flaw in the young post-quantum half.

Here is the part that turns the argument from plausible to proven. When Google and Cloudflare trialed the isogeny family, they did it as a hybrid too -- CECPQ2b, X25519 combined with SIKE. So when SIKE collapsed in 2022, the question was not academic: what happened to the sessions that had negotiated the SIKE hybrid? The answer is that they were fine. Every X25519 plus SIKE session stayed confidential, because X25519 held when SIKE fell. The "safe if either half holds" design did exactly its job -- in the field, against a real and total break of one half.

SIKE is a dead end, not a step in the defense lineage -- but it is the load-bearing dead end, because it is the empirical proof of the hybrid thesis. A NIST Round-4 candidate KEM fell to a laptop in minutes, and the deployments that had wrapped it in a hybrid lost nothing, because their classical half was untouched. This is the concrete answer to the tempting question "why not just ship the newest pure post-quantum algorithm?" Because young primitives can die suddenly, without warning, from a piece of mathematics nobody had noticed -- and when the thing you are protecting is a recording that cannot be un-made, you diversify the bet. The isogeny *idea* is not entirely dead, but SIKE as a key-establishment path is finished, and it took CECPQ2b with it [@sike-break].

The design principle is now settled, and the deployment is largely built. So what does correct, quantum-safe confidentiality actually look like on the wire in 2026?

6. What Quantum-Safe Confidentiality Looks Like in 2026

By 2026 the state of the art has converged on a single shape: a standardized post-quantum KEM (ML-KEM), wrapped in a hybrid with a classical elliptic-curve exchange, wired into the real key-establishment step of TLS, SSH, and secure messaging, and turned on by default. Everything deployed today is a variation on that one sentence.

Start with the flagship. The TLS 1.3 hybrid group X25519MLKEM768 sends a client share of 1216 bytes -- the 1184-byte ML-KEM-768 encapsulation key followed by the 32-byte X25519 share -- and receives a 1120-byte server share, a 1088-byte ML-KEM ciphertext plus the server's 32-byte X25519 share, from which both sides derive a 64-byte combined secret. Its IANA codepoint is 0x11EC [@ietf-mlkem].The group name lists its components in the reverse of their wire order: the client share carries the 1184-byte ML-KEM-768 key first, then the 32-byte X25519 share, yet the name puts X25519 first, "for historical reasons" [@ietf-mlkem]. Naming is hard, even in cryptography.

A three-algorithm scheme -- key generation, encapsulation, and decapsulation -- in which one party encapsulates a fresh random secret to the other's public key and transmits the resulting ciphertext, and the key holder decapsulates it to recover the same secret. This is structurally unlike a non-interactive key agreement (a NIKE) such as Diffie-Hellman, where both sides derive the key from public values with no ciphertext exchanged. ML-KEM is a KEM, which is why the post-quantum answer is a hybrid handshake and not a "post-quantum Diffie-Hellman" [@fips-203]. sequenceDiagram participant C as Client participant S as Server C->>S: X25519 share and ML-KEM-768 encapsulation key (1216-byte client share) S->>C: X25519 share and ML-KEM-768 ciphertext (1120-byte server share) Note over C,S: Each side computes an X25519 secret AND an ML-KEM secret Note over C,S: A KDF combines both into the session key, safe if either half holds

The same hybrid shape shows up everywhere else. OpenSSH exposes it as mlkem768x25519-sha256, available by default since 9.9 [@openssh-99]. Signal's PQXDH puts a lattice KEM alongside the classical exchange in initial key establishment; Apple's PQ3 does the same and extends post-quantum protection to ongoing rekeying as well [@signal-pqxdh] [@apple-pq3]. Apple ranks these on a coarse scale of its own -- Signal's initial-key-establishment protection at "Level 2," PQ3's establishment-plus-rekey at "Level 3" -- though those levels are Apple's own taxonomy, not an industry standard [@apple-pq3].

Method	Layer protected	Break requires	Extra wire cost	Default on?
X25519MLKEM768 (TLS)	TLS key establishment	X25519 and ML-KEM-768	~1.2 KB client share	Yes: browsers, OpenSSL 3.5 [@openssl-35]
mlkem768x25519-sha256 (SSH)	SSH key establishment	X25519 and ML-KEM-768	~1.2 KB	Yes: OpenSSH 9.9 and later [@openssh-99]
PQXDH (Signal, "Level 2")	Messaging initial key est.	X25519 and lattice KEM	~1 KB per establishment	Yes: all users [@signal-pqxdh]
PQ3 (Apple, "Level 3")	Messaging key est. and rekey	ECC and lattice KEM	~1 KB per est. and rekey	Yes: iOS 17.4 and later [@apple-pq3]
Pure ML-KEM-1024 (CNSA 2.0)	Key establishment	ML-KEM-1024 alone	~1.5 KB, no ECC	Federal direction [@cnsa-2]
Classical X25519 (baseline)	Key establishment	X25519 alone, so a CRQC	none (32-byte baseline)	Yes: legacy [@cf-pq2024]

Notice what the KEM structure forces. Because ML-KEM encapsulates a secret and returns a ciphertext, rather than agreeing a key from two public values the way Diffie-Hellman does, the deployed construction is a hybrid handshake, not a "post-quantum Diffie-Hellman" [@fips-203]. That is the single most common misconception about post-quantum key exchange, and the shape of the wire is why it is wrong.

A key-agreement scheme in which two parties compute a shared secret purely from each other's published public values, with no ciphertext or extra protocol message passing between them -- which is exactly what classical Diffie-Hellman is. A KEM is not a NIKE: it requires one side to encapsulate a secret and send a ciphertext back. That structural gap is why a genuine "post-quantum Diffie-Hellman" would need a post-quantum NIKE, and why the absence of one forces the deployed answer into a hybrid handshake instead [@fips-203]. If a true post-quantum Diffie-Hellman existed -- a non-interactive key exchange as clean as the classical one -- it would be the perfect drop-in, and none of the hybrid-handshake plumbing would be necessary. One candidate does exist in the literature: CSIDH, an isogeny-based group action its authors proposed as "suitable for non-interactive key exchange in a post-quantum setting," with public keys of only 64 bytes [@csidh]. But its concrete quantum security is disputed -- Peikert's C-sieve cryptanalysis "strongly invalidates its claimed NIST level 1 quantum security" for the CSIDH-512 parameters [@peikert-csieve] -- and it belongs to the same isogeny family whose SIKE cousin fell classically in ten minutes. The information-theoretic alternatives, the one-time pad and quantum key distribution, do not scale to open-internet key establishment. So a standardized KEM wrapped in a hybrid, switched on before capture, is not a compromise forced by expedience. It is the realizable ideal: the best construction actually available, given that the cleaner primitive is either undeployable or untrusted.

The cost of all this is worth stating precisely, because it lands where people do not expect. Lattice operations are cheap; the CPU overhead of an ML-KEM key generation, encapsulation, and decapsulation is negligible. The cost is bytes.

{` const X25519_SHARE = 32; // classical elliptic-curve share const MLKEM768_EK = 1184; // ML-KEM-768 encapsulation key (FIPS 203) const hybridShare = MLKEM768_EK + X25519_SHARE; // 1216 bytes, codepoint 0x11EC

console.log('Classical X25519 client share :', X25519_SHARE, 'bytes'); console.log('Hybrid X25519MLKEM768 share :', hybridShare, 'bytes'); console.log('Extra on the wire : ~' + ((hybridShare - X25519_SHARE) / 1024).toFixed(2) + ' KB'); // ~1.2 KB extra is why a post-quantum ClientHello can span more than one TCP segment (tldr.fail). // CPU cost is negligible: lattice KEM operations are cheap. `}

About 1.2 kilobytes of extra ClientHello: that is the price of quantum-safe confidentiality on the wire, and it is why the hard problems in this migration are network problems -- does the larger handshake fit through every middlebox? -- rather than compute problems.

Now the honest part, the part a launch post tends to skip.

Note: Turning on X25519MLKEM768 protects new key establishment. It does nothing for four things: ciphertext an adversary already captured (irreversible); digital signatures and the Web PKI (a different threat model, on a different clock); data encrypted at rest under a quantum-vulnerable scheme; and the long tail of non-browser protocols that have not enabled a hybrid group. A "majority of web traffic" statistic is a browser statistic.

That last point deserves weight before we move on. The adoption curve is real, but it measures browser-terminated TLS. It says nothing about the VPN concentrator, the mail server, the database connection, or the backup pipeline -- and those are exactly the surfaces most likely to be carrying secrets with long confidentiality lifetimes.

This shape -- ML-KEM in a hybrid, on by default -- is the consensus of browsers, Signal, Apple, OpenSSH, and the CDNs. But it is not the consensus of everyone. The U.S. government is quietly betting on a different design, and the disagreement is real.

7. The Migration's Open Fault Lines

The commercial internet ships hybrids. The NSA does not want to. Its Commercial National Security Algorithm Suite 2.0 leans toward pure ML-KEM-1024, with no classical curve alongside it [@cnsa-2]. This is not a mistake to correct in either direction. It is a real disagreement between reasonable parties, worth understanding rather than resolving.

Hybrid versus pure

The case for the hybrid is the one this article has already earned: provably secure if either component holds, and vindicated in the field when SIKE fell. The formal guarantee is not a slogan. For the exact pairing of X25519 with ML-KEM-768, the X-Wing construction proves the combined KEM is secure as long as either component is -- classically if X25519 holds, post-quantum if ML-KEM-768 holds [@xwing]. To recover a hybrid session key, an adversary must break both the elliptic-curve discrete logarithm (which needs a quantum computer) and Module-LWE (which needs a cryptanalytic break) -- strictly harder than breaking either one alone.

There is a deeper reason the hybrid is more than belt-and-suspenders, and it is epistemic rather than mechanical. ML-KEM's security rests on the presumed hardness of a lattice problem -- and "presumed" is the load-bearing word.

The lattice problem underneath ML-KEM: recovering a secret from many linear equations over a polynomial module that have been deliberately perturbed with small random errors. FIPS 203 claims only that ML-KEM "is believed to be secure, even against adversaries who possess a quantum computer" -- there is no proof that Module-LWE is hard for a classical or a quantum machine, any more than there is a proof that integer factoring or the discrete logarithm is hard [@fips-203].

This is the honest core of the hybrid argument. The security of RSA, of elliptic curves, and of ML-KEM alike rests on unproven conjectures -- problems the world has failed to solve, not problems anyone has shown are unsolvable. A hybrid does not escape that condition; it diversifies the wager across two independent unproven conjectures, so that a break of either one alone is survivable. It buys resilience, not a proof. Nothing deployed at internet scale offers a proof.

The case for pure ML-KEM-1024 is not irrational either. A vetted standard at its highest parameter set, the argument goes, should stand on its own; a hybrid adds a second code path, a combiner to get right, and larger messages, and complexity is itself attack surface. The preference is old and consistent: at CRYPTO 2018 the NSA already stated its intent to publish pure post-quantum standards "not combined with an elliptic-curve operation as a safeguard," as Langley recorded at the time [@langley-cecpq2].

Question	Hybrid (X25519 + ML-KEM-768)	Pure ML-KEM-1024
If ML-KEM is later broken	Still safe -- X25519 holds	Broken: single-primitive bet
If X25519 is later broken (CRQC)	Still safe -- ML-KEM holds	Safe: ML-KEM is designed for this
Formal guarantee	Secure if either component is secure (X-Wing) [@xwing]	Rests entirely on Module-LWE
Empirical precedent	SIKE hybrid survived the 2022 break [@sike-break]	A pure SIKE deployment would have been harvestable
Complexity	Two code paths plus a combiner	One primitive, one path
Who ships it	IETF, browsers, OpenSSL, OpenSSH, Signal, Apple	NSA CNSA 2.0 for national-security systems [@cnsa-2]

The honest verdict is that this is unresolved. For migration today, against a recording you cannot un-make, the hybrid is the defensible default: it costs one extra primitive and about 1.2 kilobytes to convert "we bet everything on a five-year-old lattice assumption" into "we lose only if both a classical curve and a lattice scheme fall." But the pure-PQC position -- that ML-KEM-1024 will hold, and that simplicity is a security property -- is a coherent bet on a leaner steady state. The SIKE episode is a live counterexample to single-primitive confidence during migration, not a proof that pure PQC is wrong forever.

It is worth remembering why the field landed on lattices at all, because that too was a measured choice rather than a foregone one.

Metric (production TLS experiment, 2019)	HRSS lattice (CECPQ2)	SIKE isogeny (CECPQ2b)
Public-key size	~1100 bytes	~330 bytes
Relative compute cost	Low (orders of magnitude faster)	High
Typical client	Matches or beats the isogeny scheme	Slower for most clients
Where the isogeny scheme wins	--	Only the slowest tail of clients

Before ML-KEM was the standard, Cloudflare and Google ran a production experiment pitting a lattice hybrid against the tiny-keyed isogeny hybrid, whose public keys were roughly 330 bytes against the lattice scheme's ~1100 [@cf-towards]. Nick Sullivan framed it as an ostrich against a turkey: the lattice scheme big but fast, the isogeny scheme small but slow. The ostrich won -- the lattice hybrid matched or beat the isogeny one for the overwhelming majority of clients, and the small keys did not offset the computational cost [@cf-experiment]. The later SIKE break removed isogeny KEMs from contention on security too. Both results point at the same 2026 answer: a lattice KEM, in a hybrid.

Two migrations, two clocks

The second fault line is not really a contest, and treating it as one is a category error the whole article has worked to prevent. Key-establishment migration closes the harvest-now-decrypt-later window and can be deployed today. Signature migration answers a different threat model -- forgery by a quantum adversary at attack time -- and is years behind, entangled with the certificate infrastructure and slowed by larger, heavier post-quantum signatures. The standardized signature primitives already exist, ML-DSA and SLH-DSA [@fips-204] [@fips-205], with more arriving through NIST's signatures onramp [@pqc-dig-sig], but deployment across the Web PKI has barely begun.

Federal policy keeps the two explicitly separate, and always in the same order.

Three dated policies shape the U.S. migration, and they keep the two clocks apart. CNSA 2.0 sets the direction for national-security systems toward pure ML-KEM-1024 [@cnsa-2]. Executive Order 14412 sets federal deadlines: post-quantum key establishment by 31 December 2030, digital signatures by 31 December 2031 [@eo-14412]. And NIST IR 8547 -- still an initial public draft, so its dates may shift -- would deprecate quantum-vulnerable public-key algorithms after 2030 and disallow them after 2035 [@ir-8547]. Key establishment always leads signatures, because the confidentiality clock is the urgent one.

Note: Neither debate here has a settled answer. Hybrid-versus-pure is a genuine trade-off between diversifying a bet and minimizing complexity. Key-establishment-versus-signature migration is not a contest at all -- they are different problems on different clocks. Anyone who tells you one option simply wins is smoothing over a real disagreement.

Both debates, though, quietly assume you at least know when you must be finished. But the deadline term in Mosca's inequality -- the time until Q-Day -- is the one number nobody can honestly give you.

8. Mosca's Inequality, and What It Can and Cannot Promise

The load-bearing "bound" in this field is a strange one. It is not a complexity bound on an algorithm, nor a lower bound on an adversary's work. It is a decision rule about a race between clocks, and it is the tool that turns a fuzzy future into a concrete, present-tense choice you can make one dataset at a time.

Michele Mosca's decision rule for quantum risk. Let $X$ be the number of years your data must remain secret, $Y$ the number of years your migration to quantum-safe cryptography will take, and $Z$ the number of years until a cryptographically-relevant quantum computer exists. If $X + Y > Z$, your data is already exposed: it will still demand secrecy at a time when the machine that breaks it exists [@mosca-2018].

Read it slowly, because the ordering of the terms is the whole insight. $Y$ and $Z$ are the usual suspects -- how long migration takes, how long until the machine. But $X$, the secrecy lifetime, is what makes the loss present-tense. The adversary's decisive act, capturing the ciphertext, happens now. So for a given dataset you are not really racing $Z$; you are racing $Z$ minus however long the recording has already been running, against $Y$. If your data must stay secret for thirty years, you do not have "until Q-Day" to migrate. You had until the moment someone started recording [@mosca-2015].

flowchart TD A[X: required secrecy lifetime] --> D{"X + Y > Z ?"} B[Y: time to migrate] --> D C[Z: time to a CRQC, uncertain but tightening] --> D D -->|Yes| E[Already exposed: migrate this data class first] D -->|No| F[Lower priority, re-check as Z tightens]

The practical payoff is that you can run this yourself, today, against your own data. The numbers below are illustrative -- pick your own $Z$ and re-run -- but the structure is exactly Mosca's.

{` // X = required secrecy lifetime (years); Y = migration time (years); // Z = years until a cryptographically-relevant quantum computer (UNCERTAIN). const mosca = (X, Y, Z) => (X + Y) > Z;

const Z = 12; // a deliberately uncertain estimate -- change it and re-run const data = [ { name: 'Genomic records', X: 50, Y: 3 }, { name: 'State secrets', X: 30, Y: 3 }, { name: 'Long-term IP', X: 20, Y: 3 }, { name: 'Session cookie', X: 0.1, Y: 3 }, ];

for (const d of data) { const exposed = mosca(d.X, d.Y, Z); console.log(d.name.padEnd(18) + (exposed ? 'ALREADY EXPOSED -- migrate first' : 'lower priority')); } `}

Change $Z$ to anything you like. The genome stays exposed under almost every value you would plausibly choose; the session cookie almost never does. That is the inequality doing its real work -- not predicting Q-Day, but sorting your data by whether the decision has already been lost.

Now the limits, stated as plainly as the thesis.

No cryptographically-relevant quantum computer exists in 2026. RSA-2048 is unbroken. Every qubit figure in circulation is an estimate of what an unbuilt machine would require, and those estimates are falling. In 2019, Gidney and Ekera estimated that factoring RSA-2048 would take on the order of twenty million noisy qubits over about eight hours [@gidney-ekera-2019]. In 2025, Gidney revised the figure to fewer than one million noisy qubits in under a week [@gidney-2025]. That is a roughly twentyfold drop in six years -- and still not a demonstration. The honest description of the timeline is uncertain but tightening.Mosca himself once put "a 1/2 chance of breaking RSA-2048 by 2031" -- but that is his estimate, not a consensus, and this article endorses no Q-Day date [@mosca-2015].

This uncertainty is exactly why some cryptographers who once shrugged at the quantum threat no longer do. The falling estimates do not name a date; they make the risk action-forcing without one.

"I need you to recognize how immediately dispositive that is." -- Filippo Valsorda, on why an uncertain timeline is still action-forcing [@valsorda]

There is a common objection worth meeting head-on: most TLS traffic is short-lived, so who cares if it is harvested? The objection is correct, and it does not weaken the thesis -- it sharpens it. Because ephemeral session traffic has almost no value years from now, the genuine harvest-now-decrypt-later risk concentrates precisely on the data with long confidentiality lifetimes: state secrets, health and genomic records, source identities, long-term intellectual property. The short-lived-traffic point does not universalize the casualty; it focuses it.

All of this rests on conjectural hardness. No one has proved that a quantum computer -- or even a classical one -- cannot break ML-KEM, RSA, or elliptic curves. Their security rests on the presumed hardness of Module-LWE, factoring, and the discrete logarithm; FIPS 203 itself claims only that ML-KEM "is believed to be secure" [@fips-203]. A hybrid does not dissolve that uncertainty. It spreads the wager across two independent unproven conjectures, so a break of one alone is survivable, but it proves nothing -- which is why this migration is risk management performed before capture, not a certificate of safety [@xwing].

And then the one limit no engineering reverses.

Key idea: Harvested ciphertext is the one loss no future fix reverses. Migration can protect every session from this moment forward, but it cannot reach back and protect a recording already sitting in an archive. For data whose secrecy must span the gap, the decision was made at capture -- which is why the deployment choice, not the future math, is where the casualty is booked.

The inequality tells you how to decide under uncertainty. But it silently assumes one thing: that you can still migrate before capture. For a great deal of data already on the wire, that assumption is false. Which raises the question the deployment curve tends to obscure: where does the harvest still win?

9. Where the Harvest Still Wins

A majority of web traffic riding hybrid key agreement is a real milestone, and also a misleading one, because "majority of web traffic" is not "done." Six frontiers remain, and the first is permanent.

Ciphertext already captured. This is the irreversible frontier. Any long-lived secret already sent under classical-only key establishment and recorded by an adversary is beyond rescue; no hybrid, no key rotation, no future standard can reach into an archive and un-capture it. The only levers left are operational -- re-key and re-encrypt long-lived secrets under a hybrid now, so you stop adding to the harvested set, and rotate credentials that may already be exposed. You can stop the set from growing. You cannot make it smaller.

The long tail of unmigrated surfaces. Browser TLS is migrating fast; almost nothing else is. VPNs, email transport over SMTP and IMAP, database connections, internal service meshes, backups, machine-to-machine APIs, and the vast installed base of IoT devices still negotiate classical-only key establishment in 2026. These surfaces are not a random sample -- they disproportionately carry exactly the long-confidentiality-lifetime data where the sharpened risk concentrates.

Note: The adoption number that gets quoted -- a majority of human web traffic -- is a browser number. The mail server holding a decade of correspondence, the database of health records, the backup vault, and the site-to-site VPN carrying internal traffic are usually still classical-only. The surfaces least migrated are the ones whose secrets have the longest lifetimes.

The bug that makes turning it on look like breaking the internet. There is a mundane, maddening obstacle to flipping the switch.

A post-quantum ClientHello is about 1.2 kilobytes larger than a classical one, which pushes it past a single packet. A single call to TCP `read()` may then return only part of the ClientHello. Servers and middleboxes that quietly assumed a one-packet ClientHello -- calling `read()` exactly once, or refusing a split message -- reject the connection outright instead of falling back to a classical handshake. Enabling post-quantum key exchange can therefore look, from the outside, like it "breaks the internet," when it merely exposes a pre-existing bug in how those servers read from a socket. The failure is documented and named at tldr.fail, which also makes the boundary point this article keeps insisting on: the store-then-decrypt threat does not apply to authentication, because connections are authenticated in real time, so signatures are not harvestable the way key establishment is [@tldrfail].

Timeline uncertainty. Z is unknowable from public information. The estimates fall, but they describe unbuilt hardware, and no one can honestly hand you a date. Over-confidence in a late Z under-protects long-lived data; a false "imminent" claim wastes scarce migration effort. The discipline is to treat Z as uncertain but tightening, and decide by data lifetime rather than prediction.

Crypto-agility and inventory. Most organizations cannot say, with confidence, where and which cryptography they run. You cannot prioritize -- or even find -- the long-lived-secret surfaces that harvest now, decrypt later targets, if they are invisible to you.The blunt version: you cannot rotate what you cannot see. An un-inventoried quantum-vulnerable endpoint protecting decade-lifetime data is a silent casualty. Building and maintaining that inventory is the subject of this article's crypto-agility and cryptographic-bill-of-materials sibling. The official guidance already centers this: the joint CISA, NSA, and NIST quantum-readiness factsheet urges a cryptographic inventory that prioritizes long-term-confidentiality data [@cisa-qr], and NIST IR 8547 sets the deprecation clock that inventory has to race [@ir-8547].

The signature and PKI migration. Authentication is also quantum-vulnerable, but -- and this is the boundary the whole article has policed -- it is not the harvest-now-decrypt-later problem. Forging a signature needs a quantum computer at attack time, so it cannot be harvested in advance. Its migration is the separate, later track the fault-lines section already mapped. It is important, it is on a separate clock, and it is not the confidentiality remedy.

None of this is hopeless. Most of it is a to-do list. So here is the to-do list, in priority order.

10. What to Do Before Q-Day, Prioritized by Data Lifetime

You cannot un-capture the past. But you can stop feeding the harvest today, and the order in which you do it is not arbitrary -- it is set by the confidentiality lifetime of each data class. Run Mosca's inequality in your head as you read: the longer the secrecy lifetime, the more urgent the migration.

1. Inventory the longest-lived secrets first. Before turning any knob, find the data whose secrecy must span decades: genomic and health records, state secrets, source identities, long-validity keys, long-term intellectual property. For each class, the secrecy lifetime alone may already exceed any plausible time-to-Q-Day, which puts it at the front of the queue. You cannot protect what you have not located.

Data class	Typical secrecy lifetime	Priority	Action
Genomic and health records	Decades	Highest	Hybrid now; re-encrypt stored data
State secrets, source identities	25+ years	Highest	Hybrid now; audit what may already be captured
Long-term IP, legal, financial	10-20 years	High	Hybrid on all TLS and SSH termination
Business correspondence, email	Years	Medium	Post-quantum-capable transport and messaging
Session tokens, ephemeral traffic	Minutes to hours	Low	Migrate with the default; no rush

2. Turn on hybrid key establishment wherever you terminate TLS or SSH. This is the single most effective action, and modern tooling makes it nearly free: OpenSSL 3.5 ships the hybrid group as a default, and OpenSSH 9.9 and later offer mlkem768x25519-sha256 by default [@openssl-35] [@openssh-99]. It is downgrade-safe -- a peer that does not support the group simply negotiates a classical one -- so enabling it is never worse than the status quo.

On a recent OpenSSH build, list the key-exchange algorithms and look for the hybrid:

ssh -Q kex | grep mlkem

If mlkem768x25519-sha256 appears, your client can already negotiate post-quantum key exchange (OpenSSH 9.9 and later). For TLS, a current OpenSSL can attempt the hybrid group directly:

openssl s_client -groups X25519MLKEM768 -connect example.com:443

A completed handshake means both ends agreed on the hybrid group.

3. Prefer post-quantum-capable messaging for confidential conversations. Signal's PQXDH protects initial key establishment for all users; Apple's PQ3 adds ongoing rekeying on top of it [@signal-pqxdh] [@apple-pq3]. Messaging is a canonical long-lived-secret surface, and both are already deployed.

4. Do not wait for pure post-quantum cryptography.

Note: During migration, the hybrid is the move to make now. It is provably secure if either component holds [@xwing], it was vindicated when SIKE fell, and it is downgrade-safe: against a peer that does not support it, TLS simply negotiates a classical group, so a hybrid is never worse than what you already run. Pure ML-KEM is a defensible steady-state target, not a reason to delay hybrid deployment today.

5. Treat signatures and PKI as a separate, later track. Migrating your key exchange does not touch quantum forgery of signatures, and it does not need to -- that is a different threat model on a different clock. Track it separately, and do not let a signature-migration timeline slow your confidentiality migration, or the reverse.

6. Expect the large-ClientHello bug, and test before flag-day. When you enable the hybrid, some servers or middleboxes may reject the larger handshake because of the one-read() bug rather than fall back gracefully [@tldrfail]. Test your endpoints, fix the socket handling, and rely on browser-side ClientHello splitting where you can.

Key idea: You cannot un-capture the past, but you can stop feeding the harvest today. Every session you move to a hybrid before it is recorded is one loss that never gets booked. That is the entire discipline: change the deployment before capture, prioritized by how long each secret must live.

That is the whole discipline: decide by lifetime, deploy the hybrid before capture, and keep the two clocks separate. What is left are the questions people ask next -- and most of them are misconceptions worth correcting precisely.

11. Misconceptions, Precisely Corrected

No. No cryptographically-relevant quantum computer exists in 2026, and RSA-2048 is unbroken [@gidney-2025]. The risk is not present-day decryption; it is present-day *capture*. An adversary who records your ciphertext today can decrypt it only once such a machine exists, which is exactly why the loss is decided at capture time rather than at decryption time [@mosca-2018]. The threat model is documented -- NSA, CISA, NIST, and an executive order all name it explicitly [@cisa-qr] [@eo-14412] -- and the general practice of bulk interception and indefinite retention is documented independently of quantum computing [@bamford] [@bullrun]. What is *not* publicly established is a specific, attributed, ongoing nation-state program that harvests ciphertext in order to await a quantum computer. That is a rational-actor inference, not a public smoking gun, and the case for migrating does not depend on one existing. Yes -- and that sharpens the argument rather than weakening it. Because ephemeral session traffic has little value years from now, the genuine harvest-now-decrypt-later risk concentrates on data with long confidentiality lifetimes: state secrets, health and genomic records, source identities, long-term intellectual property. The nuance focuses the casualty; it does not dissolve it. No. Key-establishment migration closes the confidentiality (harvest-now-decrypt-later) window. Signature forgery is a different threat model that needs a quantum computer at attack time, so it cannot be harvested in advance; its migration runs on a separate, later clock [@eo-14412]. The two never share a single verdict. Yes. ML-KEM is the standardized name for the scheme formerly called CRYSTALS-Kyber, published as NIST FIPS 203 [@fips-203]. "ML-KEM is the new name for Kyber" [@cf-pq2024]; in a 2026 voice, use ML-KEM. The internals of the primitive -- Module-LWE, lattice sampling, decapsulation -- are the subject of this article's post-quantum-toolkit sibling. No. ML-KEM is a key-encapsulation mechanism, not a non-interactive key agreement; one side encapsulates a secret and sends a ciphertext, rather than both sides deriving a key from public values the way Diffie-Hellman does [@fips-203]. The deployed answer is therefore a hybrid *handshake*, not a drop-in "post-quantum Diffie-Hellman." During migration, prefer a hybrid. It is provably secure if either component holds [@xwing], and the SIKE break is the empirical proof: a NIST Round-4 candidate KEM fell classically in about ten minutes, and every deployment that had wrapped it in a hybrid stayed safe [@sike-break]. Pure ML-KEM-1024 is a defensible steady-state target -- the direction of U.S. national-security systems [@cnsa-2] -- but not a reason to delay hybrid deployment today.

The paradox we opened with dissolves once you see where the casualty is booked. No quantum computer can factor RSA-2048 in 2026, and yet the loss is real, present, and ongoing -- because the adversary's decisive act is capture, not decryption. Every long-lived secret sent today under a quantum-vulnerable algorithm, while a recording runs, is a casualty already entered in the ledger: collected now, read later, and past the reach of any future fix the moment it is stored.

That is the reconciliation with this series' running thesis, and it holds without an exception. The primitive's mathematics did not cause this break -- RSA-2048 is unbroken, and no cryptographically-relevant quantum computer exists. The deployment did: continuing to protect must-outlive-Q-Day data with a deprecated-but-still-live quantum-vulnerable algorithm while someone records the ciphertext. The remedy is a deployment change you can make today -- hybrid X25519 plus ML-KEM key establishment -- and its urgency is set entirely by how long your data must stay secret.

So the only question that ever mattered is the one we started with: what were you doing at capture time? If the answer is "shipping a hybrid before the recording was made," the loss was never booked. If it was "waiting for Q-Day," you were already too late. The mechanism that finishes the job -- one machine running Shor's algorithm against RSA, Diffie-Hellman, and ECC at once -- is the subject of the sibling article "How Q-Day Breaks Everything: Shor's Algorithm and the Simultaneous Fall of RSA, Diffie-Hellman, and ECC." Knowing where your own quantum-vulnerable cryptography lives, so you can change it before capture, is the subject of the crypto-agility and cryptographic-bill-of-materials sibling. Both matter. Neither un-captures a recording. Only the deployment you ship before capture ever could.

Parag Mali - tag: harvest-now-decrypt-later