Why Most Timeline Estimates Are Too Short

The most common failure mode in PQC migration planning is treating the problem as a software update. Libraries need updating; that is true. But library migration is the simplest component, and it is not the bottleneck. The bottleneck is almost always one of three things: a cryptographic estate that no one has fully mapped, hardware security modules (HSMs) that need physical replacement, or an application landscape where hundreds of internal applications use cryptography in ways that are undocumented and un-agile.

The second failure mode is sequential optimism: assuming phases can be parallelised more than they actually can. Certificate authority migration depends on library migration completing first (the HSMs protecting CA private keys must support the new algorithms). Application-layer migration depends on library migration and CA migration. Testing at scale is measured in months, not days. A programme that assumes these phases run concurrently will slip its plan.

The third failure mode is underestimating vendor dependency. Third-party SaaS applications, ISV software, embedded device firmware, and public CA certificates (from DigiCert, Sectigo, GlobalSign, and others) all have their own migration timelines. An organisation cannot fully migrate its public-facing TLS certificates to ML-DSA (Module-Lattice-Based Digital Signature Standard, FIPS 204) until the public CAs support ML-DSA root certificates and browsers accept them. That is an external dependency no security programme manager controls.

Phases 1 and 2: Before You Write a Line of Code (3 to 15 Months of Planning)

Phase 1: Discovery and Cryptographic Inventory (3 to 6 Months)

Discovery is the prerequisite for everything that follows. You cannot scope a migration programme, select algorithms, or plan HSM procurement without knowing what cryptographic assets exist across the estate. Most large enterprises do not have this inventory.

Certificates are scattered across multiple certificate authorities, registrars, cloud providers, and development teams. Application-layer cryptography in internal applications is frequently undocumented and discovered only through static analysis tooling or manual code review. Third-party and SaaS dependencies require vendor disclosure requests; response times vary from days to months. Embedded and IoT devices often require physical or firmware-level inspection. The cryptographic asset register build guide covers what a systematic discovery programme looks like in practice.

CBOM (cryptographic bill of materials) tooling is maturing but not yet enterprise-standard. CycloneDX 1.6 (April 2024) added native CBOM support, and tooling integrations are in active development across the ecosystem. Organisations with no CBOM tooling in place should expect the upper end of the 3 to 6 month estimate. The CBOM foundation guide covers what the inventory needs to capture to be useful for migration scoping.

NIST IR 8547 IPD (November 2024) provides interoperability and migration guidance that is useful during discovery to understand which algorithm families are relevant to which use cases. A cryptographic asset prioritisation matrix helps scope which systems require immediate migration versus deferred migration within the discovery output.

Phase 2: Architecture Design and Crypto-Agility (4 to 9 Months)

Architecture design covers algorithm selection, hybrid deployment model, crypto-agility requirements, key management hierarchy redesign, and HSM replacement planning. The range is wide because organisations start from very different baseline positions.

Organisations with existing crypto-agility, where TLS configuration is abstracted into a centralised management layer, can transition configuration faster. Organisations with hardcoded algorithm choices in application code or firmware face re-architecture rather than reconfiguration. That distinction is not visible from the outside; it only becomes apparent during discovery.

Algorithm selection has a degree of specificity that surprises organisations encountering it for the first time. For key encapsulation, ML-KEM-768 (FIPS 203, security level 3) is the standard enterprise choice. ML-KEM-1024 (security level 5) is required under NSA CNSA 2.0 for national security systems. For digital signatures, ML-DSA-65 or ML-DSA-87 (FIPS 204) covers most signing applications; SLH-DSA (Stateless Hash-Based Digital Signature Standard, FIPS 205) is preferred for code-signing use cases where stateless security properties are important. Hybrid schemes (ML-KEM alongside X25519, ML-DSA alongside ECDSA) are recommended by both NCSC and NIST during the transition period to maintain backward compatibility.

For EU and EEA organisations, the ANSSI PQC position paper (March 2022) and BSI migration recommendations are also relevant; the European positions have maintained nuanced differences from NIST on certain algorithm choices that boards and architecture governance processes will want to account for.

Phase 3: Libraries and HSMs (6 to 18 Months, the Hardware Bottleneck)

Library updates for standard TLS stacks are available or near-available for modern software versions. OpenSSL 3.x has ML-KEM support in progress via OQS integration; BoringSSL has experimental ML-KEM support. For organisations running current software, library migration may be 6 to 9 months of testing, integration, and deployment. Legacy stacks take longer.

HSM migration is the critical path item for large financial services organisations. Physical HSMs from Thales, Entrust, and Utimaco have PQC support roadmaps at varying stages. Physical replacement cycles include procurement lead times (which have been running at several months in some cases across the industry), firmware qualification, and key ceremony planning. Organisations with large HSM fleets cannot realistically complete this phase in under 9 months. The HSM procurement and readiness criteria insight covers what to evaluate when selecting post-quantum capable hardware.

