Post-quantum cryptography · Data prioritisation · Migration planning

Which Data Needs PQC First?
Prioritising by Confidentiality Lifetime, Not Visibility

Ayodele (Sodolu) Coker19 October 2026

“We need to go post-quantum” is not a migration plan. It is a direction.

A plan needs priorities. The first question is not simply which cryptographic system is most visible, or which protocol attracts the most attention. It is which information or trust decision must remain protected for the longest—and how long the organisation will need to change the systems around it.

NIST describes harvest now, decrypt later as the risk that an adversary records encrypted data today and waits for a future cryptographically relevant quantum computer to attack the public-key protection. NIST also notes that integrating new algorithms across products and services can take 10 to 20 years. No one knows the exact arrival date of such a quantum computer, so prioritisation should use scenarios rather than pretend that one forecast is certain.

“Protection lifetime, exposure and migration lead time matter more than visibility alone.”

Use the Time Test as a Heuristic, Not a Prediction

A useful planning test is:

required protection period + migration lead time > credible quantum-risk horizon

If that condition could be true under a plausible scenario, the dependency belongs higher in the investigation queue. This is not a countdown and it does not produce a universal deadline. It is a disciplined way to expose where delay could leave data or trust decisions unprotected before migration is complete.

The UK National Cyber Security Centre recommends discovery work that records the data an organisation holds, its expected lifetime, its value to an adversary, and how it is protected in transit and at rest. That is a stronger starting point than sorting systems by how prominent they are.

Separate Confidentiality From Authenticity

Two risks are often mixed together:

Confidentiality risk: encrypted information is captured now and decrypted later after quantum-vulnerable key establishment is broken.
Authenticity and integrity risk: a future attacker forges a signature or defeats a long-lived trust anchor that still has operational value.

Long-lived health, identity, legal, pension, government and intellectual-property records may rank highly because disclosure years later would still cause harm. Root certificates, firmware-signing systems and long-lived document signatures may also rank highly, but for a different reason: future forgery, validation failure or an upgrade path that is difficult to change.

NIST's migration work explicitly identifies both long-term confidentiality and long data-protection periods for signatures. Treating them as separate tracks makes the backlog more precise.

TLS Is Not One Risk Category

“It is not your TLS sessions” is too absolute. A short-lived, low-sensitivity session may be a lower priority than decades of regulated records. But a VPN, administrative channel or application session carrying sensitive information that can be recorded in bulk may be an urgent harvest-now-decrypt-later concern.

Assess the traffic, not just the protocol label:

How sensitive is the information in the session?
How long would disclosure remain harmful?
Can an adversary realistically capture and retain it?
Which public-key algorithm protects key establishment or authentication?
How long will the service, device or supplier take to migrate?

The same protocol can therefore sit in different priority bands in different parts of the estate.

AES-256 Does Not End the Analysis

Symmetric bulk encryption such as AES-256 is not the main algorithm-replacement target of current PQC migration programmes. But “the data uses AES-256” does not prove that the full protection path is ready.

Ask how the encryption key is generated, exchanged, wrapped, exported, backed up and recovered. Data encrypted with AES-256 may still depend on RSA or elliptic-curve cryptography in a key-management service, envelope-encryption workflow, certificate, backup process or recovery path. The public-key dependency—not the bulk cipher label—may be the part that needs migration.

A Practical Priority Order

Start by investigating:

Long-lived, highly sensitive information that is transmitted or otherwise exposed to capture.
Systems that use quantum-vulnerable public-key cryptography and will take years to replace or reconfigure.
Root and signing systems whose signatures or trust decisions must remain valid for long periods.
Archives and backups whose key-wrapping, recovery or re-encryption path is unclear.
Shared platforms whose migration will unblock many dependent services.

Lower-priority work may include short-lived, low-sensitivity data with limited capture value, or well-understood symmetric protection with no hidden quantum-vulnerable public-key dependency. Lower priority does not mean ignored; it means the evidence supports sequencing it later.

One Concrete Step

Build a data-and-dependency matrix with these columns:

Data or service → security property → protection lifetime → exposure path → current cryptographic dependency → migration lead time → owner → next decision

Use four decision labels: act now, prepare dependency, monitor and evidence missing. Do not assign a date to “quantum day.” Instead, test the ranking against more than one horizon and record which assumptions would change the result.

“The entries marked “evidence missing” are not low risk. They are unmeasured risk.”

Which part of your estate has the longest protection lifetime—and is it actually at the top of your cryptographic migration roadmap?

Which Data Needs PQC First?Prioritising by Confidentiality Lifetime, Not Visibility