PQC Migration Guide: Transitioning to Post-Quantum Cryptography

Why Post-Quantum Cryptography Migration Can’t Wait

Post-quantum cryptography (PQC) migration is the structured process of replacing classical public-key algorithms — primarily RSA and elliptic-curve cryptography (ECC) — with quantum-resistant alternatives that can withstand attacks from a cryptographically relevant quantum computer (CRQC). In 2026, that transition is no longer a research exercise: finalised standards are published, regulatory milestones are set, and adversaries are already collecting encrypted data to decrypt later.

The harvest-now, decrypt-later threat explained

The most immediate risk is not that a quantum computer will break your encryption today. It is that adversaries are harvesting encrypted traffic now, storing it, and waiting until a sufficiently powerful CRQC exists to decrypt it retroactively. This harvest-now, decrypt-later (HNDL) strategy means that data encrypted under RSA-2048 or ECDH today may be exposed in the mid-2030s — well within the confidentiality window of government communications, financial records, intellectual property, and healthcare data.

The practical consequence is that the clock for sensitive and long-lived data started years ago. Organisations that delay migration until a CRQC is announced will already have lost the race.

Why RSA and ECC are at risk from quantum computers

RSA derives its security from the computational difficulty of factoring large integers; ECC relies on the elliptic-curve discrete logarithm problem. Both problems are efficiently solvable by a quantum computer running Shor’s algorithm. A CRQC with sufficient error-corrected qubits could break RSA-2048 in hours rather than millennia. Symmetric algorithms (AES-256) and hash functions are far less affected — Grover’s algorithm provides only a quadratic speedup — but asymmetric key exchange and digital signatures require wholesale replacement.

Regulatory pressure: NCSC, NIST, and IETF signals for UK organisations

Three authoritative bodies have now moved beyond guidance into enforceable-adjacent mandates. The UK’s National Cyber Security Centre published its Timelines for migration to post-quantum cryptography in March 2025, setting explicit milestone years (2028, 2031, and 2035) for organisations operating critical systems. NIST finalised FIPS 203, 204, and 205 in August 2024, giving vendors and operators a stable target. The IETF published protocol-level migration guidance in July 2025 covering TLS, SSH, and related internet standards. For UK organisations subject to NIS2-equivalent obligations or government supply-chain requirements, these signals are effectively a compliance clock.

Understanding the NIST and NCSC PQC Standards Landscape

Before planning a migration, your organisation needs to know which algorithms to migrate to. The landscape clarified significantly in 2024–2025, and conflating draft algorithm names with finalised FIPS designations is a common source of confusion in procurement and architecture discussions.

NIST FIPS 203, 204, and 205: the finalised algorithms

NIST finalised three post-quantum cryptographic standards in August 2024, each serving a distinct purpose:

• ML-KEM (FIPS 203) — Module-Lattice-Based Key-Encapsulation Mechanism, standardised from CRYSTALS-Kyber. This is the primary replacement for RSA and ECDH in key exchange scenarios, including TLS handshakes.
• ML-DSA (FIPS 204) — Module-Lattice-Based Digital Signature Algorithm, standardised from CRYSTALS-Dilithium. The primary replacement for RSA and ECDSA in digital signature applications including code signing and PKI.
• SLH-DSA (FIPS 205) — Stateless Hash-Based Digital Signature Algorithm, standardised from SPHINCS+. A hash-based alternative for digital signatures where a different mathematical assumption from lattice-based cryptography is desirable for diversity.

A fourth standard, FN-DSA (FIPS 206, from FALCON), is expected to complete the primary suite. NIST’s post-quantum cryptography FAQ confirms that ML-KEM and ML-DSA should be the default choices for most use cases, with SLH-DSA providing an important backup rooted in well-understood hash function security.

One important clarification: these FIPS designations replace the earlier draft names (Kyber, Dilithium, SPHINCS+). When evaluating library or vendor support, verify that implementations target the finalised FIPS standards, not earlier draft specifications, which are not identical.

NCSC’s three migration milestones: 2028, 2031, and 2035

The NCSC’s March 2025 guidance defines three milestone years that UK organisations should treat as planning anchors:

These milestones align closely with NIST’s published deprecation schedule, which targets deprecation of RSA and ECC-based key establishment by 2030 and disallowance by 2035. UK organisations should treat NCSC’s milestones as the operative planning framework and NIST’s schedule as a compatible global baseline.

Which algorithms replace RSA and ECC?

