PQC Migration Roadmap: A Phase-by-Phase Guide for Enterprise Security Teams

Canada's federal departments face a mandated milestone on April 1, 2026 under the Government of Canada's ITSM.40001 post-quantum cryptography roadmap: deliver an initial departmental PQC migration plan and begin annual progress reporting. That deadline is an administrative compliance event arriving within weeks, not a planning horizon. For enterprise security and risk leaders outside Canada, the operational lesson is identical. The UK's National Cyber Security Centre has structured its own migration programme around 2028, 2031, and 2035 target dates that require active cryptographic inventory work beginning now, not at the next planning cycle.

This PQC migration roadmap turns those government timelines into an internal framework your security organisation can execute against — what to complete this quarter, what to finish by 2028, and how to land full compliance by 2035.

Why 2028, 2031, and 2035 keep showing up

• 2028 — discovery, assessment, and initial migration plan complete (UK NCSC target)
• 2031 — highest-priority migrations complete, infrastructure ready for PQC at scale (UK NCSC and Government of Canada)
• 2035 — full PQC migration for all systems, services, and products (UK NCSC and Government of Canada); RSA and ECC proposed to be disallowed from NIST standards (NIST IR 8547 IPD)

Why Regulatory Timelines Should Drive Your PQC Migration

Two national frameworks provide the most detailed phase-by-phase migration timelines currently available to enterprise security teams: the UK NCSC's March 2025 guidance and the Government of Canada's ITSM.40001 roadmap. Both converge on the same structural logic — discovery and planning by 2028, high-priority system migration by 2031, full adoption by 2035 — but they differ in their immediate triggers.

The UK NCSC's Timelines for migration to post-quantum cryptography (published 19 March 2025) sets 2028 as the target date by which organisations should complete discovery and assessment and produce an initial migration plan. The 2031 target is to complete highest-priority migration activities to protect critical assets and ready infrastructure for PQC at scale. The 2035 target is to complete migration to PQC for all systems, services, and products. NCSC explicitly describes these as target dates and indicative timelines, not statutory mandates — but for regulated sectors and government-supplier relationships, they function as de facto floors.

The Canadian framework mirrors this structure with harder compliance edges for federal departments. ITSM.40001 requires an initial departmental PQC migration plan by April 1, 2026, annual progress reporting thereafter, completion of high-priority system migration by end of 2031, and completion of migration for remaining systems by end of 2035.

In the United States, NIST IR 8547 — currently an initial public draft published November 2024 — proposes a parallel transition timeline. The draft proposes that commonly used RSA and ECC public-key schemes at roughly 112- and 128-bit security levels (RSA-2048, P-256) be deprecated by 2030 (no new deployments) and disallowed by 2035 (removed as approved options in NIST cryptographic standards). These are distinct states in NIST's transition model, not a single deadline — a distinction that matters for audit and procurement language.

NIST's National Cybersecurity Center of Excellence has further published NIST Cybersecurity White Paper (CSWP) 48, Mappings of Migration to PQC Project Capabilities to Risk Framework Documents (initial public draft, September 2025), which maps PQC migration capabilities to NIST Cybersecurity Framework 2.0 outcomes and SP 800-53 security and privacy controls. This gives security architects a structured control-mapping methodology for translating their internal programme into frameworks auditors already use.

The 2028 / 2031 / 2035 Migration Frame

For CISOs building an internal business case, this frame is the most defensible rationale for investment sequencing. A phased programme aligned to 2028/2031/2035 maps directly to planning cycles, budget requests, and audit evidence requirements.

The PQC Migration Roadmap: A Phase-by-Phase Framework

What follows is a three-phase PQC migration roadmap that translates the 2028/2031/2035 frame into executable programme phases. Each phase has defined inputs, defined deliverables, and named ownership — designed to slot into your existing programme management office rather than running as a parallel structure.

Phase 1 (Now–2028): Discovery, Inventory, and Cryptographic Risk Assessment

