PQC Migration Strategy Roadmap for Cybersecurity Leaders

Most organisations that have reached the CISO's desk on PQC have the same problem: they have a list of exposures and no structure for acting on it. A discovery exercise produced a cryptographic inventory. The inventory produced a long backlog. The backlog produced paralysis, because nobody agreed on where to start, who owns what, or how long it will take.

This article is for the CISO or CTO who has accepted the threat case and needs a programme architecture, not another explainer. It covers the five-phase model, the dependency structure that most programme plans get wrong, the governance outputs that must exist before discovery starts, and what the board actually needs to see.

Why a migration strategy is not a compliance checklist

A PQC readiness checklist identifies what is missing. A migration programme defines how to address it, in what sequence, by whom, at what cost, and against which external deadlines. These are different instruments for different problems. Many organisations have a checklist. Very few have a programme. Before running your diagnostic, see PQC Readiness Checklist for CISOs 2026; this article assumes you have done that work and now need the programme structure to act on the findings.

PQC migration differs from a standard security remediation sprint in two ways that make the difference between a successful programme and an expensive stall.

First, the dependency chain runs in one direction. Root-of-trust infrastructure (PKI, HSMs, code-signing) must migrate before dependent systems can follow. A flat remediation sprint cannot honour this. Phase your programme around the dependency structure, not around team availability or system complexity.

Second, the harvest-now-decrypt-later (HNDL) urgency means the most time-critical step is not necessarily the largest or most complex. Hybrid key exchange on data flows with long confidentiality requirements must be prioritised independently of project scope. NIST NCCoE SP 1800-38B (2024) provides the reference framework for this dependency and phasing model. Mosca's inequality (Mosca, IEEE Security and Privacy, 2018) provides the mathematical basis for the HNDL urgency: if the sensitivity lifetime of the data plus the migration time for the system exceeds the time remaining to a cryptographically relevant quantum computer, the system is HNDL-exposed and needs Phase 3 treatment before Phase 4.

The five-phase programme model

A PQC migration programme can be structured in five phases, each with a distinct objective, primary output, and decision gate. The external deadline structure comes from three sources: NIST IR 8547 (November 2024), NCSC's phased timeline (March 2025), and NSA CNSA 2.0 (September 2022). See PQC Migration Timeline: 2025, 2026, 2027 for the full calendar anchors.

The structural point that every programme plan must get right: Phases 3 and 4 are not sequential. Phase 3 begins as soon as Phase 2 is complete for HNDL-exposed systems. Phase 4 begins for non-HNDL-exposed systems while Phase 3 is still running on HNDL-exposed ones. Treating them sequentially adds two to three years of unnecessary HNDL exposure for the systems that needed protection first.

Phase 0: organisational foundations most organisations skip

A PQC migration programme requires a named programme owner with board-level mandate. This is not a bureaucratic formality. Cryptographic migration touches IT, operational technology, legal, procurement, finance, and HR. Without cross-functional mandate, the programme stalls whenever it hits a dependency outside the security team's authority. The programme owner does not need to be a cryptographer. They need authority, budget, and organisational reach.

Three Phase 0 outputs must exist before Phase 1 begins:

• A cryptographic governance policy defining approved algorithms, hybrid scheme requirements, and an algorithm review cadence. Without this, the CBOM has no acceptance criteria and no change control baseline.
• A budget line covering discovery tooling, library upgrades, certificate reissuance at scale, and external specialist support for OT environments. Phase 4 costs dominate the total, but Phase 0 to 2 needs its own budget line or it will be deferred indefinitely.
• An executive sponsor with accountability for the 2030 to 2035 regulatory milestones: NIST IR 8547's 2030 deprecation of RSA and ECC in new deployments, NCSC's 2031 to 2035 completion window, and NSA CNSA 2.0's 2033 hard date for National Security Systems.

Without these outputs, Phase 1 produces a CBOM that no-one is authorised to act on. This is the most common failure mode in PQC programme planning: discovery without mandate.

Phase 1: building a risk-prioritised CBOM

