PQC Migration Guide 2026: Prepare Your Infrastructure

Why Post-Quantum Cryptography Migration Is Urgent in 2026

The case for acting now does not rest on speculation about when a cryptographically relevant quantum computer (CRQC) will exist. It rests on a simpler and more immediate problem: data encrypted today with classical algorithms can be stolen now and decrypted later, once a capable quantum machine becomes available.

The quantum threat to classical encryption (RSA, ECC, Diffie-Hellman)

RSA, elliptic-curve cryptography (ECC), and Diffie-Hellman key exchange all derive their security from mathematical problems — integer factorisation and the discrete logarithm problem — that a sufficiently powerful quantum computer running Shor’s algorithm can solve in polynomial time. That is not a theoretical footnote; it is the reason the National Institute of Standards and Technology (NIST) has been running its post-quantum standardisation process since 2016 and published its first finalised standards in 2024.

Symmetric algorithms such as AES-256 are comparatively resistant: Grover’s algorithm halves their effective key length, but doubling the key size largely restores security. The acute near-term risk is concentrated in asymmetric cryptography — specifically RSA-2048 and ECC-256, which are used in almost every TLS handshake, VPN tunnel, code-signing certificate, and PKI hierarchy in production today.

The ‘harvest now, decrypt later’ attack vector

Adversaries with long time horizons — nation-state actors in particular — do not need to wait for quantum computers to become operational before acting. The harvest now, decrypt later (HNDL) strategy involves capturing and archiving encrypted network traffic today, with the intention of decrypting it once a CRQC becomes available. Classified communications, intellectual property, financial records, and health data exchanged over TLS or IPsec right now are plausible targets for this approach.

The practical implication is stark: data with a confidentiality requirement extending beyond the next decade is already at risk under classical encryption. Government communications, long-term contracts, medical records, and defence procurement data all fall into this category. Waiting until quantum computers are demonstrably capable before beginning migration means accepting that those datasets will eventually be exposed.

Why 2026 is the critical planning window before the 2028 deadline

The UK’s National Cyber Security Centre (NCSC) and equivalent agencies — NIST in the US, the Canadian Centre for Cyber Security (CCCS), France’s ANSSI, and Germany’s BSI — have converged on 2028 as the date by which organisations should have completed their cryptographic inventories and established a documented migration plan. That milestone is not a migration deadline; it is a planning deadline. The actual migration work for high-priority systems must be substantially complete by 2031.

Enterprise cryptographic migrations routinely take two to four years when procurement cycles, legacy system constraints, vendor dependencies, and regulatory approval processes are factored in. Organisations that begin their cryptographic asset discovery in 2026 are already operating within a compressed window. Those that defer until 2027 will find themselves unable to complete the necessary groundwork before the 2028 milestone.

Understanding the NIST and NCSC PQC Standards Framework

Before selecting algorithms or designing a migration architecture, you need to understand which standards govern the choice — and which agencies are mandating them on what timescale.

NIST FIPS 203, 204, and 205: the finalised post-quantum algorithms

In August 2024, NIST published three Federal Information Processing Standards that define the primary quantum-resistant algorithms for use in government and, by extension, commercial systems:

• FIPS 203 (ML-KEM) — Module-Lattice-Based Key-Encapsulation Mechanism, derived from CRYSTALS-Kyber. This is the primary algorithm for key exchange and key encapsulation, replacing RSA and Diffie-Hellman in that role. ML-KEM is available in three parameter sets (ML-KEM-512, ML-KEM-768, ML-KEM-1024) offering different security levels.
• FIPS 204 (ML-DSA) — Module-Lattice-Based Digital Signature Algorithm, derived from CRYSTALS-Dilithium. This replaces RSA and ECDSA for digital signatures, including code signing, document signing, and certificate authentication.
• FIPS 205 (SLH-DSA) — Stateless Hash-Based Digital Signature Algorithm, derived from SPHINCS+. This provides a hash-based alternative for digital signatures, valuable where algorithm diversity or long-lived signatures are required — such as firmware signing or root CA certificates.