Every subsequent migration phase depends entirely on what you produce in Phase 1. Without a comprehensive cryptographic inventory, prioritisation is arbitrary and risk assessment is impossible. A PQC migration roadmap is only as credible as the cryptographic asset register behind it.

Discovery activities

A Phase 1 discovery exercise must identify every system, application, and protocol instance that relies on quantum-vulnerable public-key cryptography — specifically RSA, ECC, and Diffie-Hellman key establishment. Scope includes:

• TLS endpoints, VPN concentrators, and certificate chains
• Enterprise PKI: root CAs, issuing CAs, issuance policies, and external trust anchors
• Code-signing infrastructure and CI/CD signing steps
• SSH keys, authentication tokens, and federated identity systems
• Server, endpoint, mobile, network appliance, IoT, and OT/ICS device classes
• Embedded firmware and hardware security modules with fixed cryptographic implementations

The Phase 1 Cryptographic Asset Register (CBOM)

A Cryptographic Bill of Materials is the structured artefact that captures this inventory in a form supporting ongoing governance, vendor engagement, and audit evidence. At minimum, each CBOM entry should record:

• Asset ID, business owner, and environment
• Cryptographic algorithm in use (RSA key size, ECC curve), protocol (TLS version, IPsec, SSH), and underlying library or module
• Update mechanism: configuration change, patchable software, field-upgradable firmware, or fixed hardware
• Vendor, support dates, and whether a PQC roadmap has been confirmed (Y/N)

The update mechanism field matters disproportionately — it determines whether migration is a software change, a firmware upgrade, or a capital replacement project. Surface it as a first-class CBOM attribute, not a footnote.

Risk assessment dimensions

Once the inventory exists, risk assessment assigns priority across four dimensions that appear consistently across NCSC and NIST guidance:

• Data sensitivity and longevity — systems protecting data that must remain confidential for ten or more years carry the highest urgency because of harvest-now-decrypt-later exposure, regardless of when a cryptographically relevant quantum computer emerges
• System lifespan — long-lived OT, ICS, and embedded devices must be prioritised because replacement cycles are long and procurement lead times are significant
• Vendor dependency — systems whose cryptographic implementations are controlled by third-party vendors require early supplier engagement to confirm PQC roadmaps and avoid being blocked by vendor timelines
• Migration feasibility — software-based systems updatable via standard patch or configuration change are lower-effort migrations; hardware-dependent implementations may require physical device replacement

NIST CSWP 48 maps these dimensions directly to NIST CSF 2.0 outcomes and SP 800-53 controls, providing a structured methodology for translating this risk assessment into control gap analysis. Security architects should use that mapping as the basis for their Phase 1 assessment deliverable.

The three Phase 1 deliverables

Phase 1 produces three named artefacts, each with explicit ownership:

• The Cryptographic Asset Register (CBOM) — owned by security architecture, maintained by platform and application teams
• The Risk-Tiered PQC Migration Backlog — High / Medium / Low urgency tiers, owned by risk management and security architecture jointly
• The PQC Migration Programme Plan — multi-year, resource-loaded, owned by the CISO organisation through the PMO

Canadian federal departments were required to deliver exactly this — an initial departmental PQC migration plan — by April 1, 2026. Enterprises should treat that standard as a reasonable baseline for their own internal programme governance, not a ceiling.

Phase 2 (2028–2031): Prioritising and Migrating High-Risk Systems First

By 2031, both the UK NCSC target and Canada's federal requirement expect highest-priority systems to have completed migration to post-quantum cryptography. Phase 2 is where planned migration becomes executed migration, beginning with the systems identified as Tier-1 in the Phase 1 risk-tiered backlog.

The Phase 2 Feasibility Sequence

Practical migration experience — reflected in NCSC guidance — indicates a natural sequencing by technical complexity, moving from most feasible to hardest:

The Three-Wave Migration Pattern

Within each Phase 2 year, structure migration activity as three successive waves:

