PQC Migration Guide for UK Organisations in 2025

What Is Post-Quantum Cryptography and Why It Matters Now

Post-quantum cryptography (PQC) refers to cryptographic algorithms designed to resist attacks from both classical computers and future quantum computers. The urgency is not theoretical: the cryptographic primitives that underpin most of today’s secure communications — RSA, elliptic-curve cryptography (ECC), and Diffie-Hellman key exchange — derive their security from mathematical problems (integer factorisation and discrete logarithms) that a sufficiently powerful quantum computer could solve efficiently using Shor’s algorithm.

A cryptographically relevant quantum computer (CRQC) capable of breaking 2,048-bit RSA does not exist today. However, the consensus among government security agencies, including the UK’s National Cyber Security Centre (NCSC) and the US National Institute of Standards and Technology (NIST), is that organisations cannot afford to wait until one appears before beginning migration.

The quantum threat to public-key cryptography

Classical symmetric algorithms such as AES-256 are considered quantum-resistant with key-doubling as a precaution: Grover’s algorithm halves the effective key space, but doubling key length restores the security margin. The more urgent problem is asymmetric cryptography. RSA and ECC — used everywhere from TLS handshakes and code signing to SSH authentication and digital certificates — would be broken by a CRQC running Shor’s algorithm in polynomial time. Replacing them is a multi-year infrastructure programme, not a software patch.

Why ‘harvest now, decrypt later’ attacks make 2025 the tipping point

“Harvest now, decrypt later” (HNDL) describes an adversarial strategy in which encrypted traffic is captured and stored today, with the expectation that it will be decrypted once a CRQC becomes available. For data with a long confidentiality requirement — classified government communications, long-term financial records, patient health data, or intellectual property — this means the effective threat timeline is not “when a CRQC arrives” but right now. If your organisation transmits or stores sensitive data that must remain confidential for ten or more years, HNDL attacks are already a credible risk.

The NCSC’s March 2025 guidance on timelines for migration to post-quantum cryptography explicitly acknowledges this threat model as a primary driver for beginning migration before a CRQC is operational.

How NIST’s finalised PQC standards change the compliance landscape

In August 2024, NIST published three finalised Federal Information Processing Standards (FIPS) for post-quantum cryptography: FIPS 203, FIPS 204, and FIPS 205. This concluded a multi-year evaluation process and removed the principal blocker for enterprise adoption — the absence of stable, standardised algorithms. Organisations that had been deferring PQC planning pending finalised standards now have no remaining justification for delay. The compliance and procurement landscape will shift accordingly: expect contractual, regulatory, and supply-chain requirements tied to these standards to accelerate through 2025 and beyond.

Note: FIPS 206 (covering the FALCON-derived algorithm FN-DSA) was published in October 2024, and NIST continues to evaluate additional candidates including HQC as a backup key-encapsulation mechanism (KEM). Where standards remain in draft or under evaluation, this guide flags them explicitly.

The NIST and NCSC Standards You Need to Know

Before scoping a migration programme, your organisation needs a working understanding of which algorithms have been standardised, what they replace, and what deadlines apply in the UK context.

FIPS 203 (ML-KEM), FIPS 204 (ML-DSA) and FIPS 205 (SLH-DSA) explained

The three primary standards published by NIST’s Cryptographic Standards and Technology (NIST CSRC) project are:

ML-KEM (Module-Lattice-based Key Encapsulation Mechanism) is the primary replacement for RSA and ECDH key exchange. It operates at three security levels: ML-KEM-512, ML-KEM-768, and ML-KEM-1024, roughly corresponding to AES-128, AES-192, and AES-256 security respectively. For most enterprise use cases, ML-KEM-768 is the recommended starting point.

ML-DSA (Module-Lattice-based Digital Signature Algorithm) replaces RSA and ECDSA for digital signatures. It produces larger signatures than classical algorithms but offers strong performance on general-purpose hardware.

SLH-DSA (Stateless Hash-based Digital Signature Algorithm) is a hash-based scheme with conservative security assumptions — it relies only on the security of the underlying hash function, not on lattice hardness assumptions. It is slower and produces larger signatures, making it most appropriate for high-assurance or long-lived signing contexts rather than high-throughput applications.