NIST IR 8547 provides supplementary migration guidance, including deprecation timelines for classical algorithms and recommendations for hybrid schemes during the transition period. NIST formally recommends that organisations no longer use RSA or ECC in new systems after 2030, and that existing deployments migrate before 2035.

NCSC UK guidance and the 2028–2031–2035 milestone roadmap

The NCSC published updated migration timelines in March 2026, setting out a three-phase roadmap that applies to all UK public sector organisations and is considered best practice for critical national infrastructure and large enterprises. The milestones are covered in detail in the dedicated section below, but the overarching framework rests on two principles: start with discovery, and build crypto-agility into every system you touch during migration.

Crypto-agility — the capacity of a system to swap cryptographic algorithms without requiring architectural redesign — is treated by the NCSC not as an optional enhancement but as a foundational design requirement. Systems that are not crypto-agile will require complete replacement rather than upgrade as standards evolve, which is significantly more expensive and disruptive.

How UK, US, and international standards align (CCCS, ANSSI, BSI)

There is strong international alignment on the core algorithm choices. The CCCS’s June 2026 roadmap endorses ML-KEM, ML-DSA, and SLH-DSA in line with NIST FIPS 203/204/205. ANSSI (France) and BSI (Germany) have both published guidance recommending hybrid cryptography — classical plus post-quantum in parallel — as the appropriate near-term posture, while awaiting further cryptanalytic confidence in lattice-based algorithms. The Post-Quantum Cryptography Coalition (PQCC), an industry body whose migration roadmap complements government guidance, similarly endorses hybrid deployment as the pragmatic enterprise path.

The practical consequence of this alignment is that organisations operating across multiple jurisdictions do not face conflicting mandates: implementing ML-KEM and ML-DSA in hybrid mode satisfies NIST, NCSC, CCCS, and most European guidance simultaneously.

Step 1 — Cryptographic Asset Discovery and Inventory

Every authoritative migration guide — NIST’s, the NCSC’s, and the PQCC’s — identifies cryptographic asset discovery as the essential first step. You cannot prioritise, plan, or execute a migration if you do not know what cryptography you are running, where it lives, and what it is protecting.

What to inventory: certificates, keys, protocols, and data flows

A comprehensive cryptographic inventory covers four categories:

1. Certificates: Every X.509 certificate in use — TLS server certificates, client certificates, code-signing certificates, intermediate and root CA certificates. Record the algorithm (RSA-2048, ECDSA P-256, etc.), expiry date, issuing CA, and the systems that depend on each certificate.
2. Cryptographic keys: Symmetric keys, asymmetric key pairs, HSM-stored keys, and keys embedded in firmware or configuration files. Include key length, algorithm, storage location, and any associated key management processes.
3. Protocols: Every protocol that uses asymmetric cryptography — TLS (all versions), SSH, IPsec/IKEv2, SFTP, DNSSEC, S/MIME, PGP, PKCS#11 interfaces, and any proprietary protocol your organisation has developed.
4. Data flows: Which systems communicate with which, over which protocols, and what sensitivity classification applies to that data. This is essential for prioritising migration order.

The output of this process is your cryptographic bill of materials (CBOM) — a structured inventory analogous to a software bill of materials (SBOM), but focused on cryptographic dependencies. NIST’s migration documentation explicitly recommends producing a CBOM as the foundation of any PQC programme.

Tools and methods for automated cryptographic discovery

Manual discovery is impractical at enterprise scale. Several approaches exist for automation, though it is worth acknowledging that CBOM tooling is still maturing as of 2026 and no single tool covers every environment comprehensively.

