PQC Migration Guide 2025: Prepare Your Organisation

Why Post-Quantum Cryptography Migration Is Urgent in 2025

The quantum threat to current public-key cryptography

Almost every secure connection on the internet — HTTPS sessions, VPN tunnels, code-signing certificates, encrypted email — relies on the computational hardness of two mathematical problems: integer factorisation (RSA) and the elliptic-curve discrete logarithm (ECC). A sufficiently powerful quantum computer running Shor’s algorithm could solve both in polynomial time, rendering every certificate, key exchange, and digital signature that depends on them cryptographically worthless.

That machine — a cryptographically relevant quantum computer (CRQC) — does not exist today. RSA-2048 and current ECC curves are not under immediate attack. The urgency stems from something more subtle: the long tail of data that is encrypted today but must remain confidential for years or decades to come.

Harvest Now, Decrypt Later: why waiting is already too late

The harvest now, decrypt later (HNDL) attack is straightforward in principle. An adversary captures and stores ciphertext today — bulk TLS traffic, sensitive government communications, intellectual property — and waits until a CRQC is available to decrypt it retrospectively. The attack requires no current quantum capability; it only requires that the harvested data still has value when that capability eventually arrives.

If your organisation handles data that must remain confidential beyond 2030 — financial records, health data, legal communications, defence-sensitive material — that data is already at risk from adversaries with long-term storage programmes. Migration timelines measured in years mean that organisations which start planning in 2025 will still be mid-transition when quantum capabilities mature. Starting later compounds that gap.

Key regulatory triggers: NIST FIPS 203/204/205 and NCSC guidance

Two regulatory anchors have turned PQC migration from a theoretical consideration into a compliance obligation:

• NIST finalised three PQC standards in August 2024: FIPS 203 (ML-KEM, for key encapsulation), FIPS 204 (ML-DSA, for digital signatures), and FIPS 205 (SLH-DSA, a stateless hash-based signature scheme). These are published, stable standards — not drafts.
• The NCSC published its migration timeline guidance in March 2025, setting explicit milestones at 2028, 2031, and 2035 for UK organisations, with particular obligations for critical national infrastructure (CNI). The document is authoritative, public, and increasingly referenced in procurement and audit frameworks.

Together, these two bodies have removed the principal reason organisations deferred action: the absence of stable standards to migrate to. That reason no longer holds.

Understanding the NIST and NCSC PQC Standards Landscape

The three finalised NIST PQC algorithms at a glance

The NIST Post-Quantum Cryptography project concluded its multi-year standardisation process with three published FIPS standards. Understanding what each algorithm does — and does not — cover is essential before mapping them to your systems.

ML-KEM is the workhorse for protecting data in transit — it replaces the Diffie-Hellman and ECDH key exchanges used in TLS, SSH, and similar protocols. ML-DSA is the primary candidate for most signature use cases, including code signing and PKI hierarchies. SLH-DSA offers a mathematically distinct, hash-based alternative for contexts where a second family of signatures is warranted as a hedge against lattice vulnerabilities.

It is worth noting that NIST continues to evaluate additional signature algorithms as supplementary standards. The current three represent the minimum viable set for migration planning, not a closed list.

NCSC UK migration timelines: 2028, 2031, and 2035 milestones

The NCSC’s March 2025 guidance on timelines for migration to post-quantum cryptography structures obligations around three milestone years. These are not aspirational targets — they are the basis against which UK government departments and CNI operators are expected to demonstrate progress.

• By 2028: Organisations should have completed a cryptographic asset inventory, assessed their exposure to HNDL risks, and have a documented migration plan approved at a senior level.
• By 2031: Critical systems — those handling the most sensitive data or forming part of CNI — should have completed migration to quantum-safe cryptography.
• By 2035: Full estate migration should be complete, and legacy cryptography (RSA, ECC-based key exchange) should be deprecated across all in-scope systems.

Private sector organisations outside direct government scope should treat these milestones as the de facto industry standard, since supply chain requirements and certification frameworks (Cyber Essentials, ISO 27001 updates, financial sector guidance) will increasingly reflect them.

How FIPS 203 (ML-KEM), FIPS 204 (ML-DSA) and FIPS 205 (SLH-DSA) map to use cases

Mapping algorithms to use cases is not a purely technical exercise — it has procurement, testing, and operational implications. A rough mapping for common enterprise scenarios:

• TLS and HTTPS traffic protection: ML-KEM for key encapsulation; ML-DSA for certificate signatures.
• Code signing and firmware integrity: ML-DSA as primary; SLH-DSA as a secondary hedge in high-assurance contexts.
• PKI certificate authorities: ML-DSA for CA and end-entity certificates; consider larger key sizes for long-lived root CAs.
• Constrained IoT devices: Performance and memory overhead of lattice-based cryptography may require careful benchmarking; SLH-DSA has higher signature sizes but lower key-generation overhead in some profiles.
• VPNs and remote access: ML-KEM for key exchange within IKEv2 or WireGuard; check vendor roadmaps for RFC-compliant hybrid modes.

The PQC standardisation process deliberately produced algorithms suited to different performance and security profiles. Selecting the right algorithm for the right context — rather than applying a single standard everywhere — is part of a mature migration strategy.

Phase 1 — Discovery and Cryptographic Inventory

What a cryptographic asset inventory covers

A cryptographic inventory — sometimes called a cryptographic bill of materials (CBOM) — is a structured record of every cryptographic mechanism in use across your estate. It is the prerequisite for every subsequent phase of migration; without it, risk assessment and triage are guesswork.

A complete CBOM captures:

• All cryptographic algorithms in use (symmetric ciphers, asymmetric algorithms, hash functions, MACs)
• Key lengths and parameters for each algorithm instance
• Protocol versions (TLS 1.2 vs 1.3, SSH version, IPsec profile)
• Certificate details: issuing CA, validity period, key type, algorithm
• Certificate lifecycle data: issuance date, expiry, renewal processes
• Where cryptography is implemented: OS libraries, application-layer code, hardware security modules (HSMs), firmware
• Dependencies: third-party libraries (OpenSSL version, BoringSSL, native language crypto APIs)

The scope should extend beyond servers and endpoints to include network appliances, cloud workloads, CI/CD pipelines, IoT devices, and any SaaS services that handle key material on your behalf.

Tools and methods for automated cryptographic discovery

Cipher enumeration at scale requires tooling. Manual inventory is feasible only for small estates — for anything larger, automated discovery reduces both the time required and the risk of gaps. Approaches include:

• Network scanning: Tools such as testssl.sh, SSLyze, or commercial scanners can enumerate TLS cipher suites, protocol versions, and certificate properties across exposed services.
• PKI platform reporting: Certificate authorities and PKI management platforms (whether on-premises or cloud-hosted) can generate inventory exports covering all issued certificates within their scope.
• SBOM/CBOM tooling: Emerging tooling derived from software bill of materials (SBOM) practices can identify cryptographic dependencies in application code and container images.
• Agent-based endpoint discovery: Endpoint agents can enumerate cryptographic libraries and their versions, flagging RSA key lengths below threshold or deprecated algorithms.

No single tool covers the full estate. A defensible inventory methodology combines network scanning, PKI platform exports, and code-level dependency scanning, reconciled against a central asset register.

Documenting ciphers, protocols, and key lengths (mandatory post-March 2025)

The NCSC’s March 2025 guidance treats a documented cryptographic inventory as a prerequisite for the 2028 milestone, not an optional preliminary step. Organisations subject to that guidance — and those in their supply chains — should treat the inventory as a live document rather than a one-time audit output.

Documentation should record not only what algorithms are in use, but why specific choices were made, which business process or system owner is responsible for each cryptographic asset, and what the remediation path is when that algorithm reaches end-of-life. This metadata is what transforms a technical scan report into a governance artefact that a CISO or auditor can act on.

Phase 2 — Risk Assessment and Migration Triage

Prioritising systems by data sensitivity and longevity

Not every system carries equal migration urgency. Risk classification should reflect two intersecting dimensions: the sensitivity of the data protected and the period over which that data must remain confidential.

A simple triage matrix:

Systems in the “Critical” cells represent your first migration wave and should be the primary focus before the 2028 inventory deadline.

Identifying long-lived data at highest harvest-now risk

Data longevity is the key variable in HNDL exposure. Categories that consistently fall into high-risk bands include: legal privilege communications, clinical records, biometric identity data, cryptographic key material itself (particularly private keys for long-lived CA certificates), and any data subject to statutory retention periods longer than ten years.

For these categories, the relevant question is not “when will a CRQC exist?” but “when was this data first at risk of being harvested?” If bulk collection by a sophisticated adversary is plausible — and for government, defence, and CNI sectors, it must be assumed — then data encrypted under RSA or ECC today is already in a potential adversary’s store.

