9 min read

Quantum Is Breaking Your Cryptography. The Question Is When It Matters.

Quantum Is Breaking Your Cryptography. The Question Is When It Matters.
Photo by Dynamic Wang / Unsplash

June 2026


You can settle your organisation's quantum exposure in three numbers, without guessing when a quantum computer will exist. How long your data must stay secret, how long migration takes, and how close the quantum window sits. That arithmetic, run honestly, tells most organisations the work is a programme to schedule, and tells a few that their data is already exposed today.

This piece gives you the tool to run those numbers and the guide to act on the answer.

Why Q-Day is the wrong question to ask

The entire public conversation fixates on a date nobody can predict. Q-Day, the point at which a quantum computer can break the encryption protecting today's data such as RSA-2048, is treated as the moment everything hinges on. Urgency gets keyed to that forecast, and then leaders cannot act on it, because the forecast keeps moving under them.

The movement is real. In 2019 the consensus estimate to break RSA-2048 stood at around 20 million physical qubits; by May 2025 a Google researcher had cut that to under a million. The Global Risk Institute's 2024 expert survey puts the probability of a code-breaking machine at roughly a third by 2034 and around even odds by 2037, a distribution rather than a date.

So a leader waiting for certainty on the timeline will be waiting a long time, and paying for urgency they cannot convert into a decision. The better question ignores the date entirely. It asks whether your data will still need protecting at the point that protection is expected to fail, and that question was answered in 2018 by the cryptographer Michele Mosca.

The arithmetic that decides it

Mosca's inequality, sometimes called Mosca's theorem, is a simple risk-timing test that needs three inputs and no crystal ball. Take the time to migrate your cryptography (X), add the time your data must stay confidential (Y), and compare the total against the time until a quantum computer arrives (Z). If X plus Y is greater than Z, data created today is already at risk, because it must stay secret past the point its protection breaks.

The honest part is what you do with Z. It is a forecast with a wide spread, so the right approach lets the verdict track expert probability and lets you choose the risk stance you are willing to accept. An organisation starting migration now, taking three years to do it, protecting data with a fifteen-year confidentiality life, needs a quantum computer to stay away until 2044. Against a 2033 to 2037 window, that data fails the test.

All of that treats quantum as a future event. The more immediate risk is already running, because an adversary does not need a quantum computer today to act today.

Harvest now, decrypt later: the threat that is already live

In 2021 the NSA stated plainly that adversaries may already be collecting encrypted data now, to decrypt it once quantum computers can. The UK's NCSC said the same in its 2023 Annual Review, describing state-actor data theft for exploitation in years to come. Two signals-intelligence agencies, describing an active strategy in public.

Harvest now, decrypt later changes the shape of the risk. It is not a future line in a budget, it is data that may already have been copied, because the ciphertext only had to be recorded once. What makes data worth harvesting is the value of the secret and how long it stays sensitive: national security records, genomic data, long-term intellectual property, anything an adversary would still want to read in a decade.

That data is collected through two channels. In transit, an adversary taps a targeted link, a specific VPN tunnel or sensitive session, rather than the open internet, which is infeasible to record wholesale even for a state; the extreme cases, undersea cable and ISP-level taps, are tier-one state capabilities aimed at other states, not the average enterprise. At rest, they capture stored ciphertext in bulk, where an exfiltrated backup or archive can hold an entire dataset with decades of confidentiality life in a single copy.

For most enterprises, the honest answer is that this is a low priority, because the data does not justify a state actor's patience. The picture changes if you hold the long-life strategic secrets named above. For those, assuming the data has already been collected is the prudent planning stance, and the question becomes which of your holdings cross that line.

Which of your data sits inside that window is a question you can answer in a few seconds.


What the verdict means: where quantum risk sits in your estate

A verdict of "at risk" raises the obvious question: at risk where? The answer splits your estate cleanly along one line, between data whose confidentiality can be harvested today and data whose protection only matters once a quantum computer exists.

Confidentiality is the live half. Backups, archives, recorded network traffic and long-term stored data are all harvestable now, because an intercepted copy sits in an adversary's storage waiting for Q-Day. Authentication and integrity are the later half: code signing, certificate chains and document signatures cannot be forged retroactively, so they are a migrate-before-Q-Day problem rather than a harvested-today one.

The table below maps the common asset types to which half they fall in, and what to watch in practical terms.

← Scroll to see full table

Asset What’s at risk Clock What to watch in practice
Backups and archives Confidentiality. Encrypted under RSA/ECC key exchange, copied once, held for years. Now Your oldest backups are your highest exposure. If a copy was taken, the ciphertext is already out of your control. Inventory retention periods and re-encrypt long-life archives under quantum-safe key exchange.
Recorded network traffic Confidentiality. TLS and VPN sessions captured in transit. Now This is the classic harvest-now target. Move to hybrid key exchange (X25519 + ML-KEM) on TLS 1.3 and VPN tunnels. Already shipping in OpenSSL 3.5 and at Cloudflare.
Stored sensitive data Confidentiality. Database exports, encrypted email at rest, long-term cloud storage. Now Classify by confidentiality life first. Anything that must stay secret past the early 2030s is in the harvest window today. Prioritise re-encryption by data shelf life, not by volume.
Code signing and firmware Integrity and authenticity. Signatures verifying software and device firmware. At Q-Day Cannot be forged retroactively, so not a harvest risk, but long-lived devices verifying signatures years from now need quantum-safe roots of trust before Q-Day. ML-DSA signing is available in private PKI today (AWS, Microsoft, DigiCert).
Certificate chains (public TLS) Authentication. Server and client identity in public web PKI. At Q-Day Authentication only matters live, so there is no harvest exposure. Public web PKI is the slow lane: browsers and the CA/Browser Forum have not adopted ML-DSA leaf certificates yet. Plan the cutover around that ecosystem step.
Document and transaction signatures Non-repudiation. Signed contracts, audit records, blockchain keys. Mixed A signature’s trust is decided when it is made, so forging it later rarely matters. The exception is permanent public keys (for example on-chain), which sit exposed indefinitely once published.
Symmetric-encrypted data (AES) Largely safe. Only weakened by Grover’s algorithm, not broken. Low Keep AES-256. Move AES-128 up to AES-256 and SHA-256 to SHA-384 for long-life data. This is a key-length adjustment, not a migration.

