PQC Migration Guide 2025: Steps for Organisations

Why PQC Migration Can’t Wait Until 2025

Most organisations think of quantum computing as a distant threat. The more accurate framing is that the threat to your encrypted data has already started — the quantum computer is simply the tool that will eventually unlock it.

The ‘Harvest Now, Decrypt Later’ Threat Explained

Harvest now, decrypt later (HNDL) is an attack strategy in which adversaries collect encrypted traffic today, store it, and decrypt it once a cryptographically relevant quantum computer (CRQC) becomes available. No credible source has confirmed when a CRQC will exist; estimates vary widely across the research community. What is confirmed is that data with long confidentiality requirements — classified records, patient data, legally privileged communications, long-term financial transactions — is already at risk if it is being exfiltrated from your networks now.

This means that even organisations whose day-to-day operations would tolerate a longer migration timeline must treat HNDL as a present-tense problem. Any data that must remain confidential beyond roughly a decade warrants urgent attention today.

Why Organisations Acting Now Gain a Competitive and Compliance Edge

Beyond the threat model, there is a straightforward compliance and commercial rationale for early action. The NCSC published its Timelines for migration to post-quantum cryptography guidance in March 2025, establishing a phased migration schedule with mandatory checkpoints. Organisations that begin discovery and planning now will be better positioned to meet the 2028 milestone without costly emergency programmes.

Cryptographic agility — the ability to swap algorithms and key lengths without rearchitecting systems — is increasingly being treated as an architectural requirement in procurement and partner due diligence. Demonstrating a structured PQC programme is becoming a differentiator in enterprise sales cycles, particularly in financial services and critical national infrastructure supply chains.

Key Drivers: NIST Finalisation, NCSC Roadmap, EU Regulatory Signals

Three converging forces are making 2025 the decisive year to act:

• NIST finalisation: FIPS 203, FIPS 204, and FIPS 205 were published in August 2024. These are current, ratified standards — not drafts. Treating them as future work is no longer accurate.
• NCSC roadmap: The NCSC has defined a phased migration schedule (2028, 2031, and 2035) that governs UK government bodies and, through supply-chain obligations, many private-sector organisations that serve them.
• EU regulatory signals: ANSSI (France) and BSI (Germany) have each published their own PQC migration recommendations, and ENISA has flagged quantum-vulnerable algorithms in sector-level risk assessments. EU-based organisations or those with EU regulatory exposure should expect these signals to harden into requirements.

Against this backdrop, quantum-vulnerable algorithms — RSA, ECC, and classical Diffie-Hellman — remain widely deployed across TLS stacks, PKI hierarchies, VPN gateways, and code-signing pipelines. The window for a managed, cost-effective migration is open now; it will narrow significantly as deadlines approach.

Understanding the NIST and NCSC PQC Standards Landscape

Before choosing an algorithm or a migration path, it is essential to understand what has actually been standardised, what is still in progress, and what the relevant authorities expect your organisation to do with that information.

NIST FIPS 203, 204, 205: What Each Standard Covers

NIST’s August 2024 publications represent the first generation of post-quantum cryptography standards for general use:

A fourth standard, FIPS 206 (ML-KEM’s companion, covering FALCON under the name FN-DSA), was published in August 2024 alongside the first three. ML-KEM is the primary recommendation for key encapsulation; ML-DSA is the default signature choice for most use cases. SLH-DSA is slower but rests on more conservative security assumptions — it is appropriate where long-term algorithm confidence is paramount, such as root CA certificates. NIST IR 8547 provides further guidance on algorithm selection and transition.

NCSC UK Guidance and Phased Migration Timelines (2028 / 2031 / 2035)

The NCSC’s March 2025 guidance establishes three milestones that should sit at the centre of any UK organisation’s migration planning:

• By 2028: Organisations should have completed a full cryptographic inventory, identified their highest-priority quantum-vulnerable systems, and begun migration of critical assets. For government bodies, the NCSC is explicit that this is a mandatory checkpoint, not a recommendation.
• By 2031: The majority of high-value systems — those handling sensitive personal data, classified information, or long-lived financial records — should have completed migration to NIST-standardised PQC algorithms.
• By 2035: Full deprecation of quantum-vulnerable public-key algorithms is expected across all in-scope systems. After this point, continued use of RSA, ECC, or classical Diffie-Hellman in new deployments will be non-compliant with NCSC expectations.

For private-sector organisations that are not directly bound by NCSC mandates, these milestones remain the most authoritative planning reference in the UK market. Supply-chain contracts, FCA expectations for financial services firms, and procurement requirements from government clients are all likely to reference this timeline.

IETF and ETSI Standards in Motion: What to Watch

Alongside the NIST standards, the IETF published its Guidance for Migration to Post-Quantum Cryptography in July 2025, providing protocol-level detail on integrating PQC algorithms into TLS, SSH, and related internet standards. The document is an essential reference for engineering teams working on TLS 1.3 deployments and PKI migration. ETSI is developing complementary guidance focused on European regulatory contexts, particularly for telecommunications and critical infrastructure. Both bodies should be tracked as their outputs will shape vendor product roadmaps.

One important distinction to maintain throughout your migration planning: post-quantum cryptography (mathematical algorithms resistant to quantum attack) is a separate and complementary approach to quantum key distribution (QKD), which uses quantum physics to distribute keys. The NCSC and NIST both recommend PQC as the primary migration path; QKD has its own niche application cases but is not a substitute for algorithm migration.

Phase 1 — Discovery and Cryptographic Inventory

The NIST NCCoE’s migration project and the TNO PQC Migration Handbook (December 2024) both identify cryptographic discovery as the essential first step — and the step most organisations underestimate in scope. You cannot prioritise what you have not found.

How to Identify Quantum-Vulnerable Public-Key Algorithms Across Your Estate

Quantum-vulnerable algorithms are those that rely on mathematical problems — integer factorisation (RSA), discrete logarithm (classical Diffie-Hellman), and elliptic curve discrete logarithm (ECC) — that a sufficiently powerful CRQC would solve efficiently. Symmetric algorithms (AES-256, SHA-384 and above) are not considered quantum-vulnerable in the same sense; they are expected to remain secure with appropriate key-length adjustments.

Your inventory scope should cover:

• TLS certificates and the cipher suites negotiated across web services, APIs, and internal service meshes
• PKI hierarchies, including root CAs, intermediate CAs, and issuing CAs
• Code-signing certificates and the keys used to sign software artefacts, firmware, and container images
• VPN gateways and the key exchange protocols they use (IKEv2, WireGuard)
• SSH host keys and user authentication keys
• Data-at-rest encryption that uses RSA-wrapped keys
• Hardware security modules (HSMs) and their supported algorithm sets
• Third-party and SaaS integrations that handle key exchange or signing on your behalf

Tools and Techniques for Cryptographic Discovery (CBOMs, Scanners)

A Cryptography Bill of Materials (CBOM) — a structured machine-readable inventory of cryptographic assets, analogous to a Software Bill of Materials (SBOM) — is the most scalable approach for large estates. Several open-source tools (including IBM’s CBOM tooling and outputs from the PQCC’s working groups) can parse source code, container images, and network traffic to generate CBOM artefacts. These are particularly valuable when combined with continuous integration pipelines, so that new cryptographic dependencies are flagged at build time rather than discovered retrospectively.

For network-layer discovery, TLS scanning tools can enumerate the cipher suites and certificate types in use across externally facing and internal endpoints. Static analysis tools can identify algorithm usage in source code and dependencies. Where source code is unavailable (legacy systems, COTS software), network traffic analysis and vendor documentation become the primary sources.

Tool and vendor mentions here are illustrative; organisations should evaluate options against their own security and procurement requirements.

Prioritising Assets: Data Sensitivity, Longevity, and Exposure

