PQC_Migration_Planning

Part 5: Planning Your PQC Migration Journey

/ PQC (Post-Quantum Cryptography) / By

TL;DR

Earlier in this series we covered why PQC matters (Parts 1 to 3) and how to see your cryptography with a Cryptographic Bill of Materials (CBOM) (Part 4). An inventory on its own changes nothing. This article explains how to turn it into a PQC migration plan: who owns it, what moves first, how fast, and how you prove progress.
The short version: set governance and scope, rank systems by data shelf-life and migration effort (Mosca’s inequality), sort them into risk tiers, plan hybrid-first with key establishment ahead of signatures, bring suppliers into the plan early, and align milestones with the UK, EU and US timelines. Part 6 then covers the tools to execute it.

Sinevis point of view (what a good plan does)

  1. It is driven by the inventory, not by vendor marketing: every priority traces back to a CBOM entry.

  2. It ranks by time, not just severity: how long the data must stay secret and how long the system will take to change.

  3. It sequences hybrid-first (classical plus PQC) so interoperability and rollback are preserved.

  4. It treats suppliers as part of the critical path, because most of your cryptography arrives inside products you buy.

  5. It builds crypto-agility in, so the next algorithm change is a configuration change, not another programme.

A programme, not a project: scoping and governance

PQC migration will run for years and cross every business unit, so it needs the same governance as any other enterprise risk programme. The US Office of Management and Budget makes the point directly in M-26-15 (24 June 2026): migration is not only the responsibility of the CIO and CISO, and every member of the leadership team needs defined accountability. That applies equally outside government.

  1. Sponsor and owner: a named executive sponsor and a single accountable programme owner, reporting to the risk or audit committee.

  2. Scope: decide what is in (internal IT, cloud, OT/IoT, products you ship, customer-facing channels) and what is explicitly deferred, with a reason.

  3. Roles: architecture, PKI and key management, application owners, procurement, legal and supplier management, each with clear responsibilities.

  4. Policy hooks: a cryptography standard that names approved algorithms (FIPS 203 ML-KEM, FIPS 204 ML-DSA, FIPS 205 SLH-DSA), hybrid-first rules and exception handling.

  5. Funding model: where possible, fold PQC into planned cloud migrations, application releases and hardware refresh cycles rather than funding it as a standalone project. OMB M-26-15 asks agencies to do exactly this to minimise cost.

Our Post-Quantum Cyber Readiness service uses this structure as the starting point for every plan.

Building the plan in six steps

Step 1. Set goals, scope and success criteria

  • Goals: the UK NCSC asks organisations to define migration goals as their first milestone. Write them as outcomes, for example “no long-lived confidential data protected only by quantum-vulnerable key exchange on external channels by a set date”.

  • Target dates: anchor your internal dates to the external ones that apply to you (see the regulatory clock below), then add margin. NIST notes that previous cryptographic transitions have taken 10 to 20 years.

  • Deliverables: a one-page programme charter, a scope statement and an agreed set of KPIs.

Step 2. Start from the inventory

  • Input: the CBOM from Part 4, covering algorithms, key sizes, protocols, certificates, keystores, libraries and signing flows.

  • Add business context to each entry: owning service, business criticality, the data it protects, how long that data must stay confidential, whether you or a supplier control the cryptography, and the system’s next planned change or refresh date.

  • Keep it live: a one-off spreadsheet is out of date within a quarter. OMB M-26-15 calls automation critical for inventory, policy enforcement and compliance reporting.

Platforms such as Quantum Sentinel, an Enterprise Cryptographic Exposure Management platform, provide PQC discovery, an enterprise CBOM, exposure assessment and migration planning using read-only collection of cryptographic metadata, which gives the plan a continuously updated base.

Step 3. Prioritise with data shelf-life and Mosca’s inequality

Michele Mosca’s widely used test (IEEE Security & Privacy, 2018) compares three numbers for each system:

  • x: how many years the data must remain secure (its shelf-life);

  • y: how many years it will take to migrate the system;

  • z: how many years until a cryptographically relevant quantum computer exists.

If x + y > z, data captured today could be exposed within its useful life (“harvest now, decrypt later”). Nobody knows z precisely, so use a range taken from expert surveys such as the Global Risk Institute’s annual Quantum Threat Timeline Report, and test the plan against the pessimistic end. In practice, x and y are the numbers you control: a system holding 15-year confidential records that needs five years to change is already urgent under any plausible z.