Mapping third-party and supply-chain cryptographic dependencies

Supply chain cryptography is one of the least-visible migration risks. Your internal systems may be migrated on schedule, but if they communicate with suppliers, payment processors, identity providers, or SaaS platforms still running legacy key exchange, the security of the end-to-end channel remains bounded by the weakest link.

Third-party risk assessment for PQC should include:

• Reviewing vendor PQC roadmaps and published migration commitments
• Including PQC readiness clauses in new contracts and renewals from 2025 onwards
• Identifying APIs and integration points that carry sensitive data and whose cryptography is controlled by the third party
• Assessing HSM and hardware appliance vendors for firmware upgrade paths to PQC support

Building crypto-agility into your own architecture — discussed in Phase 3 — also provides a buffer against supply chain migration delays, since agile systems can negotiate the strongest mutually supported algorithm rather than failing on a cipher mismatch.

Phase 3 — Selecting a Migration Strategy

Crypto-agile architecture: what it means in practice

Crypto-agility refers to designing systems so that the cryptographic algorithm can be changed — updated, swapped, or supplemented — without requiring a fundamental architectural re-engineering. It is the difference between cryptography baked into compiled firmware and cryptography abstracted behind an interface that accepts algorithm parameters at configuration time.

In practice, crypto-agility means:

• Using cryptographic libraries and APIs that support algorithm negotiation (e.g., TLS 1.3 cipher suite configuration rather than hardcoded cipher references)
• Externalising algorithm selection to configuration rather than hard-coding it in application logic
• Deploying certificate management infrastructure capable of issuing and renewing certificates across multiple algorithm families (RSA, ECDSA, ML-DSA)
• Building monitoring that detects cryptographic algorithm usage across the estate in near-real-time, supporting the evergreen CBOM

Algorithm agility is not a single feature to add — it is a design principle to apply consistently across the estate, from network infrastructure to application code to operational tooling.

Hybrid classical/PQC schemes as a transitional approach

Hybrid cryptography combines a classical algorithm (typically X25519 or P-256) with a PQC algorithm (ML-KEM) in a single key exchange, such that the session key is secure as long as either algorithm remains unbroken. The hybrid approach is specifically recommended by the NCSC and NIST for the transition period because it maintains backward security against classical attacks while adding quantum resistance.

The X25519Kyber768 hybrid (now formalised as X25519MLKEM768 in IETF drafts) is already supported in Chrome, Firefox, and Cloudflare infrastructure, making it the most immediately deployable hybrid key exchange for TLS workloads. For organisations with existing TLS estates, enabling hybrid key exchange is often the lowest-friction first step — it requires no certificate changes, only library and configuration updates on both ends of the connection.

Hybrid schemes are a transitional measure, not a permanent destination. The overhead of carrying two key exchange operations adds latency and bandwidth cost; long-term architecture should converge on pure PQC as interoperability and library support matures.

Lift-and-replace vs. crypto-agile middleware: trade-offs

Two broad migration strategies exist at the implementation level:

• Lift-and-replace: Retire the existing cryptographic implementation and replace it wholesale with a PQC-native one. Clean, auditable, and architecturally straightforward — but disruptive, expensive for legacy systems, and leaves no fallback path if a newly deployed PQC algorithm is later found to have weaknesses.
• Crypto-agile middleware: Insert a cryptographic abstraction layer — a middleware component, protocol gateway, or library wrapper — that can serve multiple algorithm families simultaneously, negotiating the strongest mutually supported option per connection. More complex to deploy and maintain, but allows incremental migration and provides resilience against algorithm failure.

The right choice depends on the system’s age, business criticality, and whether it can tolerate a maintenance window for a full replacement. For legacy systems with long replacement cycles (OT environments, embedded firmware, mainframe platforms), crypto-agile middleware is often the only realistic path within the NCSC’s milestones.

Phase 4 — Implementation, Testing, and Rollout

Procurement, vendor readiness, and standards compliance checks

Vendor assessment is a non-trivial step that must begin before implementation. Key questions to put to every technology vendor whose products handle cryptographic operations:

• Does the product support FIPS 203/204/205 algorithms, or have a published roadmap with committed dates?
• Is the PQC implementation independently validated (e.g., NIST ACVP testing, FIPS 140-3 module certification)?
• What is the upgrade path: firmware update, major version upgrade, or hardware replacement?
• How does the product handle hybrid key exchange during the transition period?
• Does the vendor’s PKI or certificate management platform support ML-DSA certificate issuance?