NIST’s full post-quantum cryptography project documentation is available on the NIST CSRC website and should be treated as the authoritative reference for algorithm parameters and test vectors.

NCSC UK guidance and the 2028 / 2031 / 2035 milestone framework

The NCSC published its most comprehensive PQC migration guidance in March 2025, establishing a three-horizon framework for UK organisations. The milestones are framed as strong recommendations rather than legally binding mandates — the NCSC’s language uses “should” rather than a statutory “must” — but they are expected to be reflected in sector-specific regulatory requirements over time.

The NCSC’s March 2025 timelines document is the primary reference for UK organisations and should be consulted directly for the most current guidance, as the framework is subject to review as the threat landscape develops.

How UK and US timelines align (and where they diverge)

NIST and the US Cybersecurity and Infrastructure Security Agency (CISA) have set a target of deprecating RSA and ECC in government systems by 2030, with a hard cut-off for legacy algorithms by 2035 — broadly consistent with the NCSC framework. The key divergence is in framing: US guidance for National Security Systems is more prescriptive and faster-paced, while NCSC guidance applies more broadly across critical national infrastructure and the wider commercial sector.

For UK organisations, the practical implication is that crypto-agility — designing systems so that cryptographic algorithms can be updated without architectural overhaul — is a shared expectation of both frameworks and should be treated as a design requirement, not an optional enhancement.

Step 1 — Discovery and Cryptographic Inventory

No migration can begin without a clear picture of what you are migrating from. A cryptographic inventory is a structured catalogue of every algorithm, protocol, certificate, key, and cryptographic dependency across your organisation’s systems. As of March 2025, NCSC guidance explicitly positions this as a prerequisite for all subsequent migration activity.

Why a documented cryptographic asset inventory is now mandatory

Consider a mid-size financial services firm with 200 microservices, 15 third-party API integrations, legacy mainframe systems running mutual TLS, and a public key infrastructure (PKI) managing 3,000 employee and server certificates. Without a documented inventory, there is no way to prioritise migration, scope vendor assessments, or produce a credible roadmap for the board. Regulators and cyber insurers are beginning to ask for evidence of this inventory as part of routine assurance activities.

The Post-Quantum Cryptography Coalition (PQCC) migration roadmap framework treats discovery as the non-negotiable foundation of any structured PQC programme, noting that organisations that skip this step consistently underestimate migration scope and cost.

Tools and methods for finding every cipher, protocol and certificate in use

Cipher discovery requires a combination of automated scanning and manual review:

• Network traffic analysis: Tools such as Zeek (formerly Bro), Wireshark, or commercial TLS inspection platforms can identify cipher suites negotiated in live traffic, surfacing any systems still using RSA key exchange or weak elliptic curves.
• Certificate lifecycle management platforms: Products from vendors such as Venafi, Keyfactor, or DigiCert Trust Lifecycle Manager can enumerate all X.509 certificates across the estate, including their key types, expiry dates, and issuing certificate authorities (CAs).
• Code scanning: Static analysis tools (e.g., OWASP Dependency-Check, Semgrep with cryptographic rules) can identify hard-coded cryptographic calls in application code, flagging uses of deprecated libraries or algorithm constants.
• Configuration management database (CMDB) enrichment: Map cryptographic findings back to the CMDB to link algorithms to specific systems, owners, and business processes.
• Hardware security module (HSM) inventory: HSMs store private keys and perform cryptographic operations; many current HSMs do not yet support PQC algorithms. Include HSM firmware versions and vendor PQC roadmaps in scope.

Prioritising systems by risk: data sensitivity and operational criticality

Not all systems carry equal risk. Apply a two-axis prioritisation model:

1. Data sensitivity: Systems handling data with long confidentiality requirements (patient records, classified information, long-term financial data) are most exposed to HNDL attacks and should be migrated first.
2. Operational criticality: Systems where downtime or cryptographic failure would cause significant harm — payment processing, identity and access management, remote access infrastructure — require careful change management but cannot be left until last.

Document your classification scheme and assign a risk score to each system. This becomes the input to your migration sequencing in Step 3 and your board-level reporting.

Step 2 — Assessing Vendors and Third-Party Cryptographic Dependencies

Your organisation’s cryptographic posture is only as strong as its weakest dependency. A PQC-ready internal PKI means little if your payment gateway, cloud provider, or SaaS productivity suite still negotiates RSA-2048 key exchange. Vendor assessment is a distinct workstream that many organisations underestimate.

