NCSC PQC Migration Guidance: The UK Position Explained

On 20 March 2025, the UK National Cyber Security Centre published "Timelines for migration to post-quantum cryptography." It is the NCSC's first dedicated migration timeline document, and it sets three milestone dates: 2028, 2031, and 2035. Those dates are not legally binding deadlines for most commercial organisations. For operators of essential services designated under the Network and Information Systems (NIS) Regulations 2018, they define the technical baseline that sector regulators will use when assessing security measures.

This article works through what the guidance actually requires at each phase, how it connects to UK legal obligations, what the sector-specific challenges look like, and why 2028 is the milestone that demands immediate attention rather than the 2035 endpoint most organisations focus on.

A point of clarification that matters throughout: the UK NIS Regulations 2018 (SI 2018/506) are a transposition of the EU's original NIS1 Directive (Directive (EU) 2016/1148). They are not NIS2. EU NIS2 (Directive (EU) 2022/2555) is an EU instrument and does not apply to UK-established organisations operating under UK jurisdiction. The two frameworks are legally distinct. UK organisations that are part of EU corporate groups or supply ICT services to EU essential or important entities may face contractual obligations driven by NIS2, but they are not directly subject to it. Confusing the two is a common error; this article does not make it.

What the NCSC Published in March 2025 and Why It Matters

The NCSC's "Timelines for migration to post-quantum cryptography," published at https://www.ncsc.gov.uk/guidance/pqc-migration-timelines, sets out a three-phase migration framework. Its publication followed the finalisation of the NIST post-quantum cryptography standards in August and October 2024, which provided the algorithm targets that made a timeline document actionable. Before NIST finalised FIPS 203, 204, 205, and 206, UK organisations had guidance on the threat but no confirmed algorithm candidates to migrate to.

The primary audience is technical decision-makers and risk owners at large organisations, operators of critical national infrastructure (CNI) including industrial control systems, and organisations with bespoke IT environments. The NCSC recommends that all organisations with internet-connected services consider the timeline, but the Phase 1 deliverable is directed first at large and CNI organisations where the cryptographic estate is largest and the migration complexity is highest.