Source: NIST FIPS 203/204/205; NSA 2021 and UK NCSC on harvest-now-decrypt-later; CA readiness per AWS Private CA, Microsoft AD CS, DigiCert (2025). “Now” = harvestable today. “At Q-Day” = exposed only once a quantum computer exists.

A note on TLS: TLS appears twice because one connection carries two separate risks on two different clocks. The certificate proves server identity, an authentication job that only matters live, so it carries no harvest exposure and sits in the slower public-PKI lane. The session key exchange inside that same connection protects the data in transit, and if the traffic was recorded it is harvestable today. Migrating one does not cover the other: hybrid key exchange protects the session now, while the certificate cutover waits on public-PKI readiness.

Who is actually targeted: harvest-now collection is overwhelmingly a nation-state activity, because it needs bulk interception capability, vast storage, and the patience to wait years. Collectors are selective rather than indiscriminate, prioritising data with multi-year strategic, commercial, or intelligence value, which concentrates the real exposure in defence, diplomacy, critical infrastructure, financial services and healthcare. If your data does not fit that profile, harvest-now is a lower priority for you, and this is where the calculator earns its keep: it tells you which side of that line you sit on.

Knowing what is exposed is half the work. The other half is more reassuring: the migration itself is well within reach, and most of the tooling is already in place.

What post-quantum migration really involves, and what is ready now

"Migrate to post-quantum cryptography" sounds like a moonshot. In practice it is replacing two things and adjusting two more.

The real work is the asymmetric layer that quantum breaks. Key exchange moves from RSA and ECDH to ML-KEM, and signatures move from RSA and ECDSA to ML-DSA, with a hash-based backup in SLH-DSA. The easy part is the symmetric layer, which quantum only weakens: keep AES-256, move AES-128 up to it, and use SHA-384 for long-life data. That is a key-length adjustment, not a migration.

Most coverage skips the correction that matters. The standards are finished, published by NIST in August 2024, and the tooling already ships. Cryptographic inventory and hybrid key exchange work today in OpenSSL 3.5 and at Cloudflare, and ML-DSA certificate issuance is live for private PKI across AWS, Microsoft and DigiCert. The one genuine gap is public web PKI, where browsers and the CA/Browser Forum have not yet adopted ML-DSA leaf certificates. This is less exposing than it sounds. A public TLS certificate proves identity in a live handshake, so its protection is not something an adversary can harvest and break later; the risk only arrives with a quantum computer capable of forging it in real time. That gives the ecosystem room to move, so the public-facing TLS cutover can wait on that step while the harvest-sensitive work, inventory and key exchange, begins now.

The honest blocker, then, is knowing your own cryptography, and that is the first move.

How to use this in a board conversation

The board does not want a quantum lecture. It wants a decision and a number, and the tool manufactures the sentence that delivers both.

The framing is simple: our longest-life secrets need protection to roughly a given year, our migration runs a given number of years, the credible quantum window opens around 2033, therefore this data either clears the line or it does not. From there the sequencing follows the exposure: inventory first, the harvest-now categories first within that, and the public-TLS cutover sequenced around ecosystem readiness rather than rushed ahead of it.

When the pushback comes, and it will be "isn't quantum decades away?", the answer is honest. It might be, and the tool lets you test that exact stance by moving to the conservative setting.

The harvest risk, though, runs on a different clock: protection has to be in place before data is captured, not before Q-Day arrives. For anything that would still be valuable to an adversary in a decade, whether it sits at rest or travels over the wire, the preventative move is quantum-safe encryption now, because once a copy is taken under today's cryptography no later migration can protect it. The aim is to match the effort to the actual exposure: protect what is harvestable today, and schedule the rest.

Summary

The date a quantum computer arrives is unknowable, but the decision about your data is not. Three numbers give you an honest verdict and a clear first move, and tell you whether you are scheduling a programme or fighting a fire.

Run your highest-life data category through the tool, then start the cryptographic inventory. For most organisations the honest answer is calmer than the headlines. For the few it is not, knowing now is the whole point.

This article and the calculator within it are a directional guide, not a substitute for professional advice. The tool gives an indicator from three inputs and makes simplifying assumptions; it cannot weigh every factor in a specific environment. Use it to frame the decision, then seek a qualified expert assessment before acting on it.


References and sources

  • NIST FIPS 203, 204, 205 (post-quantum standards), August 2024 csrc.nist.gov
  • Mosca & Piani, Global Risk Institute Quantum Threat Timeline Report 2024 globalriskinstitute.org
  • NSA, 2021 statement on adversarial data collection
  • UK NCSC, 2023 Annual Review
  • Gidney, "How to factor 2048-bit RSA integers with less than a million noisy qubits," arXiv:2505.15917 (2025, preprint); Gidney & Ekerå, Quantum 5:433 (2021)
  • HNDL targeting and feasibility: "On the Practical Feasibility of Harvest-Now, Decrypt-Later Attacks," arXiv:2603.01091; Cloud Security Alliance Labs, AI Infrastructure Post-Quantum HNDL (2026)
  • CA readiness: AWS Private CA, Microsoft AD CS, DigiCert Trust Lifecycle Manager (2025)