The primary replacement mappings are straightforward: ML-KEM (FIPS 203) replaces RSA and ECDH for key encapsulation and key agreement; ML-DSA (FIPS 204) replaces RSA-PSS and ECDSA for digital signatures. SLH-DSA (FIPS 205) provides an alternative signature scheme where algorithm diversity is a design requirement. During the transition period, hybrid cryptography — combining a classical algorithm with a PQC algorithm in the same handshake or key exchange — is the recommended approach, as it preserves classical security guarantees while adding quantum resistance.

Phase 1 — Cryptographic Discovery and Inventory

Discovery is the mandatory first step identified in both NIST’s PQC FAQ and the NCSC’s migration guidance. You cannot prioritise, assess risk, or plan remediation for cryptographic assets you have not found. Organisations consistently underestimate the breadth of their cryptographic footprint.

How to identify all cryptographic assets across your infrastructure

Cryptographic asset discovery requires a systematic sweep across several layers of your environment:

• Network traffic analysis: Inspect TLS handshakes to identify cipher suites in active use. Tools such as network scanners and TLS inspection proxies can enumerate RSA and ECC key exchange and authentication in transit.
• Certificate inventory: Export and audit all X.509 certificates from your PKI, certificate authorities, load balancers, web servers, and API gateways. Note key types, sizes, and expiry dates.
• Code and build pipelines: Identify where code signing is performed, which keys are used, and which libraries (OpenSSL, BouncyCastle, native OS CNG/Security.framework) underpin cryptographic operations.
• Application layer: Audit application source code and configuration for direct cryptographic API calls, hard-coded algorithm identifiers, and embedded key material.
• Hardware and firmware: Hardware Security Modules (HSMs), TPMs, smart cards, and IoT devices often embed cryptographic capabilities that are difficult or impossible to update remotely.

Prioritising systems by sensitivity and longevity of data

Not all cryptographic assets carry the same risk. Prioritisation should be driven by two axes: the sensitivity of the data protected, and the longevity of that data’s confidentiality requirement. Long-lived data — patient records, legal contracts, classified information, intellectual property with decade-scale value — faces the highest harvest-now, decrypt-later exposure. Systems protecting this data should be moved to the top of your migration queue regardless of their technical complexity.

The NCSC’s guidance specifically calls out critical national infrastructure, financial services, and government systems as early-priority candidates. For other sectors, the same logic applies: assess how long your data needs to remain confidential, then work backwards from the plausible CRQC timeline.

Building a cryptographic bill of materials (CBOM)

A cryptographic bill of materials (CBOM) is the structured output of your discovery phase — a machine-readable inventory of every cryptographic asset, its algorithm, key size, certificate authority, expiry date, dependent systems, and migration status. The CBOM concept is analogous to a software bill of materials (SBOM) and is increasingly recognised as a prerequisite for PQC migration planning.

Your CBOM should record, at minimum: asset identifier, cryptographic algorithm and parameters, system owner, data sensitivity classification, vendor or library providing the implementation, and dependency relationships (which systems or services depend on this cryptographic asset). Maintaining this as a living document — not a one-off spreadsheet — is essential for tracking migration progress and supporting ongoing crypto-agility.

Phase 2 — Risk Assessment and Migration Prioritisation

Discovery tells you what you have. Risk assessment tells you what to migrate first. The goal of this phase is to convert your CBOM into a prioritised migration backlog, informed by quantum risk exposure, data sensitivity, and the realities of vendor and supply-chain dependency.

Classifying systems by quantum risk exposure

Risk classification for PQC migration combines three factors: the algorithm’s vulnerability to quantum attack (RSA and ECC key exchange are high; AES-256 data encryption is low), the sensitivity and longevity of the data, and the system’s exposure to adversarial traffic capture. Internet-facing systems that handle long-lived sensitive data — HTTPS endpoints serving authenticated financial transactions, VPN gateways, identity providers — warrant the highest risk classification and the earliest migration dates.

Internal systems with short-lived session data and no public exposure carry lower urgency, though they remain in scope for the 2035 deadline. A risk matrix mapping these dimensions to NCSC milestone years gives programme managers a defensible prioritisation rationale.

Assessing vendor and supply-chain dependencies

A frequently overlooked aspect of PQC migration is that your organisation’s cryptographic posture is only as strong as your weakest dependency. Third-party PKI providers, cloud service providers, SaaS platforms, HSM vendors, and embedded firmware suppliers all implement cryptographic algorithms on your behalf. Before committing to a migration timeline for any system, map its cryptographic dependencies:

• Does your HSM vendor have a firmware roadmap for ML-KEM and ML-DSA support?
• Has your certificate authority published a timeline for issuing PQC or hybrid certificates?
• Do your cloud providers support hybrid TLS or PQC key exchange in their managed services?
• Have your SaaS vendors disclosed their PQC readiness?

Dependency mapping at this stage prevents a common failure mode: completing your internal migration only to discover that a critical third-party PKI or SaaS platform cannot support PQC certificates until 2029 or later. The Canadian Centre for Cyber Security’s June 2025 migration roadmap specifically highlights supply-chain cryptography as a risk multiplier that organisations routinely underestimate.

Defining your migration goals and success criteria

A migration programme without defined success criteria becomes indefinitely open-ended. Before moving to strategy selection, agree measurable goals: what percentage of internet-facing TLS endpoints will be hybrid-enabled by the 2028 NCSC milestone? What is the target for PKI migration by 2031? Which systems must reach full quantum-resistant operation before the 2035 deadline?

Crypto-agility — the architectural property that allows cryptographic algorithms to be updated without fundamental system redesign — should itself be a defined success criterion, not an afterthought. Systems that complete PQC migration but cannot be updated when a future algorithm is deprecated will require another full migration cycle.

Phase 3 — Selecting a Migration Strategy

With a risk-prioritised backlog and defined goals, the next decision is strategic: how will your organisation migrate, and in what posture will you operate during the multi-year transition period?

Hybrid vs. pure PQC migration: trade-offs explained

This is currently debated among practitioners and standards bodies, though the consensus is converging. Hybrid cryptography combines a classical algorithm (e.g. ECDH) with a PQC algorithm (e.g. ML-KEM) in a single key exchange, such that breaking both would be required to compromise the session. The IETF and NCSC both recommend hybrid as the approach for the transition period: it provides quantum resistance while preserving classical security guarantees if a flaw is discovered in the PQC algorithm.

Pure PQC — migrating directly to ML-KEM or ML-DSA without retaining a classical component — is the eventual target state (2035 deadline) but carries interoperability risk in the near term. Most clients, servers, and embedded systems do not yet have mature PQC-only implementations, and removing the classical fallback increases the blast radius of any future cryptographic vulnerability in the PQC algorithm. For most organisations, the pragmatic path is: hybrid now, pure PQC when ecosystem maturity and NCSC guidance confirm it is appropriate.

Crypto-agile architecture: building for future algorithm updates

Algorithm agility means designing systems so that the cryptographic algorithm is a configurable parameter rather than a hard-coded constant. In practice, this involves abstracting cryptographic operations behind well-defined interfaces (e.g. using a cryptographic provider framework rather than calling algorithm-specific APIs directly), externalising algorithm configuration to policy files or key management systems, and maintaining separation between key material, algorithm identifiers, and application logic.

A crypto-agile architecture absorbs algorithm updates — whether driven by a newly discovered vulnerability or a future NIST deprecation — as configuration changes rather than code rewrites. Given that the PQC landscape will continue to evolve (NIST is already evaluating additional signature algorithms), crypto-agility is not optional; it is the architecture that makes future migrations tractable.

Prioritising internet-facing systems first

The IETF’s July 2025 guidance and the NCSC’s milestone framework both point in the same direction: migrate internet-facing systems first. These are the highest-exposure systems for HNDL attacks because adversaries can passively capture their traffic at scale. TLS-protected web services, API gateways, VPN concentrators, email security gateways, and identity providers should lead your migration. Firmware and IoT cryptography present a harder problem — many devices cannot receive cryptographic updates at all — and should be flagged for hardware replacement planning rather than software migration.

Phase 4 — Implementation and Testing

Implementation is where the theoretical migration plan meets real infrastructure. This phase has more friction than most roadmap articles acknowledge. The NIST PQC FAQ notes that performance and interoperability testing are essential steps before production deployment, and organisations that skip straight from pilot to production typically encounter problems at scale.

Deploying PQC in TLS, PKI, and code-signing workflows

For TLS, the immediate target is enabling hybrid key exchange using ML-KEM combined with ECDH (X25519 or P-256). The IETF has specified hybrid key exchange combinations for TLS 1.3 (refer to the IETF’s July 2025 guidance for protocol-specific details). Library support — OpenSSL 3.x with the OQS provider, BoringSSL experimental branches, and platform libraries — is maturing but not uniform across operating system versions. Audit your TLS library versions before enabling PQC extensions.