Questions to ask every vendor about PQC readiness

Develop a standard questionnaire for material vendors and integrate it into procurement and contract renewal cycles. Key questions include:

• Do you have a published PQC migration roadmap aligned to NIST FIPS 203/204/205?
• What is your target date for supporting ML-KEM in TLS key exchange?
• Have you completed a cryptographic inventory of the components you deliver to us?
• What contractual obligations can you offer around PQC readiness milestones?
• Do your HSMs and cryptographic libraries currently support PQC algorithm families?
• How do you handle certificate lifecycle management for certificates issued on your behalf?

Where vendors cannot provide satisfactory answers, escalate to SLA renegotiation or include PQC readiness as a condition of contract renewal. The CMORG UK guidance (June 2025) provides detailed frameworks for incorporating PQC obligations into supplier contracts, with particular emphasis on critical national infrastructure supply chains.

Evaluating protocol support: TLS 1.3, SSH, S/MIME and code signing

Protocol-level PQC readiness varies significantly across the ecosystem as of mid-2025:

• TLS 1.3 hybrid key exchange: The IETF draft for hybrid TLS 1.3 (combining classical ECDH with ML-KEM) is widely supported in test implementations. Google Chrome and Cloudflare have deployed X25519Kyber768 hybrid key exchange in production. Confirm whether your web application firewalls, load balancers, and CDN providers support these hybrid cipher suites.
• SSH: OpenSSH 9.0+ supports the sntrup761x25519 hybrid KEM; migration to ML-KEM-based hybrid SSH is expected as FIPS 203 implementations mature.
• S/MIME and code signing: Certificate authority support for ML-DSA-based certificates is limited as of mid-2025. Monitor CA/Browser Forum developments and plan for dual-signature certificates as a transitional measure.
• Code signing: Software supply chain integrity relies on digital signatures. Organisations signing firmware or software releases should plan ML-DSA adoption early given the long shelf-life of signed artefacts.

Supply-chain cryptographic risk: what the CMORG guidance highlights

The CMORG UK guidance identifies supply-chain cryptographic risk as one of the most underserved areas of current PQC planning. Unlike direct system migration, supply-chain risk is distributed: a vulnerability in a third-party component can undermine a fully migrated internal system. CMORG recommends:

• Including PQC readiness requirements in software bills of materials (SBOMs).
• Requiring vendors of critical components to attest to their cryptographic inventory completion by the 2028 NCSC horizon.
• Treating cryptographic dependencies in open-source libraries with the same rigour as direct vendor contracts.

Step 3 — Selecting a Migration Strategy: Hybrid, Full or Phased

Once you have a prioritised inventory and a view of vendor readiness, the next decision is how to migrate. There is no single correct answer: the right strategy depends on your risk profile, budget, operational constraints, and the maturity of PQC implementations in your technology stack.

Hybrid classical-PQC as a transitional posture

A hybrid classical-PQC posture combines a classical algorithm (e.g., ECDH P-256) with a PQC algorithm (e.g., ML-KEM-768) in a single handshake. The session key is derived from both; security is maintained as long as either algorithm remains unbroken. This approach offers two advantages: it provides immediate protection against HNDL attacks while retaining classical algorithm compatibility for systems that have not yet been updated, and it allows organisations to build operational experience with PQC algorithms before committing to a full migration.

The NCSC endorses hybrid key exchange as an appropriate transitional posture, particularly for internet-facing services ahead of the 2028 horizon. It should not, however, be treated as a permanent end-state — see the FAQ section below on the long-term viability of hybrid cryptography.

Full migration vs. phased migration: trade-offs in cost, downtime and complexity

A full migration replaces all classical asymmetric cryptography with PQC equivalents in a single programme. This is feasible for organisations with a small, well-documented estate and strong change management capability. For most organisations, it carries significant risk of unplanned downtime, compatibility failures, and scope creep.

A phased migration sequences systems according to the risk prioritisation established in Step 1, migrating highest-risk systems first and deferring lower-risk legacy systems to later horizons. This aligns naturally with the NCSC’s three-horizon framework and allows lessons learned from early migrations to inform subsequent phases.

