Post-quantum readiness starts with how long your data must stay secret

Two different risks in one programme

Post-quantum migration is usually discussed as a single problem, which obscures the fact that it contains two risks with different urgency and different solutions.

The first is retrospective decryption. An adversary records encrypted traffic or acquires encrypted data today, stores it, and decrypts it once a sufficiently capable quantum computer exists. The exposure is created at the moment of capture, which means it is being created now for any data protected by classical public-key key establishment.

The second is forgery and impersonation. Once such a machine exists, an adversary can forge signatures and impersonate parties whose authentication rests on classical public-key cryptography. This risk begins when the capability exists, not before—a signature verified today cannot be retrospectively forged.

The distinction matters because it produces different priorities. For confidentiality, the question is how long your data must stay secret. For authentication, the question is how hard your verifiers are to update. A programme that treats both as one item tends to sequence by ease rather than by exposure.

The question that sequences the work

For any system carrying data, ask one question: if this traffic were recorded today and decrypted in fifteen years, would it matter?

The answers separate cleanly in most organisations:

Data	Secrecy requirement	Retrospective exposure
Session tokens, cache contents, transient API traffic	Days	None meaningful
Commercial pricing, current negotiations	Months to a few years	Limited
Customer personal data, employment records	Decades	Significant
Health records, genetic data	Lifetime and beyond	Significant
Legal privilege, litigation material	Decades	Significant
Intellectual property, formulations, designs	Product lifetime, often decades	Significant
State and defence material	Decades	Significant
Long-lived credentials and root key material	Until rotated, often years	Significant

The top rows are the majority of network traffic by volume and carry almost no retrospective risk. The lower rows are a much smaller proportion and are where early action is warranted. This is a far more useful prioritisation than working through systems by size or by team.

Work out your own exposure window

The reason data lifetime is the right axis is that it lets you reason without knowing when a capable quantum computer will exist—a date nobody knows.

The standard formulation adds three durations: the time your data must remain confidential, plus the time your migration will take, compared against the time until the capability exists. If the first two together exceed the third, data you protect today is exposed.

Since the third term is unknown, the practical use of this is to establish which of your systems is sensitive to it. A system whose data must stay secret for two years is insensitive to any plausible estimate. A system whose data must stay secret for thirty years is exposed under every estimate. The systems in between are where the estimate matters, and they are a smaller set than the whole estate.

Migration duration is the term organisations underestimate, and it is the one they control. A protocol change that requires a counterparty to upgrade takes years regardless of engineering capacity. ENISA’s integration study is useful on this point: the difficulty is concentrated in integration and protocol work rather than in the primitives themselves.

What actually carries retrospective risk

It is worth being precise, because the risk is narrower than general discussion implies.

Retrospective decryption applies where confidentiality depends on public-key key establishment over a channel an adversary can record or where the key material is stored. In practice:

• TLS and VPN sessions carrying long-lived sensitive data across networks an adversary can observe;
• data encrypted to a recipient’s public key and stored—encrypted backups, archived messages, escrowed material;
• key material wrapped with a public-key scheme and retained;
• long-term document encryption.

It does not apply to data protected only by symmetric encryption with a key that was never transported using public-key cryptography, because symmetric algorithms with adequate key sizes are not broken by the same attack. A database encrypted with a symmetric key held in a hardware module, where the key never crossed a network under public-key protection, is not exposed to harvest-now-decrypt-later. That observation removes a significant amount of anxiety from most inventories.

The standardised key encapsulation mechanism in FIPS 203 is the replacement for the exposed case, and it is available in mainstream libraries and platforms now.

The dates you are being measured against

The published timelines have converged enough to plan against, and they are the basis on which customers and regulators will ask questions.

The UK’s migration timelines guidance asks organisations to complete discovery and a migration plan by 2028, execute the highest-priority migrations by 2031, and complete migration by 2035. NIST’s transition guidance sets out deprecation of classical public-key algorithms around 2030 with disallowance around 2035. The joint quantum-readiness guidance sets the same expectation for inventory-led planning.

Read these as a procurement forecast as well as a security one. An organisation selling into regulated sectors should expect the question “what is your post-quantum plan?” in due-diligence questionnaires well before the deadlines, and the answer that satisfies it is an inventory with owners and dates rather than a statement of intent.

What to do in the next two quarters

Four actions are useful now and none of them require waiting for anything.

First, inventory the systems in the lower rows of that table—the ones whose data must stay secret for a decade or more—and record for each one where key establishment happens and who owns changing it.

Second, write the protection-lifetime requirement down as a business decision. Engineering cannot determine how long a health record must stay confidential; the data owner can, and without it the prioritisation has no input.

Third, raise the migration question in contracts and interface roadmaps with counterparties, because these have the longest lead times. A partner integration that needs to change in 2029 needs to be on the agenda in 2026.

Fourth, add the agility provisions: algorithm identifiers in stored formats, negotiated parameters in configuration rather than code, and telemetry on what is actually negotiated. These reduce the cost of every subsequent step and are worth doing whatever the timeline turns out to be.

What not to do

Three tempting responses waste effort.

Do not migrate everything at once. Most traffic carries no retrospective risk, and a uniform programme spends its budget on the systems that did not need it while the long-lead items remain untouched.

Do not adopt a non-standardised scheme because it appeared promising. The history of the standardisation process includes candidates broken late, and the value of a standard is that it has survived concentrated attack. Use the standardised algorithms, in hybrid combination with a classical scheme where the protocol supports it.

Do not treat this as a cryptography project. The work is inventory, ownership, contracts, protocol negotiation and release capability. The cryptographic content is a handful of decisions, most of which the standards have already made.