For PKI, the migration involves issuing certificates containing PQC or hybrid public keys. Certificate lifecycle management becomes more complex: PQC certificates are substantially larger than RSA or ECC certificates (ML-DSA public keys are approximately 1,312 bytes for the 44 security level, compared to 294 bytes for P-256), and some legacy PKI infrastructure has fixed-size database fields or network buffers that cannot accommodate them. Engage your CA provider early to understand their issuance roadmap.

For code signing, the migration to ML-DSA signatures affects software distribution pipelines, package repositories, firmware update mechanisms, and any process that verifies the integrity and authenticity of software artefacts. Signature sizes under SLH-DSA are large (8–50 KB depending on parameter set), which may affect signed firmware images stored in constrained devices.

Performance implications: bandwidth, latency, and compute overhead

Post-quantum algorithms carry measurable performance costs that your organisation should quantify in your environment rather than relying solely on published benchmarks. The key practical considerations are:

• Key and signature sizes: ML-KEM public keys and ciphertexts are larger than RSA or ECC equivalents. ML-DSA signatures are significantly larger than ECDSA signatures. This increases TLS handshake sizes and certificate chain sizes, which matters particularly for high-throughput services and constrained-bandwidth environments.
• Compute overhead: ML-KEM and ML-DSA are generally faster than RSA at equivalent security levels, but slower than optimised ECC implementations on some hardware. Hardware without AES-NI or vector instruction support will see higher relative overhead.
• Latency: Increased handshake size adds round-trip latency in constrained network environments. Measure this in your specific network topology — cloud-to-cloud connections will be less affected than mobile clients on high-latency links.

These are manageable costs for most modern infrastructure, but quantifying them in a staging environment prevents surprises in production.

Testing PQC implementations before production rollout

A staging environment that mirrors your production cryptographic configuration is essential. Test the full transaction path: client initiates TLS handshake with hybrid key exchange → server negotiates ML-KEM → certificate chain validates → session established. Specifically test interoperability between different library versions, since ML-KEM implementations from different vendors must interoperate correctly with the finalised FIPS 203 specification. Regression test classical-only clients against hybrid-capable servers to confirm graceful fallback behaviour. Load test at production-representative throughput to validate that performance overhead is within acceptable bounds before any production cutover.

Phase 5 — Governance, Training, and Ongoing Crypto-Agility

PQC migration is not a project with an end date. Even after the 2035 deadline, cryptographic algorithms will continue to evolve, vulnerabilities will be discovered, and new standards will be issued. Organisations that treat PQC migration as a one-time programme rather than an ongoing capability will find themselves repeating the exercise within a decade.

Embedding PQC readiness into security governance frameworks

Cryptographic governance should be a standing function within your GRC (governance, risk, and compliance) framework, not a temporary project. This means defining a cryptographic policy that mandates approved algorithm lists (aligned with NCSC guidance), establishing a review cycle (annual is typical, triggered additionally by NIST or NCSC deprecation notices), assigning ownership of the CBOM to a named function, and including cryptographic posture in supplier assurance questionnaires and contract requirements.

For organisations operating under UK regulatory frameworks — financial services under PRA/FCA requirements, health under DSPT obligations, or government suppliers under Cyber Essentials Plus — embedding PQC compliance into existing compliance programmes rather than creating a parallel track reduces overhead and improves auditability.

Training security and development teams on post-quantum standards

The primary risk in implementation is not algorithm weakness but implementation error. Developers who are unfamiliar with PQC APIs, key sizes, and stateless signature requirements will make mistakes that undermine security regardless of algorithm strength. Training priorities should include: understanding why classical and PQC algorithms cannot simply be swapped without architectural review; correct use of ML-KEM key encapsulation (which differs operationally from ECDH key agreement); ML-DSA statelessness requirements versus stateful hash-based signatures; and the importance of not reusing nonces or key material across algorithm boundaries. The UK Cyber Security Council’s professional development frameworks provide a useful reference for structuring training curricula.

Planning for future algorithm updates and deprecations