For most UK organisations, a phased approach with hybrid cryptography as an interim posture for critical services is the practical recommendation. Document the phasing explicitly in your roadmap, with named system owners and target completion dates for each horizon.

Bandwidth and storage implications of PQC algorithms (key size increases)

PQC algorithms carry real performance trade-offs that must be factored into infrastructure planning. Based on NIST test vector data:

The bandwidth overhead for a TLS 1.3 handshake using ML-KEM-768 hybrid mode is approximately 2–4 KB additional data compared to a classical ECDH handshake — negligible for most web applications but potentially significant for constrained IoT devices, low-bandwidth industrial control systems, or high-frequency financial messaging protocols. Storage implications are most acute for certificate stores, HSMs with limited key storage, and systems that archive signed documents long-term. Audit your HSM capacity and firmware upgrade path early: HSM compatibility is a common migration blocker.

Building Your PQC Roadmap: Milestones Mapped to NCSC Timelines

The following roadmap maps concrete organisational actions to each of the NCSC’s three migration horizons. Use it as a template and adapt it to your organisation’s size, sector, and risk profile.

2025–2028: immediate actions — inventory, governance and quick wins

This is the foundation horizon. Organisations that do not complete these steps by 2028 will find themselves unable to execute the subsequent phases within the NCSC framework.

• Complete cryptographic inventory: Scope and execute the discovery programme described in Step 1. Target completion by end of 2026 to allow time for risk prioritisation.
• Establish governance: Appoint a named PQC programme owner (typically CISO or deputy). Secure board-level buy-in with a clear business case — HNDL risk to long-lived data is the most compelling argument at board level. Create a steering group with representation from IT, legal, procurement, and risk.
• Update procurement and vendor management: Integrate PQC readiness criteria into all new supplier contracts and major renewals from 2025 onwards.
• Deploy hybrid TLS for internet-facing services: Enable hybrid ML-KEM/ECDH key exchange on public-facing web services and APIs as a quick win that delivers immediate HNDL protection with minimal downtime risk.
• Begin PKI assessment: Engage your certificate authority and PKI team to map the path to ML-DSA certificate issuance. Identify HSM upgrade requirements and lead times.
• Establish a PQC readiness score: Define internal metrics (percentage of systems inventoried, percentage of internet-facing services with hybrid TLS, number of vendor assessments completed) to track progress and report to the board.

2028–2031: core system migration and supplier contractual updates

• Migrate highest-risk systems: Execute migration of the systems identified as highest priority in Step 1 — those handling long-lived sensitive data or forming critical operational infrastructure.
• Complete PKI migration: Issue ML-DSA-based certificates for internal services. Decommission RSA and ECDSA certificate templates where systems support the new algorithm.
• Update supplier contracts: Enforce PQC readiness milestones in supplier SLAs. Require evidence of cryptographic inventory completion from critical suppliers.
• Address HSM and hardware dependencies: Complete HSM firmware upgrades or replacements. Hardware procurement cycles mean any HSM needing replacement should be identified by 2027 at the latest to avoid supply-chain delays.
• Extend migration to SSH, S/MIME and code signing: As ecosystem support matures, migrate internal SSH infrastructure, email signing, and software release pipelines to PQC algorithms.

2031–2035: full transition and legacy system decommission

• Migrate or isolate remaining legacy systems: Systems that cannot be migrated — due to vendor end-of-life, embedded hardware constraints, or prohibitive cost — should be isolated from networks carrying sensitive data and scheduled for decommission.
• Decommission RSA and ECC infrastructure: Remove classical asymmetric algorithm support from internal CA policies, VPN configurations, and application cryptographic libraries.
• Achieve continuous monitoring posture: Crypto-agility requires ongoing monitoring to detect certificate expiry, algorithm regressions introduced by software updates, and new dependencies introduced by third-party components. Embed cryptographic monitoring into your security operations function.
• Review against updated standards: By 2031–2035, NIST and NCSC guidance will have evolved. Review your programme against updated standards, including any new algorithm standardisations or deprecations.

Common Pitfalls and How to Avoid Them

The most instructive lessons from early PQC migration programmes come from what went wrong. The following failure modes are well-documented in practitioner literature and warrant explicit attention in your planning.

Treating PQC as a one-off IT project rather than a continuous posture