Not every system needs to be migrated on the same schedule. A practical prioritisation framework considers three factors:

1. Data longevity: How long must this data remain confidential? Records that need protection beyond ten years are highest priority given the HNDL threat.
2. Data sensitivity: Personal health records, legally privileged communications, and classified information warrant the fastest migration regardless of system age.
3. Exposure: Internet-facing systems that handle key exchange are more likely to be targets for traffic harvesting than air-gapped internal systems.

The intersection of high longevity, high sensitivity, and high exposure defines your critical path. Root CA keys and the TLS infrastructure protecting long-term data stores will typically sit at the top of this list.

Phase 2 — Migration Strategy Selection

Once you have a prioritised inventory, the next decision is which migration path to take for each system type. The choice is not binary, and the right answer depends on your operational constraints, your vendors’ readiness, and the specific risk profile of each asset.

Direct Migration vs. Hybrid Cryptography: When to Use Each

Direct migration replaces classical public-key algorithms with their PQC equivalents entirely. It is cleaner, simpler to audit, and avoids the overhead of running two cryptographic systems simultaneously. The drawback is that it requires both endpoints in a communication channel to support PQC — which is not yet universally the case across browsers, operating systems, and network appliances.

Hybrid cryptography combines a classical algorithm with a PQC algorithm such that security is maintained if either component remains secure. If the PQC algorithm has an undiscovered flaw, the classical component provides a fallback; if the classical algorithm is broken by a CRQC, the PQC component protects the session. Hybrid schemes are the recommended approach during the transition period, particularly for TLS, where client compatibility is heterogeneous.

A practical decision rule:

• Use hybrid where you cannot guarantee both endpoints will have PQC support, where rollback risk is high, or where the system is customer-facing and backward compatibility is required.
• Use direct migration for internal, organisation-controlled systems where you can coordinate both sides simultaneously, and for new deployments where there is no legacy constraint.

Hybrid Key Encapsulation Mechanisms (KEMs) and Composite Signatures

At the protocol level, hybrid key encapsulation mechanisms combine a classical KEM (typically X25519 for elliptic curve) with ML-KEM. The combined scheme, sometimes referred to as X25519Kyber768 (or its IETF-standardised successors), is already available in recent versions of major TLS libraries including BoringSSL and OpenSSL 3.x, and is the default in current Chrome and Firefox releases for TLS key exchange.

For signatures, composite signatures bind a classical signature algorithm to an ML-DSA or SLH-DSA signature in a single cryptographic object. This approach is being standardised through IETF and is particularly relevant for long-lived certificate chains, where a root CA signed with a composite algorithm can be validated by both PQC-capable and classical verifiers during the transition window.

Cryptographic agility — building systems so that algorithms can be updated through configuration rather than code changes — is the architectural principle that makes hybrid schemes sustainable. Without it, each algorithm change becomes a bespoke engineering project.

Vendor and Supply-Chain Readiness: Questions to Ask Your Providers

Supply-chain cryptography is one of the most commonly overlooked dimensions of PQC migration. Your own systems may be migrated, but if your HSM vendor, certificate authority, VPN appliance supplier, or SaaS platform has not updated their cryptographic stack, you remain exposed.

Key questions to put to vendors:

• Do your products support FIPS 203 (ML-KEM) and FIPS 204 (ML-DSA) today, or what is your roadmap for support?
• Have your HSMs been updated or certified to handle PQC key sizes and operations at production throughput?
• Do you publish a CBOM or SBOM covering cryptographic dependencies in your software?
• What hybrid transition options do you offer, and how long will you support classical-only configurations?
• How will algorithm updates be delivered — firmware patch, software update, or hardware replacement?

The PQCC’s migration roadmap includes vendor readiness as a core dimension and is a useful benchmark for evaluating supplier responses.

Phase 3 — Pilot Implementation and Testing

A controlled pilot is essential before committing to broad rollout. It surfaces integration issues, quantifies performance impacts, and builds internal expertise that will be critical during full-scale migration. The question most organisations get wrong is not whether to pilot, but where to pilot first.