NIST has stated that it will continue evaluating additional post-quantum signature algorithms, and the security properties of current PQC algorithms will be subject to ongoing cryptanalytic scrutiny. Your governance framework should include a process for monitoring NIST and NCSC deprecation notices, assessing the impact of any new guidance on your CBOM, and executing targeted updates to affected systems without requiring a full programme restart. This is the operational definition of crypto-agility governance: the organisation’s ability to respond to algorithm changes at the speed of the threat, not the speed of a multi-year capital programme.

PQC Migration Timeline: Key Milestones for UK Organisations

The following timeline consolidates the NCSC’s March 2025 milestone guidance and NIST’s deprecation schedule into a single reference for UK organisations. These dates are drawn from published primary sources; your organisation’s specific obligations may be stricter depending on sector regulation.

What must be completed by 2028 according to NCSC

The NCSC’s 2028 milestone is focused on preparation and early action for the highest-risk systems. By 2028, organisations — particularly those in critical national infrastructure and government — should have completed a full cryptographic asset discovery, produced and maintained a CBOM, completed risk classification and prioritisation, engaged with key vendors and supply-chain partners on their PQC roadmaps, and begun hybrid PQC deployment on the highest-risk internet-facing systems. The 2028 date is not a completion target; it is a readiness and early-deployment checkpoint. Organisations that have not started discovery by 2026 are already behind schedule relative to this milestone.

2031 objectives: full hybrid deployment

By 2031, the NCSC expects organisations to have achieved full hybrid PQC deployment across priority systems. This means TLS on internet-facing services is using hybrid key exchange, PKI is issuing PQC or hybrid certificates, and code-signing workflows have been updated. Vendor dependencies identified in Phase 2 should be resolved — either through vendor-delivered updates or through hardware replacement for devices that cannot support software migration. Supply-chain cryptography requirements should be embedded in procurement and contract processes by this point.

2035 deadline: full quantum-resistant infrastructure

The 2035 milestone represents the target end state: all systems operating exclusively on quantum-resistant cryptographic algorithms, with classical asymmetric algorithms fully retired. This aligns with NIST’s published timeline to disallow RSA and ECC key establishment after 2035. Reaching this milestone requires that the ecosystem — including hardware, embedded systems, third-party services, and standards — has matured sufficiently to support pure PQC operation without hybrid fallback. The 2035 deadline should be treated as fixed: it is anchored to the plausible CRQC development timeline, not to organisational convenience.

Frequently Asked Questions About PQC Migration

How long does a PQC migration typically take?

For a mid-sized organisation with moderate cryptographic complexity, a realistic migration programme spanning discovery through full hybrid deployment runs three to five years. Larger organisations with complex supply chains, legacy hardware, and bespoke PKI infrastructure should plan for five to seven years for full completion. This is precisely why the NCSC’s 2028 milestone focuses on preparation and early deployment rather than completion: organisations need to be well into their programme by 2028 to achieve full quantum-resistant infrastructure by 2035.

Can we run classical and post-quantum algorithms simultaneously?

Yes — and this is the recommended approach during the transition period. Hybrid cryptography, as standardised in the IETF’s TLS hybrid key exchange specifications, runs classical and PQC algorithms in parallel within the same cryptographic operation. A successful attack requires breaking both simultaneously. Hybrid operation also preserves backwards compatibility with clients that do not yet support PQC, allowing a phased rollout. Pure PQC (without a classical component) is the eventual target state but carries interoperability risks in the near term that most organisations should not accept until the ecosystem matures.

Which sectors face the most urgent PQC requirements?

The NCSC explicitly identifies critical national infrastructure — energy, water, transport, telecommunications, and financial services — as the highest-priority sectors for early migration. Government systems and defence supply chains face similar urgency. Financial services organisations face additional pressure from regulators who are increasingly treating cryptographic resilience as an operational risk requirement. Healthcare and life sciences face exposure through long-lived patient and research data. No sector is exempt from the 2035 deadline, but these sectors should be operating to the 2028 milestone as an active planning constraint.

What is crypto-agility and why does it matter for PQC?

Crypto-agility is the architectural property that allows a system to switch cryptographic algorithms — for key exchange, digital signatures, or encryption — without requiring a fundamental redesign of the system. It matters for PQC because the post-quantum algorithm landscape is not yet settled: NIST will issue further standards, cryptanalysts may identify weaknesses in current algorithms, and new attacks may emerge that require algorithm deprecation on shorter timescales than organisations can tolerate if their systems are tightly coupled to specific algorithms. A crypto-agile architecture makes future algorithm transitions a configuration and key management exercise rather than a multi-year engineering programme.