• Wave 1 — controllable server-side components: reverse proxies, VPN endpoints, internal load balancers. PQC enabled in hybrid mode, performance and interop validated in controlled conditions.
• Wave 2 — managed clients and internal services: managed endpoint fleet, internal APIs, CI/CD signing, internal PKI issuance. Hybrid PQC becomes the default, classical-only treated as exception.
• Wave 3 — complex trust boundaries: external partner integrations, customer-facing services, federated identity. Requires coordinated vendor and partner migration alongside your own.

Algorithm selection for Phase 2

NIST finalised three post-quantum cryptography FIPS on August 13, 2024:

• FIPS 203 specifies ML-KEM, a lattice-based key-encapsulation mechanism, for key establishment
• FIPS 204 specifies ML-DSA, a lattice-based digital signature scheme, for general-purpose signing
• FIPS 205 specifies SLH-DSA, a stateless hash-based digital signature algorithm providing a non-lattice alternative for cases where lattice-independence is required

NIST has also selected a code-based KEM, HQC, for standardisation as a fifth PQC algorithm, currently progressing through its own FIPS publication process. When finalised, HQC will sit alongside ML-KEM as a second key-establishment option — a deliberate portfolio design that implicitly endorses cryptographic agility as an architectural principle.

Unless you have a specific reason otherwise, treat ML-KEM as your default KEM and ML-DSA as your default general-purpose signature scheme. Reserve SLH-DSA for cases requiring hash-based properties or lattice-independent assurance, accepting the larger signatures and slower performance. Making this default explicit in architectural standards prevents the algorithm choice from being relitigated in every design review.

The Hybrid Transition Window

During Phase 2, most enterprise environments will operate in hybrid mode — running classical and post-quantum algorithms simultaneously to maintain interoperability with systems not yet migrated. This is operationally necessary but adds complexity that needs explicit guardrails:

• Configuration guardrails: for TLS, enforce that hybrid suites negotiate both classical and PQC components successfully; avoid suite configurations that silently downgrade to classical-only
• Monitoring: track telemetry on the percentage of connections actually negotiating ML-KEM and ML-DSA, and fail automated tests when services regress to classical-only suites
• Two named exit dates:
• PQC-preferred date — all Tier-1 services must offer PQC and prefer it when clients support it
• PQC-only date — classical RSA and ECC key establishment disabled for high-sensitivity systems, scheduled ahead of the 2035 NIST IR 8547 proposed disallowance

Setting both exit dates explicitly at programme kickoff turns hybrid mode from "temporary by default" into a measured, plannable transition. Without them, hybrid tends to persist by inertia, and the programme never completes.

Phase 3 (2031–2035): Full Enterprise PQC Adoption and Ongoing Governance

The 2035 target under both UK NCSC guidance and the Government of Canada ITSM.40001 roadmap represents full PQC adoption across all systems, services, and products. In US terms, this aligns with NIST IR 8547's proposed 2035 disallowance of RSA and ECC.

Phase 3 scope is predictable from Phase 1 risk tiering. Systems classified as Medium priority in Phase 1 — lower data sensitivity, shorter operational lifespans, or higher migration feasibility — become Phase 3's active migration targets. Any system whose vendor could not deliver PQC capability on a Phase 2 timeline should have been flagged in Phase 1 as a vendor risk; Phase 3 is when those vendor dependencies are resolved or the systems are replaced. ICS and OT environments that could not complete hardware replacement within Phase 2 due to operational constraints — plant shutdowns, safety validation cycles, procurement lead times — are the most likely source of Phase 3 exceptions, requiring documented executive-level risk acceptance with compensating controls and clear remediation timelines, not silent non-compliance.

Crypto agility as architectural property, not aspiration

The 2035 target marks the completion of migration, not the end of cryptographic change. HQC's addition as a fifth NIST standard, future algorithm standardisation, and the periodic deprecation-and-disallowance cycle that NIST IR 8547 formalises all imply that algorithm transitions will continue. Crypto agility — the architectural capability to swap cryptographic algorithms without systemic re-engineering — is what makes continuous governance tractable.