Selecting Pilot Systems: TLS, PKI, Code Signing, or VPN First?

The optimal starting point depends on your risk profile and your vendor ecosystem’s current state of readiness:

• TLS (web and API services): The highest-visibility and most ecosystem-ready starting point. Browser and library support for hybrid key exchange (X25519 + ML-KEM) is already live in major clients. A TLS pilot on a non-critical web service or internal API gateway gives early performance data with low blast radius.
• PKI: More complex but high-impact. Issuing a test PQC-capable sub-CA beneath an existing root CA allows you to evaluate certificate lifecycle management tooling, OCSP and CRL compatibility, and HSM performance without touching production certificate chains. Note that full PKI migration — including replacing root CAs — is a long-horizon project given root certificate trust store propagation timelines.
• Code signing: An excellent early candidate because it is largely internal, the verifier set is controlled (your own build and deployment systems), and the consequences of a failed signature are visible and recoverable in a test environment.
• VPN: IKEv2 has published hybrid PQC extensions, and several enterprise VPN vendors now support them. A site-to-site VPN pilot between two organisation-controlled endpoints is lower risk than a remote-access VPN rollout affecting thousands of endpoints with heterogeneous client software.

Performance Benchmarking: Latency and Key-Size Impacts of PQC Algorithms

PQC algorithms carry different performance characteristics from their classical equivalents. Understanding these trade-offs before rollout prevents surprises in production:

The key takeaway for TLS: ML-KEM’s computational overhead is lower than RSA-2048, but the larger key and ciphertext sizes increase TLS handshake byte counts. For most modern network connections this is immaterial, but constrained environments — IoT devices, satellite links, high-frequency trading networks — warrant careful measurement. SLH-DSA’s large signature sizes make it unsuitable for high-throughput signing operations; ML-DSA is the practical default for most signature use cases.

During your pilot, benchmark TLS handshake latency, certificate chain validation time, HSM signing throughput, and any impact on session resumption rates. Run regression testing across your full application stack — PQC-related breakage often surfaces in unexpected places, such as TLS inspection proxies that do not yet support larger handshake messages.

Common Implementation Pitfalls and How to Avoid Them

• TLS inspection breakage: Many enterprise web proxies and DLP tools perform TLS inspection by re-encrypting traffic with their own certificates. If these appliances do not support PQC cipher suites or larger handshake messages, they will silently fail or block connections. Audit your inspection stack before rollout.
• HSM capacity limits: Older HSMs may not support PQC key generation or may handle the larger key structures at significantly reduced throughput. Validate HSM firmware versions and performance profiles early.
• Certificate chain size: PQC certificates and their chains are larger than RSA equivalents. Some clients impose hard limits on TLS record or certificate sizes — test across your full client population.
• Algorithm misidentification: Ensure that all tooling and documentation uses the FIPS algorithm names (ML-KEM, ML-DSA, SLH-DSA) rather than the earlier competition names (Kyber, Dilithium, SPHINCS+). Tooling that references deprecated names may not be current.

Phase 4 — Enterprise-Wide Rollout and Governance

Technical readiness is necessary but not sufficient for a successful migration at scale. Without clear ownership, defined decision rights, and a governance structure aligned to your NCSC deadlines, migration programmes stall when they move beyond the pilot team.

Building a PQC Programme: Roles, Ownership, and Steering Committee

A PQC programme requires representation across functions that rarely sit in the same room:

• Chief Information Security Officer (CISO) or equivalent: Programme sponsor and accountable executive. Ensures migration receives budget and board visibility.
• Cryptography lead or architect: Technical authority on algorithm selection, hybrid schemes, and FIPS compliance. In smaller organisations this may be an external specialist.
• PKI and certificate management team: Responsible for certificate lifecycle management tooling, CA hierarchy changes, and HSM operations.
• Infrastructure and network engineering: Owns TLS configurations, VPN gateways, and network appliance firmware roadmaps.
• Procurement and vendor management: Drives PQC readiness questions into vendor contracts and renewal cycles.
• Legal and compliance: Monitors NCSC mandatory requirements, FCA guidance for financial services firms, and GDPR obligations relating to cryptographic data protection.
• Steering committee: A cross-functional body meeting quarterly (at minimum) to review progress against milestones, resolve resource conflicts, and escalate blockers to the executive sponsor.