Sinevis tip: estimate y honestly. Embedded devices, partner-facing protocols and anything needing a hardware change usually take far longer than the application team expects.

Step 4. Assign risk tiers and a migration pattern

  • Tier 1 (migrate first): long-lived confidential data, internet-facing key exchange, high-impact systems and the PKI that underpins access control. OMB M-26-15 uses a similar cut: high-impact systems, high value assets, PKI-based logical access, and systems holding data still sensitive in 2030.

  • Tier 2: internal service-to-service traffic, code and firmware signing roots, and systems with medium data shelf-life.

  • Tier 3: short-lived data and systems due for retirement before 2035.

Then give each system one pattern: upgrade in place (library or configuration change), hybrid via proxy or gateway where the application cannot change quickly, replace through procurement, or retire. NIST IR 8547 and OMB M-26-15 both say systems that cannot support PQC should be identified and prioritised for replacement or decommissioning.

Step 5. Map supplier and third-party dependencies

  • Tag every CBOM entry with who controls the cryptography: you, a software vendor, a cloud or SaaS provider, a hardware maker or a counterparty.

  • Ask for dated roadmaps: which PQC algorithms, in which product versions, by when, with hybrid support and a rollback path.

  • Use contracts and procurement: add PQC and crypto-agility clauses to renewals. CISA’s list of product categories where PQC-capable products are widely available (January 2026) is a useful baseline for what to require now.

  • Cloud shared responsibility: agree in writing which side migrates which layer, as OMB M-26-15 asks agencies to do with their cloud providers.

Supplier dates often become your critical path, so record them as plan dependencies, not footnotes.

Step 6. Design for crypto-agility

  • Configuration, not code: algorithm and parameter choices should live in configuration and central libraries, so they can change without rewriting applications.

  • Plan for more change: NIST is still developing FN-DSA (FIPS 206) and an HQC key-encapsulation standard as of October 2026, and the IETF continues to standardise PQC for protocols. Your plan should absorb these without a restart.

  • Automate certificate lifecycle: public TLS certificate lifetimes fall to 200 days from March 2026 and 47 days by March 2029 under the CA/Browser Forum’s ballot SC-081v3, so automation is needed regardless of PQC and is the foundation for PQC certificate profiles.

  • Gate new work: add PQC and agility checks to architecture review, SDLC and procurement so the inventory stops growing in the wrong direction.

The regulatory clock (as at October 2026)

United Kingdom

  • The NCSC’s PQC migration timelines (20 March 2025) set three milestones: by 2028 define goals, complete discovery and build an initial plan; by 2031 complete the highest-priority migrations and refine the roadmap; by 2035 complete migration of all systems, services and products.

European Union

  • The Coordinated Implementation Roadmap (23 June 2025), addressed to Member States, calls for first steps such as inventories and national plans by 31 December 2026, migration of high-risk use cases by 31 December 2030, and medium-risk use cases as far as feasible by 31 December 2035. Expect national authorities and sector regulators to pass these expectations on to operators.

United States

  • Executive Order 14412, Securing the Nation Against Advanced Cryptographic Attacks (22 June 2026), and OMB M-26-15 (24 June 2026) required federal agencies to submit PQC migration plans within 120 days (by 22 October 2026, now passed). High-impact systems and high value assets must use PQC for key establishment by 31 December 2030 and for digital signatures by 31 December 2031, with full migration by 2035 and TLS 1.3 support by 2 January 2030.

  • NIST IR 8547, finalised on 27 October 2026, deprecates all quantum-vulnerable public-key algorithms (RSA, ECDSA, EdDSA, DH, ECDH) after 2030 and disallows them under NIST standards after 2035. The 2024 draft had limited the 2030 deprecation to 112-bit strength; the final version brings RSA-3072 and P-256 into it too.

US federal rules bind agencies, but suppliers to government, regulated firms and anyone using FIPS-validated products will feel them. For most multinational organisations the practical planning envelope is: discovery and plan done by 2027 to 2028, priority key establishment migrated by 2030, signatures by 2031, everything by 2035.

Hybrid-first sequencing: what moves first

1. Key establishment before signatures.
“Harvest now, decrypt later” threatens confidentiality today, so key exchange on channels carrying long-lived data comes first. Signature forgery only becomes possible once a quantum computer exists, which is why OMB M-26-15 sets signatures a year later than key establishment.