The NCSC also launched a pilot PQC consultancy scheme in March 2025, onboarding an initial cohort of eight organisations. The scheme provides direct technical assistance on cryptographic discovery and migration planning. Its existence confirms that the NCSC expects Phase 1 to be genuinely demanding, not a quick audit exercise. [ASSUMED: the scheme's current status, whether it has expanded beyond the initial eight cohort organisations, should be verified before publication.]

The Three Phases: What Each Milestone Actually Requires

The three phases are sequential but have overlapping preparation. Each has a defined deliverable, not a vague ambition.

The 2035 endpoint aligns with NIST IR 8547 (November 2024), which designates 2035 as the target date for complete retirement of RSA, ECDH, ECDSA, DSA, and classical finite-field Diffie-Hellman across US federal systems. The convergence of UK NCSC and US NIST timelines reflects coordinated international planning, not coincidence.

Phase 1's deliverable is a Cryptographic Bill of Materials: a structured inventory of which algorithms, key sizes, and protocols protect which systems across the organisation's IT and OT estate. The CBOM must cover algorithm identity, key sizes, protocol contexts (TLS, IPsec, S/MIME, code signing, SSH, database transparent data encryption), certificate and PKI dependencies, and supply chain cryptographic interfaces. The NIST NCCoE SP 1800-38B migration project provides a detailed CBOM methodology aligned with the NCSC's Phase 1 requirements. No gap analysis is possible without this inventory.

Sector-Specific Challenges: Internet-Facing and Infrastructure-Heavy

The NCSC distinguishes two broad sector types with different migration trajectories.

Internet-facing sectors — banking, financial services, telecommunications — should prioritise earlier migration. PQC product availability is advancing fastest in this space; hardware and software supporting ML-KEM and ML-DSA is increasingly available in commercial TLS libraries, load balancers, and enterprise security products. These sectors also have the most global supply chain dependencies, which means co-ordinating migration with international partners in the same sectors is both necessary and practically achievable. Hybrid TLS deployment, which requires only library support and configuration changes rather than PKI replacement, can be rolled out rapidly.

Infrastructure-heavy sectors — operational technology, industrial control systems, embedded systems in energy and water infrastructure — face a different constraint set. PQC product options for OT and ICS environments are significantly fewer than for IT environments. Many fielded OT devices cannot be patched in place; they must be replaced or network-isolated to address cryptographic vulnerabilities. Physical infrastructure changes must be co-ordinated with maintenance windows that may occur on multi-year cycles. For these environments, IEC 62443-3-3 zone-and-conduit network segmentation provides the standard framework for managing cryptographic upgrade risk during the transition period: isolate non-upgradeable devices, upgrade network edge controls, and plan device replacement in the next scheduled lifecycle refresh.

The NCSC specifically notes that OT organisations must secure remote IT access channels (which are IT-side, manageable with standard TLS hybrid deployment) and address wirelessly connected fielded OT devices. The wireless connection point is where OT and IT cryptographic risk intersect, and it is typically the highest-priority OT migration target because it is both accessible to adversarial interception and often more manageable to upgrade than embedded industrial controllers.

The UK Legal Context: NIS Regulations 2018 and Sector Competent Authorities

The Network and Information Systems (NIS) Regulations 2018 (SI 2018/506) impose cybersecurity obligations on operators of essential services (OES) and digital service providers (DSPs). Operators of essential services must take appropriate and proportionate technical and organisational measures to manage security risks and prevent or minimise the impact of incidents. The regulations apply across six sectors: energy, transport, water, health, digital infrastructure, and financial market infrastructure.

Each sector has a designated competent authority under the regulations: the FCA for financial services, Ofcom for digital infrastructure and digital service providers, BEIS/OPSS for water and energy distribution, DHSC for health, and the DfT for transport. Competent authorities can issue written notices requiring operators to provide evidence of their security measures and, where measures are insufficient, can direct improvement. The NCSC's March 2025 guidance defines the technical baseline that competent authorities will reference when assessing operator security measures under these powers.

The NCSC guidance does not itself create legally binding deadlines for commercial organisations that are not designated OES. An organisation outside the NIS Regulations 2018 scope can treat the NCSC timeline as best practice guidance. For a designated OES, the calculus is different: a competent authority that has reviewed the NCSC guidance and the NIST FIPS standards will have a formed view of what "appropriate and proportionate" measures include, and an OES that has taken no steps by 2028 will face difficulty demonstrating proportionate risk management in a supervisory assessment.

The UK Cyber Security and Resilience Bill, announced in the King's Speech in July 2024, was in consultation at the knowledge cutoff. [ASSUMED: Kelly must verify the Bill's enacted status and, if enacted, what obligations it creates for organisations currently only in scope under the NIS Regulations 2018, before the legal context section is finalised for publication.]

Why 2028 Is the Urgent Milestone: The HNDL Driver

The Phase 1 deadline of 2028 matters because the threat it responds to is operating now, not in 2028. Harvest-now-decrypt-later (HNDL) is the adversarial strategy of capturing encrypted ciphertext today and storing it for decryption when a cryptographically relevant quantum computer becomes available. Data transmitted under RSA or ECDH key exchange in 2026 is being intercepted and archived. The question is when the archive becomes readable.

The NCSC's March 2025 guidance does not cite a fixed Q-Day date. The planning window it implicitly accepts is consistent with the 2033-2035 range in NIST IR 8547 (November 2024) and NSA CNSA 2.0 (September 2022). The Global Risk Institute Quantum Threat Timeline Report 2025 (Mosca and Piani, published 9 March 2026) found that 28 to 49% of expert respondents assigned a probability greater than 50% to a CRQC existing within 10 years. That figure represents the highest 10-year estimate in the report's seven-year history.

An organisation that completes Phase 1 by 2028 has seven years between the CBOM completion date and the 2033 conservative Q-Day estimate. That window is enough to execute Phases 2 and 3 for most organisations if Phase 1 is started now. An organisation that delays Phase 1 until 2027 compresses Phase 2 into a timeline that leaves no margin for the integration delays, vendor dependency gaps, and PKI replacement complexity that arise in every large-scale cryptographic migration.