• TLS audit tools: Network scanners such as testssl.sh, SSLyze, or enterprise equivalents can enumerate TLS configurations across all external and internal endpoints, identifying cipher suites, certificate algorithms, and protocol versions.
• PKI assessment: Certificate management platforms (CMP-compatible systems, ACME-based tooling, or dedicated CLM solutions) can provide a certificate inventory across the enterprise PKI, including shadow IT certificates not under centralised management.
• Code scanning: Static analysis tools with cryptographic detection capabilities can identify algorithm usage within application code, libraries, and build pipelines — critical for discovering cryptographic dependencies in internally developed software.
• Network traffic analysis: Passive inspection of encrypted traffic metadata can reveal protocol versions and key exchange algorithms in use across the network without decryption.

Avoid presenting any specific commercial vendor’s tooling as a neutral recommendation; the appropriate choice depends on your existing estate, budget, and operational model. Evaluate tools against the CBOM data model requirements set out in NIST guidance before procurement.

Prioritising assets by sensitivity and exposure

Once your CBOM is established, apply a prioritisation framework based on two axes: data sensitivity (what would the exposure of this asset cost?) and migration difficulty (how complex is it to replace the cryptography protecting this asset?). Assets that are both high-sensitivity and externally exposed — internet-facing TLS endpoints, externally accessible VPNs, public-key infrastructure roots — should head your migration queue. Long-lived data at rest with a multi-decade confidentiality requirement represents the highest HNDL risk and warrants urgent attention regardless of how difficult re-encryption may be.

Step 2 — Defining Your Migration Strategy

With a CBOM in hand and assets prioritised, the next decision is strategic: how will you migrate, and in what sequence? There is no single correct answer, but there are three dominant patterns, each with distinct trade-offs.

Hybrid cryptography: classical and post-quantum in parallel

Hybrid cryptography runs a classical algorithm and a post-quantum algorithm simultaneously, combining their outputs so that security is maintained even if one is broken. For example, a TLS handshake might combine X25519 (classical ECDH) with ML-KEM-768, deriving the session key from both. If ML-KEM is subsequently found to have a weakness, the classical component still provides protection; if a quantum computer breaks X25519, the ML-KEM component still provides protection.

Both the NCSC and NIST recommend hybrid cryptography as the appropriate near-term posture for most organisations. It provides defence-in-depth during a period when post-quantum algorithms are finalised but not yet extensively deployed at scale. The trade-off is increased handshake size, latency, and computational overhead — measurable but generally acceptable for most enterprise workloads.

IETF standards for hybrid key exchange in TLS 1.3 and for X.509 post-quantum certificates are progressing rapidly, and several implementations are already available in mainstream TLS libraries.

Crypto-agility by design: building systems that can swap algorithms

Crypto-agility means designing systems so that the cryptographic algorithm is a configurable parameter rather than a hardcoded dependency. A crypto-agile TLS implementation can switch from RSA to ML-KEM by updating configuration; a non-agile system requires code changes, recompilation, and potentially architectural redesign.

For any system being built or substantially refactored in 2026, crypto-agility is not optional — it is a design requirement. Practically, this means: abstract cryptographic operations behind well-defined interfaces, avoid hardcoding algorithm identifiers in application code, use libraries that support algorithm negotiation (OpenSSL 3.x with the OQS provider, for example, already supports ML-KEM and ML-DSA), and ensure your PKI and certificate management infrastructure can issue and manage post-quantum and hybrid certificates.

Choosing between full replacement, hybrid, and phased migration

The three strategic options are:

• Full replacement: Remove classical algorithms and deploy pure post-quantum. Appropriate only for new systems with no legacy compatibility requirements, or for systems at end-of-life being replaced anyway. Not recommended as the primary near-term strategy for production systems given interoperability considerations.
• Hybrid (recommended near-term): Deploy classical plus post-quantum in parallel for key exchange and signatures. This is the NCSC-endorsed approach for externally facing systems and high-priority assets through to 2031.
• Phased migration: Migrate different parts of the estate in priority order, maintaining classical cryptography in lower-risk areas until resources allow. Appropriate for large, complex estates — provided the phasing plan is documented and tracked against NCSC milestones.