Concretely, crypto agility resolves to three architectural properties that Phase 2 migrations should build in deliberately:

• Central configuration — algorithms and key sizes set in policy (configuration, feature flags, or a central cryptographic policy service), not hard-coded in application logic
• Abstraction layers — applications consume cryptographic operations through internal libraries, SDKs, or a crypto proxy service that can be updated independently of consuming code
• Automated inventory — the CBOM ties into CI/CD and deployment pipelines so new services register their cryptographic dependencies automatically, preventing drift between the inventory and reality

Organisations that build these three properties into Phase 2 migrations will carry significantly lower governance overhead post-2035. Organisations that don't will experience the next algorithm transition as a repeat of this one.

Continuous governance post-2035

Establish a standing cryptographic governance function — owned in the CISO organisation, not distributed across platform teams — that maintains the CBOM on an ongoing basis, tracks NIST and NCSC algorithm updates, and manages transitions as standards evolve. Algorithm rotation becomes routine operational work, not an exceptional multi-year programme.

The Hidden Complexity: PKI, IoT, and ICS Migration Challenges

Regulatory guidance documents necessarily abstract over implementation complexity. Three domains consistently present the highest friction in enterprise PQC migrations, and each warrants specific architectural attention before Phase 2 execution begins.

PKI: parallel hierarchies, not overnight replacement

Enterprise PKI migration to PQC is not a leaf-certificate reissuance exercise. Over time, you will need to introduce a PQC-anchored CA hierarchy — up to and including new root CAs — because existing roots are signed with RSA or ECC algorithms that NIST IR 8547 proposes to deprecate by 2030 and disallow by 2035. In practice, most organisations will operate dual hierarchies for years, with classical and PQC roots and intermediates running in parallel during a multi-year transition, rather than switching roots overnight.

Certificate lifecycle management tooling must be evaluated for PQC certificate support before migration begins, not during it. The CA/Browser Forum and commercial CA vendors are currently evaluating hybrid certificates, parallel hierarchies, and related mechanisms; policy decisions in those ecosystems will shape what's available to enterprises during the transition window.

Tactical next step: stand up a lab-grade parallel PQC CA hierarchy this year, issue non-production ML-DSA leaf certificates, and verify that every major platform your organisation relies on — operating systems, browsers, application servers, network appliances — can consume them. The gaps you find are your Phase 2 vendor engagement priorities.

IoT: classify by update mechanism, not algorithm

For a significant subset of IoT devices, software patching is not a viable PQC migration path — the relevant constraint is the device's update mechanism and lifecycle, not simply its current algorithm. NCSC's migration timelines note that commodity hardware can often be addressed through normal refresh cycles, while industrial IoT and fielded devices present additional challenges requiring special attention.

Tactical next step: classify every IoT device class in the CBOM into three categories — fully patchable (firmware updates can deliver PQC), partially patchable (configuration change only, no crypto stack update), and non-patchable (fixed cryptographic implementation or no secure update mechanism). Treat the non-patchable category as a capital replacement project with a 2031–2035 deadline, captured in your multi-year technology refresh budget. Procurement criteria for any new IoT deployment should already specify PQC algorithm support and firmware update capability as mandatory requirements.

ICS: vendor roadmaps on the record

Industrial control systems combine long operational lifespans, safety-critical operational constraints, and vendor-controlled update cycles. Many ICS environments cannot tolerate unplanned downtime for cryptographic updates, and firmware changes may require safety re-validation before deployment. ICS PQC migration timelines are therefore largely determined by vendor roadmaps and operational maintenance windows, not by the security team's preferred schedule.

Tactical next step: request written PQC roadmaps from every ICS vendor this year. Capture the commitments — and, critically, the gaps — in the CBOM and the Risk-Tiered PQC Migration Backlog so the issue is visible at the board level. Vendor silence becomes a documented risk that forces procurement conversations on the 2031–2035 timeline.

Scope Translation: Federal Timelines and Private-Sector Enterprises