Procurement teams should incorporate PQC readiness requirements into RFPs and contracts from 2025. Vendors that cannot demonstrate a credible PQC roadmap represent a future migration dependency that should factor into total cost of ownership assessments.

Testing PQC implementations: performance and interoperability

Performance benchmarking is essential before wide deployment. Lattice-based algorithms generally have acceptable performance on modern server hardware, but there are known overhead areas:

• ML-KEM public keys and ciphertexts are larger than ECDH equivalents, which increases TLS handshake size and can affect performance in high-connection-rate environments.
• ML-DSA signatures are significantly larger than ECDSA signatures, which matters for use cases involving high volumes of signed objects (code packages, JWT tokens, DNS DNSSEC records).
• SLH-DSA has particularly large signature sizes; it is best reserved for contexts where signature generation frequency is low.
• Constrained devices (IoT, smart cards, embedded systems) may require hardware acceleration or algorithm profile selection.

Interoperability testing should cover both internal system pairs and externally-facing endpoints. Use NIST’s Automated Cryptographic Validation Protocol (ACVP) test vectors to validate correctness of algorithm implementations. For TLS, test hybrid key exchange negotiation against a range of client versions to confirm backward compatibility is preserved for clients that do not yet support PQC extensions.

Phased rollout: pilot → critical systems → full estate

A structured pilot deployment reduces the blast radius of unforeseen issues. A recommended sequence:

1. Pilot on non-critical, internet-facing services: Enable hybrid TLS key exchange on a low-risk external service to gather real-world performance data and identify compatibility issues with diverse client populations.
2. Extend to internal high-sensitivity systems: Migrate the systems identified as highest priority in the risk triage — those handling long-lived sensitive data — using hybrid schemes initially, then pure PQC as libraries stabilise.
3. Certificate infrastructure migration: Update issuing CAs to support ML-DSA certificate profiles; begin issuing dual-algorithm (classical + PQC) certificates where the PKI platform supports it.
4. Full estate rollout: Migrate remaining systems on a priority order derived from the CBOM, tracking progress against the 2031 and 2035 NCSC milestones.
5. Legacy deprecation: Remove RSA and ECC key exchange from configuration after confirming all clients and counterparties have migrated, aligned with the 2035 deprecation target.

NCSC UK Migration Milestones: What Must Be Done by When

The following timeline is drawn directly from the NCSC’s March 2025 migration timeline guidance. Organisations should use these milestones as fixed planning anchors, not as aspirational targets.

By 2028: initial discovery and planning obligations

• Complete a documented cryptographic asset inventory (CBOM) covering the full in-scope estate.
• Identify systems and data categories at highest HNDL risk.
• Produce a prioritised migration plan, approved by senior leadership (CISO / Board level).
• Assess supply chain and third-party cryptographic dependencies.
• Begin vendor engagement to confirm PQC roadmaps for critical technology components.
• Establish a Quantum Readiness Programme with defined ownership and governance.

The 2028 deadline is a planning and discovery milestone, not a technical migration one. Organisations that have not yet started their inventory are already behind schedule if they intend to meet it comfortably.

By 2031: critical system migration targets

• Complete migration of critical national infrastructure systems and highest-sensitivity data stores to quantum-safe cryptography.
• Hybrid key exchange deployed as a minimum across all externally-facing services.
• PKI hierarchies updated to support and issue PQC algorithm certificates.
• Supply chain compliance verified for tier-one suppliers handling sensitive data.

The 2031 milestone is where technical migration work must be substantially complete for the highest-risk systems. Organisations in financial services, health, and CNI sectors should map this milestone against their own system lifecycle schedules — systems due for technology refresh between 2025 and 2031 should be procured with PQC requirements included.

By 2035: full estate transition and legacy deprecation

• Full estate migration to quantum-safe cryptography complete.
• Legacy cryptography deprecation: RSA key exchange, ECDH, and classical-only cipher suites removed from configuration across all in-scope systems.
• Cryptographic inventory processes running continuously, with automated alerting for any newly introduced legacy algorithms.
• Audit evidence available demonstrating compliance with the full migration journey.

The 2035 target represents the end of the transition period. After this point, legacy algorithm support should not exist as a fallback on any system handling sensitive data. Given the typical enterprise system lifecycle of seven to ten years, systems procured in 2025 and 2026 must include PQC support requirements — they will still be running in 2035.

