SOLUTIONS · USE CASE
PQC Migration Planning
PQC migration planning is the work of deciding what to move to post-quantum cryptography, in what order, and on what evidence. Quantum Sentinel supplies the evidence: every cryptographic finding carries a migration priority, a named replacement algorithm, and a risk score weighted by the business importance of the system it sits on. The plan itself stays yours to write.
The near-term deadlines ask for a plan, not a migration
Several jurisdictions have now put post-quantum dates in writing, and the striking thing about the earliest ones is that they do not ask you to migrate anything. They ask you to produce a plan, grounded in an inventory. That is a harder deadline to negotiate than a migration date, because either the document exists or it does not.
| Jurisdiction | What is due, and when |
|---|---|
| United States | A PQC Migration Plan submitted to OMB and ONCD by 22 October 2026 under Executive Order 14412 and OMB Memorandum M-26-15, with post-quantum key establishment for high-value assets by 31 December 2030 and signatures by 31 December 2031 |
| United Kingdom | NCSC: define goals and complete discovery with an initial migration plan by 2028; complete highest-priority migration and refine the roadmap by 2031; finish by 2035 |
| Australia | ASD: a refined transition plan by the end of 2026, transition commenced by the end of 2028 starting with critical systems, complete by the end of 2030 |
| Switzerland | FINMA Guidance 05/2026: a board-adopted strategy with an implementation plan, and a PQC roadmap in place by mid-2027 |
The detail behind each of these is set out in Post-Quantum Deadlines Are Inventory Deadlines, and in our analyses of the NCSC timeline, ASD’s LATICE framework and FINMA’s guidance.
What every one of them expects is the same artefact: a defensible account of what cryptography you run, which parts of it are exposed, and the order in which you intend to deal with them. Plan first, and the migration work becomes schedulable. Migrate first, and you will be asked to justify the order you chose.
What actually decides the order
Sequencing by algorithm alone produces a list that is technically correct and operationally useless: it puts a test server’s RSA key next to the one protecting thirty years of customer records. Four things move a finding up or down the order.
The algorithm, and what replaces it
Every entry is assigned a migration priority of critical, high, medium or low, or marked review when the algorithm is not recognised and none when nothing needs to change. Alongside it sits a named replacement, so the finding arrives with its answer attached rather than a research task.
| What the inventory found | What it recommends |
|---|---|
| RSA | ML-DSA (FIPS 204) for signatures, ML-KEM (FIPS 203) for key establishment |
| ECDSA | ML-DSA-44 or ML-DSA-65 |
| ECDH and EC keys | ML-KEM-768 |
| Diffie-Hellman | ML-KEM-768, or an X25519 and ML-KEM hybrid |
| SHA-1 | SHA-256 as a minimum, SHA-384 for CNSA 2.0 |
| A TLS protocol finding | TLS 1.3 with hybrid ML-KEM key exchange |
| A hardcoded IV or nonce | A freshly generated nonce, flagged explicitly as an implementation defect rather than a post-quantum migration item |
The business importance of what it sits on
The cryptographic score is then weighted by context: asset criticality lifts it by up to 1.4, a production environment by 1.3, external exposure by 1.3, while an air-gapped system is weighted down to 0.8. Both the original score and the factors applied are kept, so a prioritisation decision can be explained months later rather than defended from memory.
How long the data must stay secret
Harvest-now-decrypt-later exposure is recorded as its own field per finding, and reported as its own index. Data with a twenty year confidentiality requirement behind quantum-vulnerable key exchange is a different problem from a session that expires this afternoon, and the order should reflect that.
How close the deadline is
Priorities move on their own as the dates approach. RSA, ECDSA, ECDH and Diffie-Hellman findings step up a tier eighteen months before 31 December 2030 and become critical once it passes; AES-128 and SHA-256 track 31 December 2031. A daily sweep re-applies this across the whole inventory, so an entry discovered last year escalates without waiting for a rescan.
What you take to the board and the regulator
A migration programme is funded by people who will not read a findings table. Reports come out as PDF, CSV and, for most types, DOCX.
- Quantum Readiness Assessment. Structured on a four-stage journey: inventory, assess, migrate and verify, with the proportion of the estate already quantum-safe.
- NIST IR 8547 transition assessment. Frames the estate against the 2035 mandate, the algorithms deprecated after 2030 and disallowed after 2035, and assesses digital signatures against IR 8547’s own tables.
- Executive summary. Percentage quantum-safe, findings needing action, findings on critical assets, and a recommended action per algorithm category.
- Full CBOM report. The inventory itself, for the people who do want the table.
- CSA Migration Readiness. Compares current risk tiers against a snapshot at least thirty days old, and says plainly when no such history exists yet.
Underneath them is a Quantum Risk Index, a single 0 to 100 measure weighted by risk tier, snapshotted daily and served as a trend of up to a year. Days with no scan are shown as gaps rather than interpolated, and reconstructed points are labelled as reconstructed. A trend line that quietly invents its own data is worse than no trend line at all.
Turning priorities into work
Migration work happens in the systems your engineers already use. Quantum Sentinel creates tickets in Jira, ServiceNow ITSM and BMC Helix ITSM, and a scheduled workflow can run a scan and then raise a ticket carrying values from that run, with a CBOM export attached that includes the migration priority and recommended replacement for every entry.
It also reads your service management estate in the other direction: ServiceNow and BMC Helix CMDBs can be synced in to populate assets with criticality, environment, exposure and, for ServiceNow, owner. That is what makes the business weighting above real rather than theoretical, because the context comes from the system of record rather than from a spreadsheet somebody maintained once.
Policy is the other half. A crypto policy can ban named algorithms, TLS versions and cipher suites, set a minimum key size per algorithm, require post-quantum cryptography, and cap certificate validity. Violations are tracked as open, acknowledged or resolved, and compliance is reported both flat and weighted by asset criticality, so a handful of breaches on critical systems cannot hide behind a large compliant estate.
Where the platform stops and your programme starts
This is the section most vendor pages leave out, and the one worth reading twice.
- Quantum Sentinel does not hold your migration plan. There is no plan object, no waves, no target dates, no task owners. What it produces is prioritised, justified, continuously updated evidence. The plan lives in whatever your programme already runs on, and the work lives in your ticketing system. Generating a draft plan from the CBOM and its business context is on the product roadmap; it is not available today.
- Tickets are raised deliberately, not automatically. A person or a workflow decides what becomes a ticket and what it says. Nothing raises a ticket for every critical finding on its own, and ticket status is not read back into the platform.
- Alerts do not route to ITSM. Alert rules deliver to Slack, Teams, email and syslog. Jira and ServiceNow are ticket actions, not alert channels.
- There is no risk-acceptance workflow. A violation is open, acknowledged or resolved. If your governance process needs formal exceptions with expiry dates, that process lives elsewhere.
- Post-migration verification is not tracked. The Quantum Readiness report says so in its own output rather than implying otherwise.
None of this stops a migration programme. It does mean you should expect an evidence platform, not a project management tool, and that is the honest description of what it is today.
Where this sits in the ECEM lifecycle
Enterprise Cryptographic Exposure Management runs as six stages: Discover, Inventory, Assess, Prioritise, Transition and Monitor. Migration planning is the hinge between Prioritise and Transition. It depends entirely on the stages before it, because an order derived from a partial inventory is a guess, and it is judged by the stage after it, because a plan nobody measures against is a document rather than a programme.
In practice that means discovery and planning run together rather than in sequence. You do not need a complete inventory to start planning, but you do need enough of one to be confident about what belongs at the front of the queue. The full model is set out in the Understanding ECEM whitepaper.
Frequently asked questions
What is PQC migration planning?
It is the work of deciding which cryptography to move to post-quantum algorithms, in what order, and with what justification. The decisions that matter are sequencing ones: what goes first, what can wait, and what evidence supports that choice when a regulator or a board asks.
What do the regulators actually require first?
A plan, in most cases, rather than completed migration. US agencies were required to submit a PQC Migration Plan by 22 October 2026, the UK’s NCSC expects discovery and an initial plan by 2028, Australia’s ASD expects a refined transition plan by the end of 2026, and FINMA recommends a PQC roadmap be in place by mid-2027. The migration dates come later: 2030 for Australia, 2035 for the UK.
How does Quantum Sentinel decide what to migrate first?
Each finding gets a migration priority from the algorithm and its risk tier, then that score is weighted by the criticality, environment and exposure of the asset it sits on, flagged separately if it carries harvest-now-decrypt-later exposure, and escalated automatically as the 2030 and 2031 deadlines approach.
Does it tell us what to replace an algorithm with?
Yes. Every entry carries a named recommendation: ML-DSA or ML-KEM for RSA depending on how it is used, ML-DSA-44 or ML-DSA-65 for ECDSA, ML-KEM-768 for ECDH and Diffie-Hellman, SHA-256 or SHA-384 for SHA-1, and TLS 1.3 with hybrid ML-KEM key exchange for protocol findings.
Does Quantum Sentinel produce the migration plan itself?
Not today, and it is worth being precise about this. There is no plan object in the platform: no waves, target dates or task owners. It produces the prioritised evidence a plan is built from, the reports that justify it, and tickets in the systems where the work actually happens. Generating a draft plan from the CBOM and its business context is on the product roadmap, and is not available today.
Can it raise tickets in Jira or ServiceNow?
Yes, in Jira, ServiceNow ITSM and BMC Helix ITSM, and a scheduled workflow can raise one automatically after a scan with a CBOM export attached. Tickets are created deliberately rather than one per finding, and ticket status is not synced back into the platform.
How do we show progress over time?
The Quantum Risk Index is snapshotted daily and available as a trend of up to a year, with gaps shown honestly where no scan ran. Counts of post-quantum algorithms already in use are point-in-time rather than a series, and the CSA Migration Readiness report compares current risk tiers against a snapshot at least thirty days old.
Do we need a complete inventory before planning can start?
You need enough of one to prioritise correctly, not a finished one. Discovery and planning are designed to run together, which matters when the first regulatory deadline is a plan submission and the inventory underneath it is still expanding.
Know what to migrate first.
See your estate ordered by exposure, business impact and deadline. Request a demo.