The Cryptographic Bill of Materials (CBOM) is the primary Phase 1 output. Minimum content per NIST IR 8547 and NIST NCCoE SP 1800-38B: algorithm identity (RSA-2048, ECDSA P-256, AES-128, and so on), key size, protocol context (TLS, IPsec, S/MIME, code signing, SSH, database TDE, PKI), system location (IT, OT, cloud, SaaS dependency), certificate metadata (CA, validity period, renewal cycle), and data classification for the information the cryptographic protection covers.

A CBOM populated from memory rather than automated discovery has systematic gaps in shadow IT and legacy applications. A perimeter TLS scanner is the starting point, not the output. It captures internet-facing TLS endpoints. It does not capture internal east-west traffic, IPsec VPNs, code-signing infrastructure, S/MIME, database TDE, OT protocols, HSM-managed keys, or SaaS dependencies.

Before Phase 1 is considered complete, apply HNDL exposure scoring to every CBOM entry using the Mosca inequality: T_s (sensitivity lifetime of the data) plus T_m (migration time for the system) greater than T_q (time remaining to a CRQC). For planning purposes, T_q is 2033 to 2035, consistent with the Global Risk Institute's 2024 median estimate. An entry where T_s + T_m > T_q is Phase 3 priority. This scoring converts the CBOM from a flat inventory into a risk-ordered migration queue.

OT environments are typically the most incomplete component of any Phase 1 exercise and the most critical for organisations with critical national infrastructure obligations. Industrial control systems often run proprietary or legacy protocols (Modbus/TCP, DNP3-SA, IEC 62351) with embedded cryptographic implementations not reachable by standard TLS scanning tools. OT CBOM requires vendor documentation review, network capture analysis, and sometimes physical device inspection. Begin OT scoping early; the lead time for OT vendor responses is long. For the full gap analysis methodology, see PQC Compliance Readiness Gap Analysis.

Phase 2: algorithm selection and architecture

There is no further waiting. The NIST algorithm selection is complete. The decisions for each use case are:

• Key encapsulation and key establishment: ML-KEM (NIST FIPS 203, August 2024). ML-KEM-768 for commercial enterprise TLS via X-Wing hybrid (IETF RFC 9496); ML-KEM-1024 for CNSA 2.0 scope and highest-assurance applications.
• Digital signatures, general purpose: ML-DSA (NIST FIPS 204, August 2024). ML-DSA-65 for most applications (public key 1,952 bytes, signature 3,309 bytes); ML-DSA-87 for CNSA 2.0 scope (public key 2,592 bytes, signature 4,627 bytes).
• Digital signatures, long-lived or high-assurance: SLH-DSA (NIST FIPS 205, August 2024). For CA root certificates, firmware signing, archival integrity. Hash-function-only security basis provides the most conservative diversification from ML-DSA's lattice assumptions.
• Digital signatures, constrained environments requiring smallest signature: FN-DSA (NIST FIPS 206, October 2024).
• Symmetric encryption: AES-256. No replacement required; quantum-safe under Grover's algorithm analysis.

Hybrid scheme design must be confirmed in Phase 2 before any Phase 3 deployment. For internet-facing TLS: X25519+ML-KEM-768 (X-Wing, RFC 9496). For CNSA 2.0 scope: ECDH P-384+ML-KEM-1024. For IPsec IKEv2: ML-KEM-768 combined with an existing DH group per IETF RFC 9370 (Multiple Key Exchanges in IKEv2, 2023).

Library and toolchain readiness confirmation is also a Phase 2 deliverable. As of knowledge cutoff August 2025, relevant libraries include: OpenSSL 3.5 (ML-KEM and ML-DSA support in the mainline codebase); BoringSSL (X25519+ML-KEM-768 deployed in Chrome); AWS s2n-tls (post-quantum hybrid); wolfSSL (ML-KEM integration for embedded targets); and RustCrypto (pure-Rust ML-KEM and ML-DSA implementations). For detailed library maturity assessment covering FIPS 140-3 validation status and the Kyber Round 3 versus FIPS 203 distinction, see the companion article on FIPS 203 and 205 library implementation. For FIPS 140-3 regulated environments, verify the NIST CMVP database for modules with ML-KEM within the validated scope; validation for ML-KEM was in progress at knowledge cutoff.