2. External before internal.
Internet-facing TLS, VPNs and partner links are the easiest traffic to capture. Hybrid key exchange (classical plus ML-KEM, standardised for TLS 1.3 in RFC 10024 in 2026) protects against both classical and quantum attack while keeping compatibility.

3. Plan long-lived trust anchors early.
Root CAs, firmware and code-signing roots and secure boot keys can take years to replace across a device fleet, so their migration plans must start now even if cutover comes later.

4. Keep rollback until evidence says otherwise.
Hybrid gives you a safe path back to classical-only while you measure performance and interoperability.

A phased roadmap (reference)

Phase 1: Mobilise and discover (now to 2027)

  • Governance, charter, scope and KPIs agreed.

  • CBOM for Tier-1 services, enriched with shelf-life and ownership.

  • Supplier questionnaire issued; dated roadmaps requested.

Phase 2: Pilot and early migration (2027 to 2028)

  • Hybrid key exchange piloted on one external channel; one signing path tested.

  • Certificate lifecycle automation in place for priority estates.

  • Plan refined from pilot evidence; NCSC 2028 milestone met.

Phase 3: Prioritised migration (2028 to 2030)

  • Tier-1 key establishment migrated; legacy systems replaced or isolated.

Phase 4: Signatures and Tier 2 (2030 to 2031)

  • PQC signatures for priority PKI, code and firmware; Tier-2 traffic migrated.

Phase 5: Complete and operate (to 2035)

  • Remaining systems migrated or retired; quantum-vulnerable algorithms removed; crypto-agility run as business as usual.

These phases mirror the structure of OMB M-26-15 and the NCSC milestones; adjust them to your own risk tiers and supplier dates.

KPIs that show the plan is working

  • Inventory coverage: % of Tier-1 services with a complete, current CBOM entry.

  • Risk exposure: number of systems where x + y > z under your pessimistic estimate, trending down.

  • Key establishment: % of external traffic negotiating hybrid or PQC key exchange.

  • Signatures: % of signing roots and code-signing paths with a tested PQC plan.

  • Supplier alignment: % of strategic suppliers with a dated PQC roadmap.

  • Agility: % of certificates under automated lifecycle; % of applications using centrally configured cryptography.

Report them quarterly to the same committee that owns the programme.

Common planning pitfalls

  • Planning without an inventory: priorities based on guesses collapse at the first audit.

  • Treating it as an IT project: without business owners, shelf-life decisions never get made.

  • Waiting for suppliers: ask now, contract now; dates you never requested will not arrive.

  • Funding it separately: a standalone budget invites deferral; tie it to refresh and release cycles.

  • Ignoring signatures until 2030: trust anchors and device fleets need years of lead time.

  • Treating 2035 as the deadline: for long-lived data, the deadline is set by x + y, not by the calendar.

From plan to execution, and how Sinevis helps

A plan is only useful if it can be executed. Part 6: Tools and Frameworks for Post-Quantum Readiness picks up here, with the tools, pilot patterns, PKI automation and runbooks that turn each phase into delivered change.

Sinevis supports organisations across the planning stage:

  • PQC readiness assessment: CBOM-driven discovery and prioritisation using shelf-life and Mosca-style analysis.

  • Roadmap and governance: risk tiers, phased roadmap aligned to NCSC, EU and US timelines, and board KPIs.

  • PQC in the supply chain: supplier questionnaires, dated roadmap tracking and contract clauses.

  • Keys and certificates: certificate lifecycle management, encryption and HSM planning as an authorised Thales service partner.

Talk to us about building your plan, or run a quick external check with our PQC Compliance Check.

Final Thought:

The quantum transition rewards organisations that plan early and honestly. Start from the inventory, rank by how long your data must stay secret and how long change really takes, bring suppliers in from day one, and build agility so this is the last cryptographic programme you have to run from scratch.

Sources

Our Post-Quantum Readiness Series

This article is Part 5 of our Post-Quantum Cyber Readiness Series, which explains the quantum transition in practical terms.

The series so far:

Each article equips CEOs, CISOs, IT leaders and architects with the knowledge and tools to navigate the quantum transition with confidence. For our latest status update, see PQC migration readiness in 2026.

Try our PQC Compliance Check tool for Websites

Free PQC Compliance Check
pqc_compliance_check_tool