The Quantum Attack That's Already Happening Is the Recording.

The reassuring version of the quantum threat is that it lives in the future. A cryptographically relevant quantum computer does not exist yet, the optimistic estimates put it years out, and so there is time to plan calmly. That reasoning is sound for one class of attack and completely wrong for another. For anything whose value is confidentiality held over time, the attack has already started — and it does not need a quantum computer to be under way. It needs a hard drive.

The move is called harvest now, decrypt later. An adversary records encrypted traffic today, capturing ciphertext off the wire and storing it, and then waits. The decryption happens on the day the capability finally arrives. Nothing about today's cryptography stops the recording; it only delays the reading. Which means the deadline that actually governs you is not when quantum computers arrive, but how long your data must stay secret.

The threat is retrospective

Most threat models are prospective: they ask what an attacker can do to you going forward, and your defenses improve as you patch and harden. Harvest-now-decrypt-later inverts that. The damage is done to data that already left your control, and no future improvement repairs it. The ciphertext captured today is a time capsule the attacker opens later, on their schedule. You cannot un-send it, re-key it, or claw it back once it sits in someone else's storage. Every day of traffic you emit under a quantum-vulnerable key exchange is another day of recordings accumulating in archives you will never be allowed to audit. The only variable you still control is whether tomorrow's traffic is protected.

Why "quantum is years away" is the wrong frame

The useful question is not "when will a quantum computer exist" but "how long must today's secrets survive". Those are different clocks, and for this threat they point in opposite directions. Even granting every optimistic estimate about how distant the hardware is, that distance is irrelevant to data with a long confidentiality requirement, because the data captured now simply waits in the archive for the hardware to catch up. The "years away" framing quietly assumes your data's value expires before the capability arrives. For a great deal of data that assumption is false, and in most organizations nobody has actually checked which data it is false for.

Mosca's inequality in plain terms

Michele Mosca gave this a shape you can actually use. Call X the number of years your data must remain confidential, Y the number of years it takes you to migrate your systems to quantum-resistant cryptography, and Z the number of years until a quantum computer can break today's algorithms. If X plus Y is greater than Z, you already have a problem — because data you are protecting now will still require protection after the point at which it becomes breakable, and you will not have finished migrating in time to have protected it. The value of the inequality is not precision; none of the three numbers is known exactly. Its value is that it forces three honest estimates and makes the gap between them visible. Lengthen X, lengthen Y, or shorten Z, and the exposure grows.

The deadline for post-quantum confidentiality is not the day a quantum computer is built; it is the day you sent data that must still be secret on the day that computer is switched on.

Which data is actually at risk

Not everything carries this urgency, and treating all traffic as equally exposed is how a migration stalls under its own weight. The test is shelf life — how long a given secret must stay secret — and it sorts your data more usefully than sensitivity alone.

• Long-lived personal data — health records and anything under a long retention or confidentiality duty, where the obligation to protect it is measured in decades rather than quarters.
• State and strategic material — diplomatic, defense, and intelligence traffic whose sensitivity does not fade on any timeline you would bet on.
• Intellectual property — designs, formulas, source, and trade secrets whose entire value is in staying secret for the life of the product or well beyond it.
• Long-term keys and credentials — root secrets and key material that, once recovered from a recording, unlock far more than the one session that happened to carry them.
• Session ephemera — by contrast, a one-time code or a short-lived token whose value evaporates in minutes is nearly immune; recording it buys a future attacker almost nothing.

Confidentiality now, signatures later

It is worth separating the two jobs cryptography does, because the harvest-now threat touches only one of them. This threat is purely about confidentiality. It attacks key exchange, because recovering a past session key is what turns a recording into readable plaintext. It does not attack authenticity the same way: a signature that a quantum computer could forge years from now cannot retroactively forge the document you authenticated today. The forgery threat is genuinely about future forgeries, on a different and generally slower clock. That distinction is the single most useful lever you have for sequencing a migration, because it says plainly that key exchange is the urgent move and signatures can follow behind it.

Prioritizing the migration

You cannot migrate everything at once, so sequence the work by data lifetime rather than by whatever is easiest to touch. Find the flows carrying your longest-lived secrets and protect their key exchange first, ideally with a hybrid so you are not trading one unproven bet for another. Short-lived, low-sensitivity traffic can wait its turn without materially increasing your exposure. The ordering principle is almost embarrassingly simple and almost always ignored: protect the recordings that will still matter on the day they can finally be read, before you spend effort on the ones that will be worthless long before then.

Acting before a deadline you can't see

The hard part of this threat is that there is no alarm. No breach notification fires when your traffic is quietly copied; the adversary's archive is invisible to you, and it always will be. You are being asked to act against a deadline you cannot observe, to protect against a collection you will never be told happened. That is genuinely uncomfortable, and it is precisely why the decision has to be anchored to your own data's shelf life instead of to the next headline about quantum hardware.

When 6QURE reviews an organization's exposure to harvest-now-decrypt-later, the work is not forecasting quantum timelines — that is mostly a distraction dressed up as diligence. It is inventorying which flows carry secrets with a long shelf life, estimating honestly how long a real migration will take, and sequencing the key-exchange work so the longest-lived data is protected first. The recording you cannot stop today is a sunk cost. Whether the data in it will still matter when it is finally read is the question worth answering now, while the answer still changes anything.