Phase 3: hybrid deployment on HNDL-exposed flows (the urgent track)

Phase 3 is the most operationally important phase in the programme, and the one most commonly mispositioned as sequential after Phase 4. This ordering error delays HNDL protection for the highest-risk flows by two to four years.

The operative question for each HNDL-scored system is not "is it technically complex to migrate?" It is "is the data it protects currently vulnerable to HNDL collection?" If yes, that system is a Phase 3 priority regardless of migration complexity. Hybrid key exchange deployment provides HNDL protection without requiring certificate migration. Phase 3 and Phase 4 operate on the same systems in parallel, not in sequence.

The TLS hybrid deployment sequence for a single Phase 3 system:

1. Verify OpenSSL 3.5 or BoringSSL is running. Confirm ML-KEM support in the installed version.
2. Configure the ML-KEM hybrid cipher suite (X-Wing, X25519+ML-KEM-768) in the TLS configuration.
3. Confirm that non-PQC clients fall back correctly. The IETF TLS hybrid design ensures backward compatibility for clients without ML-KEM support.
4. Monitor handshake sizes for TCP fragmentation in latency-sensitive environments. ML-KEM-768 hybrid adds approximately 2.2 KB to the TLS handshake. For most deployments this fits within the TCP initial congestion window and does not add round-trip time.

The certificate chain is unchanged at this step. This is Phase 3, not Phase 4. Certificate migration is a Phase 4 activity.

Phase 4: systematic migration (the long track)

Phase 4 covers the broader migration population: certificate lifecycle migration to ML-DSA, PKI root and intermediate CA upgrades, OT and IoT system migration, legacy application updates, and code-signing infrastructure. These systems are not HNDL-urgent in the way Phase 3 systems are, but they face two hard external deadlines: NIST IR 8547's 2030 deprecation of RSA and ECC in new deployments, and NCSC's completion window of 2031 to 2035 for high-priority and full migration. NSA CNSA 2.0 sets 2033 as the National Security Systems transition date.

Code-signing infrastructure is a Phase 4 early priority. Signed firmware images for automotive ECUs, industrial control systems, and embedded medical devices may be in field deployment for ten to fifteen years after signing. A firmware image signed in 2026 under RSA may still be running in 2033 when a CRQC could emerge. The replacement signing infrastructure must use SLH-DSA (FIPS 205) for long-lived assets, where the hash-function-only security basis provides conservative protection independent of lattice assumptions, or ML-DSA (FIPS 204) for shorter-lifecycle signing.

OT and IoT migrations in Phase 4 are the longest-duration items. Constrained devices, microcontrollers, legacy PLCs, and embedded sensors may require hardware replacement rather than firmware upgrade if ML-KEM cannot run within their memory and compute constraints. The PQM4 project (Kannwischer et al., IACR ePrint 2019/844) provides reference benchmarks: ML-KEM-512 key generation at approximately 1 to 2 ms and ML-KEM-768 at approximately 2 to 3 ms on ARM Cortex-M4. Devices that cannot meet these budgets within their protocol context require a hardware refresh. Refresh cycles for OT assets run three to seven years, depending on the asset class. These devices must be identified in Phase 1 and their procurement timelines planned in Phase 4 now, not when Phase 4 actually begins.

Phase 5: governance embedding and the living CBOM

A CBOM is not a one-time deliverable. Cryptographic assets change as software is updated, new systems are deployed, and external CAs issue certificates. Phase 5 embeds CBOM maintenance into change management and procurement. New system acquisitions should require a vendor cryptographic capability statement: which algorithms, which parameter sets, what the migration roadmap is, and when delivery is planned. Change management should require a cryptographic impact assessment for any change touching cryptographic components.