Aligning Migration Milestones With NCSC 2028 and 2031 Deadlines

Working backwards from the NCSC’s milestones:

• 2025–2026: Complete cryptographic inventory (Phase 1), finalise migration strategy, complete vendor readiness assessments, and run pilots on highest-priority systems.
• 2026–2027: Begin migration of critical-priority systems (long-lived data stores, root PKI infrastructure, code-signing pipelines). Integrate PQC requirements into procurement and contract renewal cycles.
• 2028 (NCSC checkpoint): Critical systems migrated or actively in migration. Full inventory documented and maintained. PQC programme governance in place and reporting to board level.
• 2029–2030: Migrate remaining high-value systems. Retire classical-only configurations on systems where PQC support is confirmed on all endpoints.
• 2031 (NCSC checkpoint): Majority of high-value systems on PQC. Classical-only algorithm use restricted to legacy systems under approved exception process.
• 2035: Full algorithm sunset. Quantum-vulnerable public-key algorithms deprecated across all in-scope systems.

Ongoing Cryptographic Agility: Staying Ready for Algorithm Updates

PQC standards are not static. NIST has already indicated that additional algorithms — particularly further signature schemes — are under evaluation. The ability to update algorithms without major re-engineering is not just a transition-period concern; it is a permanent architectural requirement.

Agile cryptography in practice means: centralising algorithm configuration rather than hardcoding it in application code; maintaining a live CBOM that is updated with each software release; and building algorithm sunset dates into your certificate lifecycle management processes so that deprecated configurations are flagged automatically. The steering committee should review the algorithm landscape at least annually, tracking IETF, NCSC, and NIST publications for updates that require programme adjustments.

Sector-Specific Considerations for PQC Migration

Financial Services: Lessons From Mastercard’s Migration Pathway

Financial services organisations face a combination of high data sensitivity, long record-retention requirements, and intense regulatory scrutiny that makes them among the highest-priority sectors for PQC migration. Mastercard has publicly described a phased migration approach that began with inventory and moved through hybrid deployment in payment authentication infrastructure — a model that illustrates the practical sequencing of a large, complex programme.

For UK financial services firms, the FCA’s operational resilience framework and data protection obligations under UK GDPR create a compliance context in which cryptographic failures carry regulatory consequence, not just operational risk. Firms should anticipate that FCA supervisory expectations will increasingly reference NCSC PQC guidance as the 2028 deadline approaches. Engaging with the FCA’s innovation and technology teams early — rather than waiting for formal guidance — is advisable for firms with complex cryptographic estates.

Critical National Infrastructure and Government: NCSC Mandatory Requirements

For CNI operators and government bodies, the NCSC’s PQC migration timeline carries mandatory weight that it does not (yet) carry for the general private sector. The NCSC’s March 2025 guidance is explicit that organisations in scope for the UK Government Security Classifications policy and those operating under CNI sector-specific frameworks should treat the 2028 milestone as a compliance deadline rather than a planning target.

CNI operators in energy, water, transport, and telecoms should also note that their operational technology (OT) environments present particular challenges: many OT systems use embedded cryptography that cannot be updated through a software patch and may require hardware replacement. Factoring hardware refresh cycles — which can span five to fifteen years in OT environments — into migration planning is essential.

Healthcare and Legal: Long-Retention Data at Highest Risk

Healthcare and legal sectors are underrepresented in PQC migration discussions relative to their actual risk exposure. Both sectors hold data with exceptionally long confidentiality requirements: patient records in the NHS must be retained for decades; legally privileged communications in major litigation may need to remain confidential for the lifetime of the parties involved.

