Harvest Now, Decrypt Later: The Quantum Data Risk Model
A practitioner's risk model for the harvest now, decrypt later threat — how to score quantum data risk by data lifetime, sensitivity, and exposure.
Most quantum security conversations start in the wrong place: with the quantum computer. When will it arrive? How many logical qubits? Will it be 2030 or 2040? These are interesting questions, but they are the wrong ones for a CISO planning the next budget cycle.
The decision that matters is not when a cryptographically relevant quantum computer arrives. It is which of your data must still be confidential when it does — and whether that data is being copied off your network today. That is the harvest now, decrypt later (HNDL) problem, and unlike the arrival date of the quantum computer, it is something you can quantify now.
TL;DR / Key takeaways
- The HNDL threat is already active. Adversaries capture encrypted data today to decrypt it once a quantum computer exists. Your migration deadline is set by your data's lifetime, not the machine's.
- Quantum data risk is a function of three variables: confidentiality lifetime, sensitivity, and current exposure. Volume is almost irrelevant.
- Mosca's inequality proves urgency; a risk model sequences the work. You cannot re-encrypt everything at once, so you must rank.
- NIST finalized the standards in August 2024 (FIPS 203 ML-KEM, FIPS 204 ML-DSA, FIPS 205 SLH-DSA). The blocker is no longer the algorithm — it is discovery and crypto-agility.
- Realistic enterprise migration takes 5-15 years and discovery alone takes 12-24 months. If a data class has a 10-year confidentiality requirement, you are likely already late.
Why the threat model inverts normal security thinking
In most security work, time is on the defender's side. A vulnerability patched before exploitation is a non-event. HNDL breaks that assumption. The attacker does not need to act on your data today; they only need to retain it. The cryptographic break can come a decade later, and the attack still succeeds.
This means a TLS session you consider perfectly secure in 2026 may be a liability in 2034 if the payload contained something with a long confidentiality requirement — a merger term sheet, a patient genome, a signing key, a state secret. The encryption was sound when it was used. The data outlived the algorithm.
The practical consequence: you must protect against a capability that does not yet exist, for data you are transmitting right now. That is why "the quantum computer isn't here yet" is not a reason to wait. It is the precise reason to start.
The three variables of quantum data risk
We score quantum data risk across three axes. None of them is "how much data." A petabyte of expiring session logs is low risk; a single PDF of long-term IP terms is high risk.
1. Confidentiality lifetime
How many years must this data class remain secret? This is the single most important variable, because it determines whether the data's secrecy window overlaps with the quantum era at all.
| Data class | Typical confidentiality lifetime | HNDL relevance |
|---|---|---|
| Session tokens, ephemeral cache | Hours to days | Negligible |
| Operational logs | Months to ~2 years | Low |
| Customer PII (GDPR scope) | 5-10 years | Medium-high |
| Financial contracts, M&A terms | 10-30 years | High |
| Health, genomic, biometric data | Lifetime (50+ years) | Critical |
| Root keys, code-signing keys, CA roots | Effectively permanent | Critical |
| State / classified material | 25-75+ years | Critical |
2. Sensitivity and impact
What happens if this data is disclosed in 2035? Regulatory penalty, competitive loss, physical harm, loss of trust in a root of trust? Health, biometric, and signing-key material score highest because disclosure is irreversible and the blast radius is large — a compromised CA root, for example, undermines everything it ever signed.
3. Current exposure
How exposed is the data to being harvested today? Data crossing public networks, traversing untrusted intermediaries, stored with third parties, or transiting hostile jurisdictions is far more likely to be in someone's capture archive than data that never leaves an air-gapped enclave. This axis is where Zero Trust network design and data-in-transit controls intersect with quantum planning — see our Zero Trust services for how we treat exposure reduction as a near-term mitigation while migration runs.
Mosca's inequality: proving you are already late
Before ranking, prove the urgency. Michele Mosca's inequality is the cleanest framing available:
If X (years the data must stay secret) + Y (years to migrate your cryptography) > Z (years until a cryptographically relevant quantum computer), then you have a problem today.
Worked example for a European enterprise:
| Variable | Value | Basis |
|---|---|---|
| X — confidentiality lifetime | 10 years | Contractual/regulatory requirement |
| Y — migration time | 7 years | Discovery (1-2 yrs) + crypto-agility + rollout |
| Z — quantum arrival (planning assumption) | ~10 years | Conservative industry planning horizon |
| X + Y | 17 years |
Here X + Y (17) far exceeds Z (10). For this data class, the secret should have started migrating years ago. Note that Z is uncertain and you should plan with a conservative value — vendors like Google, Cloudflare, AWS and Microsoft target internal migration around 2029, and NSA's CNSA 2.0 mandates quantum-safe algorithms for new national-security systems by January 2027, full migration 2030-2035. These dates are your calibration points; do not invent your own.
Mosca tells you that you are late. It does not tell you what to do first. That is the job of the risk model.
From scores to a migration sequence
No enterprise can re-encrypt its entire estate simultaneously. The risk model exists to sequence the work. We combine the three axes into a weighted score per data class:
Priority = (Lifetime weight) × (Sensitivity weight) × (Exposure weight)
A simple 1-3 scale on each axis gives a 1-27 priority range that is defensible to a board without false precision.
| Data class | Lifetime | Sensitivity | Exposure | Priority score | Tier |
|---|---|---|---|---|---|
| CA / code-signing roots | 3 | 3 | 2 | 18 | Migrate first |
| Genomic / health records | 3 | 3 | 2 | 18 | Migrate first |
| M&A / long-term contracts | 3 | 3 | 3 | 27 | Migrate first |
| Customer PII | 2 | 2 | 3 | 12 | Migrate next |
| Internal IP documents | 2 | 2 | 2 | 8 | Plan |
| Operational logs | 1 | 1 | 2 | 2 | Defer |
| Session tokens | 1 | 1 | 1 | 1 | Defer |
This ranking is the deliverable executives actually need. It converts an abstract "quantum is coming" anxiety into a defensible, sequenced programme with a clear first move.
In our own delivery work at CC Conceptualise, the most common surprise for clients is not the algorithms — those are now standardized and shipping (Microsoft's SymCrypt added ML-KEM and ML-DSA in late 2024, and Azure Key Vault and Managed HSM PQC support is tracking through 2026). The surprise is how much long-lived, high-sensitivity, high-exposure data is moving across networks today with no record of which keys protect it. The risk model is useless without that inventory.
How this feeds the broader programme
The HNDL risk model is one artefact in a larger post-quantum readiness programme. It sits between discovery and migration:
- Cryptographic discovery produces the inventory of algorithms, keys, certificates and the systems that use them. Without it, your risk scores are guesses. See our guide to cryptographic discovery and inventory.
- The HNDL risk model (this post) ranks data classes by quantum data risk to set migration sequence.
- Crypto-agility re-platforms key management and protocols so algorithms can be swapped without re-architecting — the strategic goal. Our crypto-agility roadmap for enterprises covers the target architecture.
- Platform migration then executes against the priority list, starting with key management. For Azure estates, our Azure Key Vault post-quantum migration walkthrough covers the concrete steps.
A common mistake is to skip straight to step 4 — buying a "quantum-safe" product before knowing what data it should protect first. That produces motion without risk reduction.
What to do in the next 90 days
You do not need a quantum computer to start, and you do not need to boil the ocean. A focused first quarter looks like this:
- Stand up cryptographic discovery for your top three business-critical systems. You are building an inventory, not a perfect map.
- Classify data by confidentiality lifetime. Reuse your existing GDPR data-classification work — most of the inputs already exist.
- Run Mosca's inequality for your two longest-lived data classes to establish urgency for the board in one slide.
- Score and rank those classes with the three-axis model and identify your single highest-priority migration target.
- Reduce exposure now for top-tier data — tighten data-in-transit controls and third-party data sharing while the longer migration runs. This is the one quick win available before any algorithm changes.
- Mandate crypto-agility in all new system designs so you stop adding to the migration backlog.
The organisations that will struggle in 2032 are not the ones whose data was hard to protect. They are the ones who never knew which data needed protecting, or how long it had to last.
FAQ
What is harvest now, decrypt later? Harvest now, decrypt later (HNDL) is an attack strategy where an adversary captures encrypted traffic or data today and stores it, betting that a future cryptographically relevant quantum computer will break the encryption later. The data does not need to be decryptable now — only at some point within its confidentiality lifetime. This makes long-lived secrets the primary concern.
Is the quantum threat real today, or is it hype? No public quantum computer can break RSA-2048 or ECC today, and credible estimates put that capability years away. But the HNDL threat is real now, because data being captured today may still need to stay confidential when such a machine arrives. NIST finalized the post-quantum standards FIPS 203, 204 and 205 in August 2024 precisely because migration must start before the threat materializes.
Which data is actually at risk from HNDL? Data whose required confidentiality lifetime overlaps with the expected arrival of a cryptographically relevant quantum computer. State secrets, intellectual property, genomic and health records, long-term financial contracts, and root key material can all need protection for decades. Short-lived session tokens or ephemeral data are low risk. The deciding factor is data lifetime, not data volume.
How do I quantify quantum data risk? Score each data class on three axes: confidentiality lifetime in years, sensitivity or impact of disclosure, and current exposure to interception or storage by third parties. Data with long lifetime, high sensitivity, and high exposure is your migration priority. We use a simple weighted matrix to rank data classes before touching any cryptography.
What is the difference between Mosca's inequality and a risk model? Mosca's inequality is a timing test: if the time data must stay secret plus the time to migrate exceeds the time until a quantum computer arrives, you are already late. A risk model extends this by prioritizing which data and systems to migrate first, since no organisation can re-encrypt everything at once. Use Mosca to prove urgency, then the risk model to sequence the work.
What should an enterprise do first about HNDL? Start with cryptographic discovery to build an inventory of where and how you use cryptography, then classify your data by confidentiality lifetime. Those two inputs feed the risk model that tells you what to migrate first. Crypto-agility — the ability to swap algorithms without re-architecting — is the strategic end state, not a single product purchase.
Quantifying quantum data risk is the difference between a panic project and a programme. If you want help building the inventory, the risk model, and the migration sequence for your estate, our Zero Trust and cybersecurity practice has delivered exactly this for European enterprises. We are happy to start with a focused discovery sprint rather than a sales pitch.
Topics