Supply chain cryptographic readiness is the most underweighted risk in most PQC programme plans. SaaS providers, managed service providers, and software vendors all have their own migration timelines. Critical supply chain dependencies should be identified in Phase 1 and tracked through Phases 3 and 4. NIS2 Directive Article 21(2)(d) requires covered organisations to manage supply chain security risks as part of risk management obligations. Do not discover in 2029 that a critical SaaS dependency has no PQC migration roadmap.

Crypto agility is the architectural principle that determines the cost of future algorithm changes. Any organisation investing in Phase 4 migrations should require crypto-agile architecture in all new systems procured from this point: algorithm selection at configuration level, not hardcoded in application code. NIST CSWP 04282021 provides the authoritative guidance on implementation. The programme investment in Phase 4 is partially wasted if the systems procured during that phase require another round of application rewrites when the next algorithm change arrives.

What the board needs to see and the three decisions that set programme pace

Board-level PQC programme reporting does not require board members to understand lattice cryptography. Four questions give them a governance view:

1. What is our current HNDL exposure? (CBOM with HNDL scoring answers this.)
2. What are our binding regulatory deadlines and are we on track? (NIST IR 8547 2030, NCSC 2031 to 2035, CNSA 2.0 2033, as applicable.)
3. What have we deployed to date and what remains? (Phase 3 hybrid deployment progress as a percentage of HNDL-scored systems.)
4. What is the supply chain risk? (Which critical vendors have confirmed PQC roadmaps and by when.)

For organisations in NIS2 scope, NIS2 Article 21(2)(h) explicitly includes the use of cryptography and encryption within the risk management measures that covered entities must implement. PQC migration programme progress is a reportable item under NIS2 risk management obligations in transposed member states. National Competent Authorities may request evidence of cryptographic risk management capability during supervision visits.

Three decisions determine how fast the programme moves:

• Decision 1: When to start Phase 1. The only decision with no downside to making early. Every month of delay on the CBOM is a month of compounding HNDL exposure for unidentified assets.
• Decision 2: Which systems are Phase 3 versus Phase 4. The Mosca inequality is the scoring mechanism. Getting it wrong delays HNDL protection for the data that needed it first.
• Decision 3: How to handle long hardware refresh cycles in Phase 4. OT, IoT, and embedded systems with three-to-seven-year replacement windows must be planned now, regardless of where Phase 4 sits in the project calendar.

Five common programme failure modes, each of which is a pattern rather than a hypothetical:

• Treating PQC migration as an IT project with a single deadline rather than a phased programme with concurrent workstreams.
• Sequencing Phase 3 after Phase 4 is complete, losing the HNDL protection window for the highest-risk systems.
• Completing a CBOM without HNDL scoring and triaging by migration cost rather than by exposure.
• Assuming "our vendor will handle it" without contractual confirmation of the vendor's PQC roadmap and delivery timeline.
• Delaying Phase 0 because there is no board mandate. The mandate must be created, not waited for. If your board has not been briefed, that is a programme initiation task, not a blocker.

An organisation that starts Phase 0 in 2027 has two years less runway for Phase 1 than NCSC's March 2025 timeline assumes. The 2030 NIST deprecation date is not the start date. Enterprise PKI migrations take twelve to eighteen months. OT device procurement takes longer. Phase 1 alone takes three to six months for a complex organisation. Work backwards from 2030 and the calendar becomes uncomfortable quickly.

Sources verified 2026-05-18. NIST FIPS 203, August 2024; NIST FIPS 204, August 2024; NIST FIPS 205, August 2024; NIST FIPS 206, October 2024; NIST IR 8547, November 2024; NIST NCCoE SP 1800-38B, 2024; NIST CSWP 04282021; NCSC Timelines for migration to post-quantum cryptography, March 2025; NSA CNSA 2.0, September 2022; IETF RFC 9496 (X-Wing), 2024; IETF RFC 9370, 2023; Mosca, IEEE Security and Privacy 2018; Global Risk Institute 2024 Quantum Threat Timeline Report; NIS2 Directive (EU) 2022/2555; NIST CMVP.