Under UK GDPR, the obligation to implement “appropriate technical measures” to protect personal data extends to protecting it against foreseeable future threats — an obligation that the Information Commissioner’s Office (ICO) is expected to interpret in light of emerging NCSC guidance on quantum threats. Healthcare data controllers and law firms handling sensitive client matters should treat HNDL as a current data protection risk, not a speculative future one, and should prioritise PQC migration for their longest-lived encrypted data stores accordingly.

Frequently Asked Questions About PQC Migration

What is PQC migration and why does it matter for organisations in 2025?

PQC migration is the process of replacing classical public-key algorithms — RSA, ECC, and Diffie-Hellman — with cryptographic standards that are resistant to attack by quantum computers. It matters in 2025 because NIST finalised the first three PQC standards (FIPS 203, 204, and 205) in August 2024, the NCSC has set a 2028 milestone for UK organisations, and the harvest now, decrypt later threat means that data with long confidentiality requirements is already at risk from adversaries collecting encrypted traffic today.

Which NIST post-quantum cryptography algorithms have been standardised?

Three algorithms are now standardised: ML-KEM (FIPS 203, formerly known as CRYSTALS-Kyber) for key encapsulation; ML-DSA (FIPS 204, formerly CRYSTALS-Dilithium) for digital signatures; and SLH-DSA (FIPS 205, formerly SPHINCS+) for hash-based stateless signatures. A fourth standard, FN-DSA (FIPS 206, formerly FALCON), was also published in August 2024. ML-KEM and ML-DSA are the primary choices for most use cases.

What are the NCSC’s mandatory deadlines for migrating to post-quantum cryptography?

The NCSC’s March 2025 guidance sets three milestones: 2028 (critical systems inventoried and migration underway), 2031 (majority of high-value systems migrated), and 2035 (full deprecation of quantum-vulnerable algorithms). For UK government bodies and CNI operators, the 2028 milestone is mandatory. Private-sector organisations should treat these dates as the authoritative planning reference for the UK market.

What is ‘harvest now, decrypt later’ and how does it affect my organisation today?

Harvest now, decrypt later is an attack in which adversaries collect and store encrypted data today, intending to decrypt it once a cryptographically relevant quantum computer becomes available. It affects organisations now because any data with long confidentiality requirements — health records, legal communications, classified government data, long-term financial records — may already be being harvested. The threat is not theoretical; the collection is happening today, even though the decryption capability does not yet exist.

How do I perform a cryptographic inventory of my systems?

Start by defining your scope: TLS certificates, PKI hierarchies, code-signing keys, VPN gateways, SSH keys, HSMs, and third-party integrations. Use TLS scanning tools for network-layer discovery, static analysis tools for source code, and Cryptography Bills of Materials (CBOMs) for a structured, machine-readable inventory. Prioritise assets by data longevity, sensitivity, and network exposure. The NIST NCCoE migration project and TNO’s PQC Migration Handbook both provide detailed discovery frameworks.

Should I use hybrid cryptography or migrate directly to PQC algorithms?

Use hybrid cryptography where you cannot guarantee PQC support on both ends of a connection, where backward compatibility with existing clients is required, or where rollback risk is high — TLS for public-facing services is the clearest example. Use direct migration for internal, organisation-controlled systems where you can coordinate both endpoints simultaneously, and for all new deployments. Hybrid schemes are the IETF and NCSC-recommended approach during the transition period.

How much does PQC migration cost and how long does it take?

Costs and timelines vary enormously depending on estate complexity, vendor readiness, and in-house expertise. Discovery alone can take three to six months for a mid-size organisation with a heterogeneous estate. Full migration to the 2031 NCSC milestone implies a six-to-seven-year programme for most large organisations, with the majority of engineering effort concentrated in PKI, TLS infrastructure, and HSM upgrades. Organisations that delay will face higher costs as the 2028 deadline creates demand for specialist expertise and vendor capacity.