One specific dependency worth tracking: PKCS#11 v3.1 (published 23 July 2023) added LMS/HSS support. ML-KEM and ML-DSA support is in the v3.2 draft (targeting April 2025 as of this writing). Organisations should verify their HSM vendor's PKCS#11 v3.2 roadmap before finalising procurement decisions, since some current HSM integrations use pre-standard interfaces.

Embedded and IoT firmware updates sit at the far end of this range. Update mechanisms may not exist for older devices; physical access may be required; cryptographic overhead may exceed device capability. For organisations with large constrained-device estates, 18 months is not a conservative estimate.

Phases 4 and 5: Certificates and Applications (6 to 36 Months Combined)

Phase 4: Certificate Authority Migration (6 to 12 Months)

Enterprise PKI commonly contains hundreds of issuing CA certificates and tens of thousands of end-entity certificates. Re-issuance at scale requires automation, typically via the ACME protocol for certificate management or equivalent enterprise PKI automation tooling. CA migration cannot begin until the underlying HSMs protecting CA private keys are migrated, which is a hard dependency on Phase 3.

Hybrid certificates (dual-algorithm certificates carrying both a classical and a PQC signature) are under active development in IETF working groups. Until hybrid certificate standards stabilise, organisations face a choice between early PQC-only migration, which may cause client compatibility issues, and waiting for hybrid standards, which delays the schedule. This is a genuine planning dilemma rather than a solved problem.

Public CA migration is an external dependency. Certificates issued by commercial CAs depend on those CAs' own migration timelines and on browser and operating system root store acceptance of ML-DSA root certificates. That acceptance timetable is outside any individual organisation's control.

Phase 5: Application-Layer Migration (12 to 24 Months)

This is typically the longest phase. The number of affected applications in a tier-1 enterprise can be in the hundreds to low thousands. Completed library migration (Phase 3) and CA migration (Phase 4) are prerequisites in most cases, so application-layer work cannot fully begin until those phases are substantially complete.

Legacy applications with no active development resource present the hardest problem. They cannot be updated without dedicated resource allocation; the alternative is a decommissioning decision, which has its own timeline. Third-party application dependencies require vendor PQC migration roadmaps and contractual commitments: a SaaS provider that has not published a PQC roadmap is a migration blocker that no internal programme can resolve unilaterally.

Testing at scale is significant. Cryptographic changes affect performance, interoperability, and in some cases correctness. A regression testing cycle for a large application estate is measured in months. Analyst estimates suggest that organisations underestimate application-layer migration effort more consistently than they underestimate any other phase.

Phase 6: Validation and What Regulators Will Ask For (3 to 6 Months)

Validation is not a retrospective check. It is a distinct programme phase that produces the documentation regulators and auditors require.

For EU and EEA organisations, NIS2 Article 21(2)(h) requires appropriate cryptographic measures as part of documented risk management. The absence of a completed migration is not the compliance gap; the absence of a documented plan, progress evidence, and validation findings is. DORA Article 9 (protection and prevention, including cryptographic controls) applies to EU and EEA financial entities; DORA Article 6 establishes the ICT risk framework that validation evidence feeds into.

For UK organisations, the UK NIS Regulations 2018 (SI 2018/506) are the applicable framework for critical national infrastructure and essential service operators. The NCSC Cyber Assessment Framework v3.2 (April 2024) is the current assessment standard; CAF alignment is what UK CNI organisations will need to demonstrate. ISO 27001:2022 Annex A.8.24 covers cryptographic management; recertification after PQC migration may require a full surveillance audit cycle.

For US defence contractors, CMMC Level 2 and Level 3 audit cycles add regulatory overhead. A CMMC audit can run 6 to 12 months from assessment through remediation to certification. That cycle is a primary driver of the longer total timeline in the defence segment.

One clarification on jurisdiction: DORA does not bind UK financial institutions. NIS2 is not UK law. UK firms should not conflate EU regulatory obligations with their own; the frameworks are distinct, though many of the underlying controls overlap.

Realistic Total Timelines by Segment

The table below reflects programme-scoping estimates and analyst projections. These are not empirical averages from completed large-scale PQC migrations; no such sample exists yet. Treat them as planning-range inputs, not guaranteed durations.

The NCSC 2031 milestone for critical national infrastructure sets a concrete outer boundary for UK organisations. An organisation starting a full PQC migration programme in mid-2026 has approximately five years. That is achievable for most. It is not comfortable for large or complex estates, and it assumes no major procurement delays, governance slippage, or application-layer surprises.

One misconception worth addressing: cloud migration does not cover the full estate. Cloud providers updating TLS and key management covers the cloud-managed layer. Application-layer cryptography, on-premise HSMs, internal PKI, and bespoke encryption implementations are not covered by cloud provider updates. Mid-market organisations with cloud-first architectures have a lighter residual migration burden. They do not have zero burden.

For the defence segment, NSM-10 (4 May 2022) directed US federal agencies to prioritise migration of high-value assets and established timelines for the highest-sensitivity systems. CNSA 2.0 mandates ML-KEM-1024 for key encapsulation and ML-DSA-87 for signatures in national security systems, the highest parameter sets in the NIST suite. Defence organisations cannot trade down to lower parameter sets for performance reasons, which removes an option available to commercial organisations.