The 2028/2031/2035 frame is drawn from federal programmes, but private enterprises are not directly bound by federal timelines — which raises the question of how tightly non-federal CISOs should hold themselves to these dates. Three reasons to treat them as de facto floors rather than external references:

• Regulated sectors will align within audit cycles. Financial services, healthcare, critical infrastructure, and defence supply chain frameworks all align over time with federal cybersecurity direction. PCI DSS, HIPAA, DORA, NIS2, and FedRAMP equivalents will incorporate PQC expectations over the next two to three audit cycles; programmes started now align naturally.
• Government-supplier contracts flow deadlines downstream. Any organisation selling to US federal, UK public sector, or Canadian federal customers will inherit PQC requirements through procurement clauses, often on earlier timelines than the ultimate regulatory dates. A large cohort of private enterprises are already federal suppliers indirectly.
• Harvest-now-decrypt-later risk doesn't distinguish by sector. Adversaries collecting ciphertext today for later decryption are sector-agnostic. Long-lived sensitive data — health records, intellectual property, financial records with long retention — carries the same HNDL exposure regardless of whether a federal regulator is imposing a deadline.

The practical conclusion: build to the federal timelines. The audit and procurement pressures will catch up faster than a multi-year migration programme can respond if started at the compliance edge.

Building Your Internal PQC Migration Business Case

Executive buy-in for PQC migration investment is most effectively secured through three arguments presented together: regulatory compliance obligation, measurable risk reduction, and resource planning aligned to existing capital cycles.

The compliance argument is the most concrete. Canada's April 1, 2026 deadline for initial migration plans is a current compliance event for federal departments; the UK NCSC 2028 discovery target and NIST IR 8547's proposed 2030 deprecation of RSA/ECC are near-term forcing functions with documented regulatory direction behind them. For regulated industries, non-alignment with these timelines creates audit exposure and potential contractual liability with government customers or regulated counterparties.

The risk reduction argument connects to harvest-now-decrypt-later exposure. When RSA or ECC public-key cryptography is used for key establishment or encryption, an adversary intercepting and storing the resulting ciphertext today can, in principle, decrypt it retroactively once they have access to a cryptographically relevant quantum computer. For data with long confidentiality horizons, this is a current risk, not a future one. Each month without PQC deployment on high-sensitivity data channels represents an irreversible security decision for the data transmitted during that window.

The resource planning argument is operational: enterprise-scale PQC migration is a multi-year programme that will compete with other infrastructure investment priorities. Starting Phase 1 now creates the asset register and risk prioritisation that allows the organisation to integrate PQC migration into existing capital cycles — hardware refresh schedules, software contract renewals, PKI reissuance cycles — rather than funding it as an emergency programme. Emergency programmes cost more and deliver less.

PQC programme KPIs for quarterly executive reporting

• Compliance KPIs: percentage of systems with documented cryptographic inventory; percentage of Tier-1 systems with approved PQC migration plans; percentage of vendors with confirmed PQC roadmaps versus unknown
• Risk KPIs: percentage of Tier-1 data paths still using RSA or ECC-only key establishment; volume of high-sensitivity data transmitted over non-PQC-protected channels per month; HNDL exposure window (confidentiality horizon minus estimated time to cryptographically relevant quantum computer) for top-tier assets
• Programme KPIs: PQC adoption percentage in TLS handshakes internal versus external; Phase 2 wave completion status; Hybrid Transition Window exit dates tracked against plan

Translating PQC migration into this metric set lets the programme report progress in the same language as other infrastructure programmes and makes the work auditable as it proceeds.

Your 90-Day Action Plan

If your organisation has not begun a formal PQC migration programme, these 90 days produce the foundation of your PQC migration roadmap. Without this groundwork, none of the 2026–2035 regulatory milestones are reachable, and every subsequent migration phase remains unplanned.

Days 1–30:

• Appoint a PQC migration programme owner with explicit authority across security architecture, platform, and PMO
• Define the CBOM schema (minimum fields above) and select discovery tooling
• Issue written PQC roadmap requests to every vendor in PKI, TLS termination, VPN, ICS, and major application categories