The data most exposed to HNDL collection includes long-lived confidential records, regulated data with multi-year retention requirements, and anything transmitted over public internet infrastructure that is of interest to state-level adversaries. For a detailed analysis of which data categories carry the highest HNDL exposure and why, see which data is most at risk from HNDL today.

Algorithm Targets: Aligning with NIST FIPS 203, 204, 205, and 206

The NCSC's algorithm recommendations align with the NIST PQC standards. The targets for UK organisations are:

• ML-KEM (NIST FIPS 203) for key encapsulation, replacing RSA and ECDH in key exchange contexts including TLS, IKEv2, and key transport.
• ML-DSA (NIST FIPS 204) for digital signatures, replacing ECDSA and RSA-PSS in certificate chains, code signing, and document signing.
• SLH-DSA (NIST FIPS 205) as a stateless hash-based signature alternative for high-assurance contexts including root CA trust anchors and long-lived audit records, where algorithm diversity relative to ML-DSA's lattice basis is valued.
• FN-DSA (NIST FIPS 206) for applications requiring the smallest possible signature size, including constrained devices and compact signing contexts.

AES-256 is quantum-safe against Grover's algorithm, which provides only a quadratic speedup rather than the exponential speedup Shor's algorithm provides against asymmetric schemes. The migration requirement applies to RSA, ECDH, ECDSA, and related asymmetric algorithms. Replacing AES-256 is not required.

During the migration period, the NCSC recommends hybrid cryptography: combining a classical algorithm (X25519) with a post-quantum algorithm (ML-KEM-768) in a single key exchange. The hybrid combination is specified in IETF RFC 9496 (the X-Wing hybrid KEM). Hybrid deployment provides backward compatibility with systems not yet supporting PQC and HNDL protection for all new sessions from the point of deployment. In TLS 1.3, key exchange is negotiated separately from the certificate, so hybrid key exchange can be deployed without replacing PKI infrastructure. Replacing the PKI — migrating root CAs and intermediate CAs to ML-DSA — is the Phase 2 and 3 workstream; hybrid TLS deployment is the Phase 1 immediate HNDL mitigation.

What to Do Before 2028: The Phase 1 Action List

The Phase 1 deliverable is a documented CBOM and an initial migration plan. The CBOM is the prerequisite for everything that follows; without it, no prioritisation, no dependency mapping, and no gap analysis is possible.

The CBOM must cover: all cryptographic algorithms in use across IT and OT environments; key sizes; protocol contexts; certificate and PKI dependencies; and third-party and supply chain cryptographic interfaces. The NIST NCCoE SP 1800-38B project provides methodology and templates for CBOM construction aligned with the NCSC's Phase 1 scope.

In parallel, organisations should communicate migration needs to cryptographic vendors and suppliers. The NCSC specifically recommends sharing statements of intent publicly to signal demand for PQC-capable products, particularly relevant for OT sectors where PQC product availability lags the IT sector. New procurement contracts from 2025 onwards should include explicit PQC capability requirements or a documented migration path.

Hardware readiness is a prerequisite for Phase 2 CNI migration. FIPS 140-3 validated cryptographic modules supporting ML-KEM and ML-DSA became available from 2025 through the NIST Cryptographic Module Validation Programme (CMVP). For organisations whose security architecture depends on HSMs or hardware roots of trust, confirming the PQC migration roadmap of their HSM vendor is Phase 1 work, not Phase 2.

The NCSC recommends integrating PQC migration with broader cyber resilience improvements and building systems on the principle of cryptographic agility: the ability to transition between algorithms without full system replacement. A system designed for cryptographic agility can respond to future algorithm deprecations at a fraction of the cost of a system where algorithm selection is hardcoded throughout the stack.

A structured gap analysis mapped to the NCSC Phase 1 deliverables, the UK NIS Regulations 2018 obligations, and your sector-specific competent authority expectations is the most direct route to an actionable Phase 1 plan. See the PQC compliance readiness gap analysis for a structured framework.