Governance, Training, and Sustaining Quantum Readiness

Establishing a Quantum Readiness Programme

A quantum readiness programme is the organisational structure that keeps PQC migration from becoming a one-off project that loses momentum after the initial inventory. It should be established as a standing programme with a defined mandate, budget, and executive sponsor — typically the CISO or a delegate at director level.

Core programme components:

• A steering group with representation from security, IT architecture, procurement, legal, and business lines that handle sensitive data
• A defined programme charter covering scope, milestones aligned to NCSC deadlines, and escalation paths
• A live CBOM maintained as the programme’s primary artefact, reviewed on at least an annual cadence
• A risk register tracking cryptographic dependencies that are blocked on third-party or vendor timelines
• A budget line for PQC tooling, training, and migration engineering work through at least 2031

Roles and responsibilities: CISO, security architects, procurement

CISO responsibility for PQC migration sits at the programme ownership level: ensuring board visibility of the migration roadmap, securing budget, and providing sign-off on the documented inventory required by 2028. Day-to-day technical execution falls to security architects and platform engineers.

Key role assignments to establish:

• Security architects: Own the crypto-agility framework and algorithm selection decisions; maintain the mapping between NIST standards and internal use cases.
• Platform/infrastructure teams: Responsible for updating library versions, TLS configurations, and certificate management tooling within their domains.
• Procurement: Responsible for embedding PQC readiness requirements in all relevant contracts and vendor assessments from 2025.
• Legal and compliance: Monitor evolving regulatory requirements (sector-specific guidance, Cyber Essentials updates, ISO 27001 revisions) and translate them into programme obligations.
• Training leads: Ensure that developers, network engineers, and operational staff understand basic PQC concepts and know where to escalate cryptographic decisions.

Keeping the cryptographic inventory evergreen

Continuous monitoring of the cryptographic estate prevents the CBOM from becoming stale within months of its initial production. Cryptographic drift — the introduction of legacy algorithms through new deployments, third-party integrations, or library updates — is a persistent operational risk.

Sustaining cryptographic lifecycle management requires:

• Integrating CBOM scanning into CI/CD pipelines so that new code deployments are checked for cryptographic regressions before they reach production
• Configuring certificate management platforms to alert on newly issued certificates using deprecated algorithm profiles
• Including cryptographic compliance checks in change management processes for network infrastructure
• Scheduling an annual full-estate CBOM review, with interim reviews triggered by significant architecture changes or new NCSC/NIST guidance publications

Security governance frameworks such as ISO 27001 already provide a structural home for many of these controls; the task is to extend existing information asset management and vulnerability management processes to cover cryptographic assets explicitly, rather than building a parallel governance structure from scratch.

Frequently Asked Questions About PQC Migration

How long does a full PQC migration typically take?

For a large enterprise, a complete PQC migration — from initial inventory to full legacy deprecation — typically spans seven to ten years. This reflects the time required to cycle through procurement, test, and replace systems across a heterogeneous estate, particularly where hardware components (HSMs, network appliances, embedded devices) require physical replacement rather than software updates. Organisations beginning in 2025 can realistically target the NCSC’s 2031 critical-systems milestone, with full estate completion by 2035, if they establish a funded programme and governance structure promptly.

Are NIST PQC algorithms approved for UK government use?

The NCSC has endorsed the NIST-standardised algorithms (ML-KEM, ML-DSA, SLH-DSA) as the recommended foundation for UK government PQC migration. The NCSC’s March 2025 migration timeline guidance is explicitly built around these standards. UK government departments and CNI operators should follow NCSC guidance directly; for classified systems, consult NCSC’s specific product and algorithm assurance guidance, as different controls apply above certain classification levels.

What is the difference between post-quantum cryptography and quantum key distribution?

Post-quantum cryptography (PQC) refers to classical mathematical algorithms — run on conventional computers — that are believed to be resistant to attacks by quantum computers. It is a software and standards approach, deployable on existing infrastructure. Quantum key distribution (QKD) is a physics-based technique that uses quantum mechanical properties of photons to distribute key material; it requires specialised optical hardware and is currently limited to point-to-point links over relatively short distances. The NCSC does not currently recommend QKD as a primary migration path for most organisations, citing cost, infrastructure requirements, and limited interoperability. PQC and QKD are distinct approaches and the terms should not be used interchangeably.

Can we use hybrid schemes during the