PKI modernisation is a particular challenge in phased migrations. Root CA certificates have long lifetimes (often 20–25 years); planning the introduction of ML-DSA or SLH-DSA root CAs and the parallel operation of dual-algorithm X.509 hierarchies should begin now, even if issuance of post-quantum end-entity certificates is still 18–24 months away.

The Three NCSC Milestones: What You Must Achieve by 2028, 2031, and 2035

The NCSC’s March 2026 guidance on timelines for migration to post-quantum cryptography defines three concrete milestones. These are not aspirational targets — they represent the NCSC’s assessment of what is achievable and necessary to maintain national security and economic resilience in the face of the quantum threat.

By 2028: identify vulnerable systems and establish a migration plan

The 2028 milestone is a planning milestone. By the end of 2028, the NCSC expects organisations to have:

• Completed a comprehensive cryptographic inventory (CBOM) covering all significant systems
• Identified which assets are vulnerable to quantum attack and ranked them by risk
• Developed a documented migration plan with named owners, budgets, and timelines
• Established relationships with suppliers and vendors to understand their PQC roadmaps
• Made initial investments in crypto-agility for systems under active development

Organisations that have not begun their cryptographic discovery by mid-2026 are already at risk of missing this milestone, given the time required for procurement, tooling deployment, and stakeholder engagement.

By 2031: complete high-priority and externally facing migrations

The 2031 milestone is the first execution milestone. By the end of 2031, the NCSC expects that:

• All externally facing services (internet-accessible TLS, public APIs, customer-facing authentication) have migrated to hybrid or pure post-quantum cryptography
• High-priority internal systems — particularly those handling sensitive data with long-term confidentiality requirements — have completed migration
• The organisation’s PKI has been updated to support post-quantum and hybrid certificate issuance
• Supplier and third-party integrations with critical dependencies have been assessed and, where necessary, migrated or replaced

The 2031 deadline is where HNDL risk reduction is most concentrated: data exchanged over external TLS connections after 2031 should be protected by algorithms that are quantum-resistant, limiting the future value of any traffic already harvested.

By 2035: full migration to quantum-safe cryptography across all systems

The 2035 milestone is the full migration deadline. By this date, the NCSC expects organisations to have retired all classical asymmetric cryptography across the entire estate — including internal systems, legacy infrastructure, OT/ICS environments, and any remaining isolated deployments. Systems that cannot be migrated should be decommissioned or replaced.

This is also the horizon at which NIST’s deprecation schedule for RSA and ECC effectively mandates removal from compliant systems. Organisations that treat 2035 as their start date rather than their completion date will find themselves in a compliance deficit with significant remediation costs.

Infrastructure-Specific Migration Considerations

Generic migration guidance is a starting point, not a plan. The practical complexity varies substantially by infrastructure type, and the trade-offs are rarely acknowledged in high-level roadmaps. The following covers the areas where implementation teams consistently encounter the most friction.

TLS/HTTPS and web-facing services

TLS is the highest-priority migration target for most organisations: it is externally exposed, it is the primary HNDL attack surface, and the standards for post-quantum TLS are the most mature. IETF RFC 9370 defines hybrid key exchange for TLS 1.3, and several major TLS libraries — including OpenSSL 3.x with the OQS provider and BoringSSL — already support ML-KEM in hybrid mode.

The immediate action is to enable X25519Kyber768 (or equivalent hybrid key exchange) in your TLS 1.3 configuration for externally facing services, where your CDN, load balancer, or web server supports it. This protects against HNDL for traffic exchanged after deployment without requiring changes to the certificate itself. Certificate migration (from RSA or ECDSA to ML-DSA or hybrid dual-algorithm X.509) is the next phase and depends on CA support and client compatibility.

Post-quantum TLS also intersects with QUIC: the QUIC protocol (used in HTTP/3) will require post-quantum key exchange extensions as they are standardised, and organisations running HTTP/3 infrastructure should track IETF progress on PQC QUIC extensions.

VPNs, secure tunnels, and IPsec