PQC migration is not a project with a defined end date after which cryptographic risk is resolved. The threat landscape, algorithm recommendations, and vendor capabilities will continue to evolve through and beyond the 2035 horizon. Organisations that treat it as a time-boxed project — stand up a project team, migrate systems, close the programme — will find themselves in the same position in five years when the next wave of algorithm deprecations arrives.

Crypto-agility — the capability to update cryptographic algorithms across your estate without major re-engineering — is the sustainable answer. Design new systems with algorithm abstraction layers. Avoid hard-coding algorithm identifiers in application code or configuration. Monitor certificate expiry and algorithm health as a continuous operational activity, not a project deliverable.

Overlooking operational technology (OT) and IoT devices

OT security and IoT cryptography present distinct challenges that standard IT migration approaches do not address. Programmable logic controllers (PLCs), building management systems, medical devices, and industrial sensors may run firmware that is difficult or impossible to update in the field, may lack the computational resources to run lattice-based algorithms, and may operate on 10–20 year lifecycles that extend well beyond the 2035 NCSC horizon.

These systems require a separate track in the migration roadmap: identify OT and IoT assets during the cryptographic inventory, assess their algorithm update capability, and — where migration is not feasible — implement network segmentation and monitoring as compensating controls. Do not assume that a standard PKI migration programme will automatically cover embedded devices: it will not.

Confusing quantum-resistant with quantum-proof: setting realistic expectations

“Quantum-resistant” means that no known quantum algorithm breaks the scheme in polynomial time — it does not mean the algorithm is unconditionally secure or permanently safe. CRYSTALS-Kyber (now ML-KEM) and CRYSTALS-Dilithium (now ML-DSA) are lattice-based; their security rests on the hardness of lattice problems, which, while widely studied, remains an active area of research. NIST’s decision to retain SLH-DSA (hash-based) alongside lattice algorithms reflects precisely this prudence — a hedge against future advances in lattice cryptanalysis.

Set expectations accordingly within your organisation: PQC migration substantially raises the bar against quantum attack, but cryptographic agility must be maintained to respond to future developments. Avoid communicating to stakeholders that completing migration by 2035 means cryptographic risk is “solved.”

Frequently Asked Questions About PQC Migration

When must UK organisations comply with NCSC PQC guidance?

The NCSC’s PQC migration timelines (March 2025) are framed as strong recommendations rather than statutory obligations. The guidance uses “should” language throughout, and the milestones — 2028, 2031, and 2035 — are targets rather than legal deadlines. However, sectors regulated by bodies such as the FCA, NHS Digital, or the ICO may see these milestones incorporated into sector-specific requirements over time. Organisations in critical national infrastructure should treat the 2028 horizon as a de facto operational requirement given the pace of regulatory alignment.

Which NIST PQC algorithms should I implement first?

For most organisations, ML-KEM (FIPS 203) should be the first priority, deployed in hybrid mode for TLS key exchange on internet-facing and high-risk internal services. This addresses the HNDL threat most directly. ML-DSA (FIPS 204) should be prioritised for code signing and certificate issuance as ecosystem support matures. SLH-DSA (FIPS 205) is appropriate for high-assurance, low-throughput signing contexts such as root CA operations or firmware signing for long-lived devices.

How does PQC migration affect digital certificates and PKI?

PKI migration is one of the most complex aspects of the transition. Today’s X.509 certificates use RSA or ECDSA keys; migrating to PQC requires certificate authorities to support ML-DSA or SLH-DSA key types, relying parties to accept and validate these new certificate formats, and all intermediate CAs, OCSP responders, and CRL infrastructure to be updated. As of mid-2025, major public CAs are piloting PQC certificate issuance but have not yet achieved broad production support. Plan for a period of dual-algorithm operation — issuing both classical and PQC certificates — as a transitional measure, and engage your CA vendor early to understand their roadmap and migration support.

Is hybrid cryptography safe as a long-term solution?

Hybrid cryptography is safe and appropriate as a transitional solution, but it is not recommended as a permanent end-state. Running two algorithms in parallel increases handshake size, adds implementation complexity, and introduces additional attack surface at the protocol level. More importantly, the NCSC framework explicitly targets full PQC migration by 2035; retaining classical algorithms beyond that horizon would leave systems exposed once a CRQC becomes operational. Treat hybrid mode as a bridge to full migration, not a destination.