Days 31–60:

• Complete the Tier-1 CBOM — critical business services and high-sensitivity data paths
• Apply risk tiering (High / Medium / Low) across Tier-1 assets using the four dimensions
• Draft the initial Phase 2 wave plan — TLS and VPN first, PKI in parallel, everything else scheduled

Days 61–90:

• Produce a formal PQC migration programme plan aligned to the 2028/2031/2035 frame
• Socialise with CIO, CFO, and audit committee; attach migration activities to upcoming hardware and software refresh cycles
• Stand up a PQC-capable lab environment with ML-KEM and ML-DSA and begin interoperability testing on your current platform stack

At 90 days, the organisation has a cryptographic asset register, a risk-tiered backlog, a resourced programme plan, and a working lab — the exact artefacts Canadian federal departments delivered under ITSM.40001, treated as a reasonable private-sector baseline rather than a federal-only obligation.

A Note on Source Currency

Several of the primary sources cited in this roadmap are in draft or recently published status:

• NIST IR 8547 is an initial public draft (November 2024) and its proposed 2030 deprecation and 2035 disallowance dates may be refined before finalisation.
• NIST CSWP 48 is an initial public draft (September 2025) and its mappings to NIST CSF 2.0 and SP 800-53 may be updated after public comment.
• HQC is progressing through its own FIPS publication process; its final standard designation and publication date are still subject to NIST's standardisation workflow.
• NCSC's Timelines for migration to post-quantum cryptography was published 19 March 2025 and may be superseded by updated guidance.

Readers making specific compliance, audit, or procurement decisions should verify the current status of the relevant source before acting on the dates and language in this roadmap. The structural approach — phased migration, cryptographic inventory, risk tiering, hybrid transition — remains valid regardless of specific standards-timeline movement.

Key Takeaways

• The Government of Canada's ITSM.40001 roadmap requires federal departments to deliver an initial departmental PQC migration plan by April 1, 2026, with annual progress reporting beginning at that date.
• The UK NCSC's March 2025 guidance sets target dates — not statutory mandates — of 2028 for discovery and assessment, 2031 for highest-priority migrations, and 2035 for full PQC migration across all systems, services, and products.
• NIST IR 8547 is an initial public draft proposing that RSA and ECC at approximately 112- and 128-bit security levels be deprecated by 2030 (no new deployments) and disallowed by 2035 (removed as NIST-approved options). These are distinct states in NIST's transition model.
• NIST Cybersecurity White Paper CSWP 48 maps PQC migration capabilities to NIST CSF 2.0 outcomes and SP 800-53 security and privacy controls, providing a structured methodology for Phase 1 control gap analysis.
• Phase 1 produces three named artefacts with explicit ownership: the Cryptographic Asset Register (CBOM), the Risk-Tiered PQC Migration Backlog, and the PQC Migration Programme Plan.
• FIPS 203 (ML-KEM), FIPS 204 (ML-DSA), and FIPS 205 (SLH-DSA) were all published on August 13, 2024; HQC is a fifth NIST-selected PQC algorithm currently progressing through its own FIPS publication process.
• The Phase 2 Feasibility Sequence runs TLS/VPN → PKI → applications → IoT → ICS, executed through Wave 1 (server-side), Wave 2 (managed clients and internal services), and Wave 3 (external trust boundaries).
• The Hybrid Transition Window needs two explicit exit dates — PQC-preferred and PQC-only — scheduled ahead of the 2035 NIST IR 8547 proposed disallowance.
• Crypto agility built into Phase 2 migrations as three architectural properties (central configuration, abstraction layers, automated inventory) significantly reduces post-2035 governance overhead as standards continue to evolve.

Disclaimer: This content is for informational purposes only and does not constitute legal, regulatory, or compliance advice. Consult a qualified professional before making compliance decisions. pqcinformation.com is independent and not affiliated with any vendor or standards body.