Harvest now, decrypt later: the board-level case

A TLS session captured this year does not have to be broken this year. If the ciphertext is worth keeping, an adversary can store it and wait for a cryptographically relevant quantum computer to make the key exchange recoverable. The mechanism is that simple, and it is why the useful planning question is not when quantum hardware arrives.

Harvest now, decrypt later converts a future capability into a present exposure. For a specific set of data classes, it means the confidentiality you believe you are providing today is already contingent on an assumption that will expire.

The exposure is the gap between shelf life and capability

For any data class, the exposure is roughly the time until decryption becomes feasible minus the time the data must remain confidential. If the requirement outlasts the capability, the data is exposed now, regardless of when the capability actually appears.

That is why data with a ten-to-fifteen-year confidentiality requirement can reasonably be treated as already exposed. It is also why the argument “we will migrate when the hardware is closer” fails for that data. The migration date is not the protection date. The protection date is when the data is encrypted with something the adversary cannot store and break.

Three variables you can actually measure

Precision about physics is unavailable. Precision about your own estate is not. Three variables carry most of the decision.

Variable	The question	Where the answer lives
Confidentiality lifetime	How long must this stay secret after it is captured?	Retention schedule, contracts, regulation, competitive value
Adversary access	Can anyone observe this traffic or storage today?	Network path analysis, peering points, third-party processors
Asset reachability	Which systems carry that data on observable paths?	CBOM joined to flow logs and data classification

Lifetime is a records-management question, not a security question, which is why security teams often cannot answer it alone. Access is a network question, and the honest answer frequently includes paths you do not control: a partner’s mirror, a cloud egress, a backup replicated to a second region, a shared peering exchange.

Reachability is what a CBOM gives you. It turns “we encrypt data in transit” into “these four services carry class A data over paths an observer can see,” which is a statement you can schedule work against.

“When will the quantum computer arrive” is the wrong question

It is the wrong question for three reasons. It has no answer anyone can defend. It invites the response “later,” which is a decision to accept exposure by default. And it puts the discussion in the hands of people who study hardware rather than people who own data.

The right question is: what must still be secret after a quantum computer exists, and for how long after. That version has an owner, an evidence trail, and a budget line. It also has an uncomfortable property: it can be answered today, which removes the excuse for not answering it.

You do not need to predict the arrival date. You need to bound the confidentiality requirement. If you cannot bound it, the conservative planning assumption is that the class is exposed.

A scoring approach you can run this month

Score each data class on three factors, then multiply. The numbers are a ranking device, not a prediction.

Factor	1	3	5
Lifetime	Under one year	Three to seven years	More than fifteen years
Access	No plausible capture path	Targeted passive collection plausible	Known tap, compromised path, or data already retained by a third party
Reachability	One isolated system	Several internal systems	Internet-facing and shared with third parties

The product runs from 1 to 125. Treat anything above roughly 45 as a candidate for immediate key establishment migration, and anything above 75 as a candidate for treating the data as already exposed in risk reporting.

Two rules keep the model honest. First, never let the score be the only artifact: attach the evidence for each factor, or the next reviewer will treat the number as arbitrary. Second, keep the scale stable across cycles. A scoring model that changes every quarter cannot show progress.

A worked example, with hypothetical data

The data classes below are hypothetical and the scores are illustrative. The point is the ordering, not the numbers.

Data class	Lifetime	Access	Reachability	Score	Reading
Clinical trial records	5	4	3	60	Migrate key establishment first
M&A data room	3	5	4	60	Treat as exposed during the deal
Source code repositories	5	3	3	45	Migrate with developer platform
Payment authorizations	2	3	5	30	Short retention lowers urgency
Device telemetry	1	2	5	10	Schedule with normal refresh

The ordering surprises executives in a useful way. Payment data usually has a compliance budget and an owner, yet it ranks below clinical records and the deal room because the retention period is short. The data that hurts most is not the data with the most regulation attached. It is the data that has to stay secret the longest.

What the board is actually deciding

Boards do not need lattice mathematics. They need three decisions, each answerable in a sentence.

First, which data classes do we treat as already exposed? That is a risk acceptance decision, and it belongs in the risk register next to breach exposure and third-party concentration.

Second, by what date will each of those classes be protected by post-quantum key establishment, and what resourcing does that date require? Under Executive Order 14412, agencies must reach that point for high-value assets and high-impact systems by December 31, 2030, which is earlier than most ten-year confidentiality requirements suggest.

Third, who owns the answer, and what evidence will they produce? A named owner with a CBOM extract and a dated migration plan is a governance answer. A working group with a charter is not.

The framing that tends to land is that harvest now, decrypt later is a retention problem with an adversary. Every organization already understands that keeping data longer increases liability. This is the same argument, with the additional feature that the liability began at capture rather than at breach.

Where the argument stops being theoretical

Three signals indicate a class is no longer theoretical. The data crosses a network segment you do not own. The confidentiality requirement exceeds the refresh cycle of the cryptography protecting it. Or a third party already holds a copy under a contract you cannot renegotiate quickly.

Any one of those is enough to move a class into the migration plan. All three together usually mean the decision has already been made by someone else.