Post-Quantum Cryptography Migration Roadmap: Sequencing the Work Against Dated Deadlines

A roadmap is an ordered plan, not a longer report

Most organizations approaching the post-quantum transition do not lack awareness of it. What they lack is an answer to a narrower question: *given finite engineering time, what do we change first?*

That is the only question a migration roadmap exists to answer. It is not a survey of the threat landscape and not a restatement of the standards. Every line in a roadmap carries two things a report does not: a position in a sequence, and a reason for that position. Strip either one out and you are back to a list of things that are all, unhelpfully, important.

The reason matters as much as the order. A sequence nobody can justify gets renegotiated in the first planning meeting that runs short on capacity. A sequence where each position traces back to how exposed a system is and how long its secrets must stay confidential survives that meeting.

Where the roadmap comes from: inventory, then risk score

A roadmap is the output of an assessment, not a substitute for one. Two steps come first, and both constrain what the roadmap can honestly say.

Cryptographic inventory. Locating where and how cryptography is used across systems — the algorithms in use, their key sizes, the protocols carrying them, certificate lifetimes, and what depends on each. You cannot sequence what you have not located. An inventory with gaps produces a roadmap with silent omissions, and those omissions are indistinguishable from completed work when someone reads the plan a year later.

Five-axis quantum risk scoring. A flat inventory implies everything carries equal weight, which is never true: a deprecated algorithm protecting a short-lived internal session is a different problem from the same algorithm protecting records that must stay confidential for a decade. Q-Shield scores quantum risk on five axes (a five-axis QRS) so the highest-risk, longest-lived secrets surface first.

If you are still at that stage, the PQC readiness assessment page covers the diagnostic in full. This page picks up where the score leaves off — with ranked findings that now need an order and a calendar.

The dates the sequence is anchored to

Sequencing is only meaningful against fixed points. Four are published and dated:

• NIST IR 8547 deprecates RSA-2048 and ECC P-256 in 2030 and disallows them after 2035.
• U.S. federal guidance targets high-priority, harvest-exposed systems by the end of 2031, and all remaining systems by the end of 2035.
• CNSA 2.0 sets a 2027 timeline for U.S. national security systems.
• FIPS 140-2 validation sunsets in September 2026.

Which of these apply to a given organization varies, and the roadmap should record which track each system falls under rather than assuming a single deadline governs everything. What the dates have in common is that they are published rather than forecast — that is precisely what makes them usable as anchors, and why a roadmap can be sequenced against them while the arrival of quantum capability itself remains open.

Note also what the dates do *not* say. Deprecation in 2030 is not the date work should begin; it is the date the classical algorithms stop being acceptable for new use. Working backwards from a disallow date through procurement, testing, and staged rollout is normally where organizations discover their real start date has already passed.

How the sequence gets ordered

With ranked findings and dated anchors, ordering follows from a small number of rules that can be stated plainly enough for anyone to challenge them:

1. Longest confidentiality lifetime, earliest. Data that must stay confidential well past the migration window is exposed to harvest now, decrypt later — an adversary can capture encrypted traffic today and decrypt it once a sufficiently capable quantum computer exists. For those systems the effective deadline is not a published date; it is now.

2. Hardest deadline next. Systems on the tightest published track — national security systems under CNSA 2.0, for instance — move ahead of systems whose disallow date is 2035.

3. Dependency order over risk order where they conflict. A certificate authority, a key management service, or a shared library that other systems inherit from has to move before its dependents, even if a dependent scores higher in isolation. Risk ranking sets priority; dependencies set feasibility.

4. Shortest-lived credentials as natural early wins. Systems whose keys and certificates already rotate frequently can absorb an algorithm change with less disruption, which makes them useful for establishing the process before it meets the harder cases.

Rules 1 and 2 come from the score and the calendar. Rules 3 and 4 come from how the work actually lands in an engineering organization, and they are the reason a raw risk ranking is not yet a roadmap.

What each item in the roadmap specifies

An entry that says "migrate to post-quantum" is not actionable. A usable entry names the target and the transition path.

The target for key establishment is ML-KEM, standardized as FIPS 203. Q-Shield produces a NIST-aligned migration roadmap toward it, including a hybrid ECDH + ML-KEM key exchange where that fits — retaining the classical algorithm's established assurance alongside the post-quantum one through the transition period.

Whether a given system takes the hybrid route or moves directly is a per-system decision, driven by what the system's peers support, how long it must interoperate with unmigrated counterparties, and what its protocol stack permits. The roadmap records that choice per entry rather than applying one policy across everything. Systems that cannot yet move at all — an appliance whose vendor has not shipped support, for example — belong in the roadmap as explicitly blocked items with the blocking condition named, not omitted because they are inconvenient.

What a roadmap does not do

Being clear about the boundary is what keeps the plan trustworthy:

• It does not execute the migration. Q-Shield locates, scores, and sequences. Changing configurations, reissuing certificates, updating libraries, and testing interoperability stay with your engineering teams.
• It does not establish compliance. A roadmap can be organized around published deadlines and still not constitute an attestation. Whether a given system meets a given obligation is determined by the body that sets it, not by a planning artifact.
• It does not survive contact unchanged. Vendor support arrives, dependencies shift, and inventory findings turn up late. A roadmap's value is in being re-sequenced as those change, which is only possible when each position has a stated reason.
• It does not depend on predicting Q-Day. More on that below.

Q-Day stays open — and the roadmap does not need it

The arrival of a cryptographically relevant quantum computer able to run Shor's algorithm is genuinely uncertain and debated among researchers. No authoritative date exists, and it should be treated as an open question rather than a countdown.

A roadmap does not require that date, and any roadmap that leans on one is built on a forecast rather than a fact. Its sequence is driven entirely by things already established: the published deadlines above, and the fact that long-lived data is exposed to harvest now, decrypt later irrespective of when quantum capability arrives. Planning against what is known is the point of the exercise — the uncertainty about Q-Day is an argument for ordering the work sensibly, not for treating any particular year as a deadline.

From ranked findings to a sequence you can defend

The chain is short and each link constrains the next: an inventory establishes what exists, a five-axis quantum risk score ranks it by exposure and confidentiality lifetime, and the roadmap turns that ranking into an order anchored to dated deadlines and adjusted for dependencies. What comes out is a plan whose every position can be traced back to a reason — which is what lets it hold up when engineering capacity gets scarce.