IPsec with IKEv2 is the dominant VPN protocol in enterprise and government environments. Post-quantum extensions for IKEv2 are defined in RFC 9370, and several major VPN platform vendors have begun implementing them. The practical challenge is interoperability: both endpoints of an IPsec tunnel must support the same post-quantum key exchange mechanism, which means migration cannot be completed until all peer organisations and remote-access clients have also upgraded.

For remote-access VPNs, the migration path is relatively straightforward once client software is updated. For site-to-site tunnels with external partners, supplier assessment (covered in the organisational readiness section) becomes critical — you cannot migrate a tunnel unilaterally.

Code signing, firmware, and long-lived certificates

Code-signing and firmware-signing certificates present a different problem from TLS certificates: they are often long-lived (three to five years is common; some firmware signing keys have effective lifespans of ten years or more), and the signatures they produce persist on artefacts that may be in deployment for decades.

A firmware image signed today with an RSA-2048 key will still be verified against that key in 2035. If the verification infrastructure has been migrated to post-quantum but the signature algorithm has not, the verification chain is broken. Conversely, if the key is compromised via a quantum attack, firmware authenticity is undermined across all deployed devices.

The NCSC’s guidance treats long-lived certificate lifespans as a migration accelerant: the longer a certificate’s validity period, the sooner it should appear in the migration queue. SLH-DSA (FIPS 205) is specifically recommended for long-lived signing use cases because its security is grounded in well-understood hash function properties rather than lattice problems, providing additional algorithm diversity.

IoT and embedded systems: the hardest migration challenge

IoT and OT/ICS environments present the most significant migration obstacles. Constrained devices — those with limited CPU, memory, or power budgets — may be physically incapable of running ML-KEM or ML-DSA within acceptable performance parameters. Many IoT devices lack secure over-the-air firmware update mechanisms, making cryptographic upgrades operationally difficult or impossible without physical access.

There is no simple solution here, and it is worth being direct about that. Organisations with large IoT estates should:

• Identify devices that cannot be migrated in place and plan for physical replacement within the 2031–2035 window
• Assess whether lightweight post-quantum algorithms (such as ML-KEM-512, the lowest-parameter variant) are viable on constrained hardware — some embedded platforms can support them with optimised implementations
• Evaluate network segmentation as a compensating control for IoT devices that cannot be migrated, reducing the attack surface while replacement is planned
• Engage manufacturers now on their PQC roadmaps; many ICS and IoT vendors have roadmaps measured in years, and procurement decisions made in 2026 should include PQC readiness as an evaluation criterion

Building a Quantum Readiness Programme Inside Your Organisation

Technical migration without organisational governance fails. The organisations that will meet the 2031 milestone are those that establish a structured quantum readiness programme with named ownership, board-level visibility, and integration into existing risk and procurement frameworks — not those that treat PQC as a purely technical infrastructure project.

Stakeholder mapping: CISO, CTO, compliance, and procurement

A quantum readiness programme requires active engagement from several distinct functions, each with different interests and decision-making authority:

• CISO: Owns the risk register, sets migration priorities based on risk appetite, and reports to the board on quantum readiness status. Responsible for maintaining the cryptographic risk register as a live document.
• CTO / Engineering leadership: Responsible for crypto-agility in product and platform architecture decisions, and for ensuring development teams have the knowledge and tooling to implement post-quantum algorithms correctly.
• Compliance and legal: Responsible for tracking regulatory requirements (NCSC guidance, sector-specific mandates, contractual obligations with government clients), and for understanding the legal implications of a data breach attributable to cryptographic failure post-2031.
• Procurement: Responsible for embedding PQC readiness requirements into vendor contracts, RFPs, and supplier assessments. Procurement cycles are long; a decision made in 2026 without a PQC clause may lock the organisation into a non-compliant solution through 2031.

Supplier and third-party cryptographic risk assessment

Supply chain cryptography is one of the most underestimated risks in PQC migration planning. Your organisation’s TLS endpoints may be migrated on schedule, but if a critical SaaS platform, cloud provider, or B2B integration partner is still using RSA-2048 for key exchange in 2030, the confidentiality of data exchanged over that connection remains at risk.

A structured vendor PQC assessment should be added to your third-party risk management process. For critical suppliers, this means requesting documented PQC migration roadmaps and milestone commitments. For new procurements, PQC readiness should be a scored evaluation criterion. The PQCC’s migration roadmap provides a useful framework for structuring supplier questionnaires.

Training security and development teams on PQC concepts

Most security practitioners and developers working today were trained on classical cryptography. They understand RSA key sizes, ECC curve selection, and TLS configuration — but may have limited familiarity with lattice-based cryptography, key encapsulation mechanisms as distinct from key exchange protocols, or the performance characteristics of ML-KEM versus ML-DSA.

Targeted training does not need to be mathematically deep: practitioners need to understand which algorithms to use for which purpose (ML-KEM for key exchange, ML-DSA or SLH-DSA for signatures), how hybrid schemes work at the protocol level, and how to configure and verify post-quantum implementations in the tooling they actually use. NIST’s migration documentation and the NCSC’s guidance both provide accessible starting points that can anchor a training curriculum without requiring specialised academic resources.

Frequently Asked Questions About PQC Migration

How long does a full PQC migration take?

Enterprise-scale cryptographic migrations typically take between three and seven years from initial discovery to full deployment, depending on estate complexity, vendor dependencies, and regulatory approval requirements. Organisations with large IoT or OT/ICS footprints should expect timelines at the longer end. This is why the NCSC’s 2028 planning milestone exists: beginning discovery and planning in 2026 is necessary to achieve the 2031 execution milestone for high-priority systems. A migration that starts in 2029 cannot realistically complete high-priority work by 2031.

Do NIST post-quantum algorithms have known weaknesses?

No critical weaknesses have been found in ML-KEM, ML-DSA, or SLH-DSA as standardised in FIPS 203, 204, and 205. These algorithms underwent approximately eight years of public cryptanalytic scrutiny during the NIST competition. That said, lattice-based cryptography is a younger field than RSA or ECC, and the cryptographic community continues to study it. This is precisely why both NIST and NCSC recommend hybrid cryptography rather than pure post-quantum deployment in the near term: combining classical and post-quantum algorithms ensures that a future unexpected weakness in one does not compromise overall security. SLH-DSA, being hash-based, rests on the security of SHA-2 and SHA-3 — which have a substantially longer track record.

Is post-quantum cryptography already available in mainstream software?

Yes, to a meaningful degree. OpenSSL 3.x with the Open Quantum Safe (OQS) provider supports ML-KEM and ML-DSA. Google Chrome has deployed X25519Kyber768 hybrid key exchange for a significant proportion of TLS connections since 2023. Cloudflare, AWS, and several other major infrastructure providers have enabled post-quantum TLS in their offerings. Commercial HSM vendors are beginning to offer ML-KEM and ML-DSA support. The ecosystem is not universally complete — in particular, post-quantum X.509 certificate issuance from commercial CAs and full IKEv2 post-quantum support across all major VPN platforms remain in progress — but the core building blocks are available for organisations ready to begin.

What happens if we miss the 2028 NCSC planning milestone?

The 2028 milestone carries no direct regulatory penalty for private sector organisations in the UK as of 2026, though this may change as sector-specific regulators develop PQC guidance aligned with the NCSC framework. The more significant consequence is operational: missing the 2028 planning milestone means compressing the execution phase, increasing the risk of incomplete migration by 2031. For organisations operating under government contracts or in regulated sectors (financial services, healthcare, critical national infrastructure), contractual or regulatory requirements may impose additional consequences. The NCSC has been explicit that organisations failing to meet the 2031 milestone for externally facing systems will be considered to have unacceptable residual cryptographic risk — with attendant implications for procurement eligibility and insurance.