Post-Quantum Cryptography Migration Guide (2026)

Why the Quantum Threat Is No Longer a Future Problem

It is tempting to treat quantum computing as a long-range concern — something to revisit when the hardware matures. That framing is now dangerously wrong. The cryptographic risk posed by quantum computers is already active, even if the machines themselves are not yet capable of breaking production encryption.

How quantum computers break today’s public-key cryptography

The security of RSA and elliptic curve cryptography (ECC) — the two algorithms underpinning the vast majority of internet security, VPNs, code signing, and digital certificates — rests on mathematical problems that are computationally hard for classical computers. RSA depends on the difficulty of factoring large integers; ECC on the discrete logarithm problem over elliptic curves.

In 1994, Peter Shor demonstrated that a sufficiently powerful quantum computer could solve both problems in polynomial time. Shor’s algorithm does not merely speed up a classical attack — it breaks the underlying mathematical assumption entirely. A cryptographically relevant quantum computer (CRQC) running Shor’s algorithm would render RSA-2048 and all standard ECC key sizes obsolete, regardless of key length.

Symmetric algorithms and hash functions face a different but less severe threat. Grover’s algorithm provides a quadratic speedup for brute-force search, effectively halving the security level of symmetric keys — AES-128 falls to approximately 64-bit security under a quantum adversary, while AES-256 retains roughly 128-bit security. The practical implication: symmetric cryptography can often be hardened by doubling key lengths, whereas public-key cryptography requires a fundamental algorithm change.

The ‘harvest now, decrypt later’ attack and why it matters now

A CRQC does not need to exist today for an adversary to benefit from one tomorrow. Nation-state actors and well-resourced criminal organisations are already intercepting and archiving encrypted traffic — TLS sessions, VPN tunnels, encrypted email — with the explicit intention of decrypting it once a capable quantum machine becomes available. This is the harvest now, decrypt later (HNDL) attack model.

The implication is stark: data encrypted today with RSA or ECC that remains sensitive in ten to fifteen years is already at risk. This includes long-lived contracts, medical records, intellectual property, classified government communications, and financial instruments. The window for protecting that data with classical cryptography is closing — not when a CRQC arrives, but right now, because the harvesting is already under way.

NCSC and NIST timelines: what 2026 guidance tells us

Both the UK National Cyber Security Centre (NCSC) and the US National Institute of Standards and Technology (NIST) have moved from research-phase recommendations to firm migration expectations. NIST has stated its intention to deprecate RSA and ECC for most use cases by 2030 and to disallow them entirely by 2035, a position formalised in NIST IR 8547 (2024). The NCCoE migration project is actively producing practice guides to help organisations act within that window.

The NCSC’s guidance, updated through 2025–2026, explicitly recommends that UK organisations begin migration planning now, prioritising systems that protect long-lived sensitive data. Critically, neither body treats PQC migration as optional for sectors handling sensitive or regulated data.

Understanding Post-Quantum Cryptography: The Core Concepts

Post-quantum cryptography refers to classical algorithms — software running on conventional hardware — designed to resist attacks from both quantum and classical computers. It is distinct from quantum key distribution (QKD), which relies on quantum physics rather than mathematical hardness.

What makes an algorithm ‘quantum-resistant’?

A quantum-resistant algorithm bases its security on mathematical problems for which no known quantum algorithm provides an exponential speedup. The leading families are:

• Lattice-based cryptography: Security rests on the hardness of problems such as Learning With Errors (LWE) and Module-LWE. Lattice schemes offer strong security proofs and practical performance, and they form the basis of the most widely adopted NIST standards.
• Hash-based signatures: Security derives entirely from the collision resistance of hash functions — among the best-understood assumptions in cryptography. Hash-based schemes are conservative and well-suited to use cases requiring long-term verifiability.
• Code-based cryptography: Based on the difficulty of decoding random linear codes. Historically large key sizes have limited adoption, though recent variants are more compact.
• Isogeny-based cryptography: Several candidates were broken during the NIST evaluation process, and this family did not advance to standardisation.

Crypto-agility — the architectural property of being able to swap cryptographic algorithms without redesigning dependent systems — is central to any quantum-resistant strategy. Systems designed with algorithm agility can absorb future algorithm changes far more cheaply than monolithic implementations.

The four NIST-standardised PQC algorithms (ML-KEM, ML-DSA, SLH-DSA, FN-DSA)

Following an eight-year evaluation process, NIST finalised its first set of post-quantum standards in August 2024:

ML-KEM (FIPS 203) is the primary algorithm for key encapsulation and should be the default choice for protecting data in transit — including TLS connections and encrypted messaging. ML-DSA (FIPS 204) is the general-purpose signature algorithm, suitable for certificate signing and code signing. SLH-DSA (FIPS 205) is the conservative hash-based alternative for contexts where implementation simplicity and long-term trust take priority over performance. FN-DSA (FIPS 206) suits bandwidth-constrained environments due to its compact signatures, but its implementation is more complex and requires careful handling to avoid side-channel vulnerabilities.

Note the naming convention shift: NIST no longer uses the competition-era names (Kyber, Dilithium, SPHINCS+, FALCON). Using the standardised names (ML-KEM, ML-DSA, SLH-DSA, FN-DSA) in procurement and policy documents avoids ambiguity between pre-standardisation draft versions and the final FIPS specifications.

Post-quantum/traditional (PQ/T) hybrid schemes explained

A PQ/T hybrid scheme combines a classical key encapsulation or signature with a post-quantum counterpart, typically using both simultaneously such that breaking the combined scheme requires breaking both the classical and the PQC algorithm. For example, a hybrid TLS handshake might combine X25519 (classical ECDH) with ML-KEM-768, ensuring that even if ML-KEM were later found to have a weakness, the classical layer still provides protection — and vice versa for the quantum threat.

The NCSC explicitly endorses PQ/T hybrid schemes as the appropriate transitional posture for most organisations, recognising that both algorithm maturity and interoperability constraints make a pure PQC deployment premature in many environments. NIST’s guidance similarly supports hybrid key exchange during the transition period. Hybrid schemes are not a permanent solution but a pragmatic bridge that maintains backward compatibility while adding quantum resistance.

Phase 1 — Cryptographic Discovery and Inventory

You cannot migrate what you cannot see. The foundation of any PQC programme is a complete and accurate inventory of every cryptographic asset in your environment. This phase is consistently under-resourced in practice, and it is where most migrations stall.

How to build a Cryptographic Bill of Materials (CBOM)

A Cryptographic Bill of Materials (CBOM) is the cryptographic equivalent of a software bill of materials (SBOM): a structured record of every algorithm, key, certificate, protocol configuration, and library in use across your systems. The CBOM should record, for each asset:

• Algorithm type and key size (e.g., RSA-2048, ECDSA P-256)
• Protocol context (TLS, SSH, S/MIME, code signing, VPN)
• Certificate expiry and issuing CA
• Owning system, application, or service
• Whether the asset is internet-facing or internal
• Data classification of what the asset protects
• Dependencies on third-party libraries, hardware, or supplier PKI

The CBOM is a living document. It must be versioned, integrated with change management processes, and updated whenever new systems are deployed or certificates renewed.

Identifying quantum-vulnerable assets: certificates, keys, protocols, libraries

Quantum-vulnerable algorithms include RSA (all key sizes), ECDSA, ECDH, and Diffie-Hellman — whether used in TLS, X.509 certificates, SSH keys, code-signing certificates, or PKI root and intermediate CAs. Symmetric algorithms (AES, SHA-2, SHA-3) are not quantum-vulnerable in the same sense, though key sizes below 256 bits warrant review.

Common locations to audit include:

• TLS certificates and configurations: Web servers, load balancers, API gateways, and any service presenting a certificate. Check cipher suites, key types, and certificate chains.
• SSH keys: Both host keys and user/service account keys. RSA and ECDSA keys are quantum-vulnerable; Ed25519 is not quantum-resistant but is classical-safe.
• PKI infrastructure: Root CAs, intermediate CAs, issuing CAs, OCSP responders, and CRL signing keys. CA private keys often have lifetimes of ten years or more.
• Code signing certificates: Software supply chain integrity depends on these; compromise or future decryption of signing keys could enable malicious code injection.
• VPN and IPsec configurations: Key exchange algorithms (IKEv2 proposals) and authentication certificates.
• Application-layer cryptography: Embedded keys in mobile apps, IoT firmware, and custom cryptographic implementations.
• Third-party and SaaS dependencies: Identity providers, payment processors, and cloud platforms whose cryptographic posture affects your security chain.

Tools and approaches for automated crypto-discovery

Manual audit is insufficient at scale. Several categories of tooling support automated cryptographic discovery:

• Network scanning: Tools such as testssl.sh, Nmap with SSL scripts, and commercial TLS inspection platforms can enumerate cipher suites, certificate details, and protocol versions across network-exposed services.
• Certificate management platforms: Enterprise certificate lifecycle management tools (Venafi, DigiCert CertCentral, and equivalents) maintain certificate inventories and can flag approaching expiry and algorithm types.
• SBOM and code analysis: Static analysis of application source code and dependencies can surface embedded cryptographic calls and library versions. The NIST NCCoE migration project references tooling guidance for this layer.
• Cloud provider APIs: AWS, Azure, and GCP all expose APIs for enumerating certificates, key management service (KMS) keys, and TLS configurations across managed services.
• Hardware inventory: Hardware security modules (HSMs), smart cards, and TPMs may have firmware-level constraints on supported algorithms — these need separate enumeration and vendor engagement.

Phase 2 — Risk Assessment and Prioritisation

Not every quantum-vulnerable asset carries the same risk. A risk-scoring approach allows organisations to direct limited migration resources where the threat is most acute, rather than attempting a simultaneous lift-and-shift of the entire estate.

Classifying data by sensitivity and longevity (‘harvest now’ risk scoring)

The primary driver of HNDL risk is the combination of data sensitivity and data longevity. A useful scoring heuristic:

• High priority: Data that is sensitive today and will remain sensitive for ten or more years — classified or regulated information, long-term financial records, healthcare data, intellectual property with extended commercial value, and state secrets.
• Medium priority: Data that is sensitive today but has a shorter useful life — session tokens, transient authentication credentials, commercial pricing data with a five-year horizon.
• Lower priority: Publicly available data or data with a short sensitivity window where HNDL provides no meaningful adversarial advantage.

Data classification should already exist within your information security framework. The PQC risk assessment layer adds a temporal dimension: how long must this data remain confidential, and does that window extend beyond the likely CRQC horizon?

Prioritising systems: internet-facing vs. internal vs. long-lived data stores

Beyond data classification, system exposure influences prioritisation:

• Internet-facing services are the most exposed to active traffic interception and should be prioritised for hybrid TLS and certificate migration.
• Internal services still warrant migration but face lower interception risk; they can follow internet-facing systems in a phased sequence.
• Long-lived data stores — encrypted databases, archived files, backup systems — may require re-encryption at rest if they protect high-sensitivity, long-lived data.
• PKI root and intermediate CAs with long validity periods (typically five to twenty years) require early attention, because a compromised or quantum-decryptable CA key undermines every certificate it has signed.
• Hardware security modules (HSMs) present a particular constraint: HSM firmware and hardware must support PQC algorithms before dependent systems can migrate. Many HSM vendors are releasing PQC-capable firmware, but the update cycle is slower than software changes. Engage your HSM vendor early to establish their PQC roadmap and any hardware replacement requirements.

Mapping dependencies: third-party suppliers, hardware HSMs, and legacy protocols

Supply chain cryptography is one of the least visible risks. Your migration depends not only on your own systems but on the cryptographic posture of every supplier, SaaS provider, identity federation partner, and hardware vendor in your ecosystem. Key questions to ask:

• Does your CA or PKI vendor have a published PQC roadmap?
• Do your hardware vendors (HSMs, network equipment, IoT devices) support PQC algorithm updates, or will hardware need replacing?
• Do your third-party libraries (OpenSSL, BouncyCastle, and equivalents) have stable PQC releases? OpenSSL 3.5 (2025) includes ML-KEM and ML-DSA support.
• Are legacy protocols in use (TLS 1.0/1.1, SSLv3, older IPsec proposals) that will need upgrading before PQC can be layered on top?

Document dependency chains explicitly in your CBOM. A system cannot migrate to PQC if it depends on a supplier-issued certificate, a shared HSM, or a library that does not yet support the target algorithms.

Phase 3 — Planning Your PQC Migration Roadmap

With a CBOM in place and risks prioritised, you can construct a migration roadmap that is realistic, sequenced, and aligned with regulatory expectations.

Phased migration vs. big-bang replacement: which approach fits your organisation

A phased migration — migrating systems incrementally, by priority tier, over a multi-year programme — is the approach recommended by both NIST and the NCSC for most organisations. Big-bang replacement (migrating everything simultaneously) is operationally unrealistic for any large or complex estate and introduces significant risk of service disruption and misconfiguration.

A practical phased structure:

1. Discovery and inventory (Months 1–6): Complete the CBOM, establish tooling, and baseline the current state.
2. Risk assessment and prioritisation (Months 3–9): Score assets, identify high-priority targets, and engage suppliers.
3. Pilot and proof of concept (Months 6–12): Deploy hybrid TLS and PQC certificates in non-production or low-risk environments to validate performance, tooling, and operational procedures.
4. High-priority migration (Months 12–30): Migrate internet-facing services, PKI infrastructure, and high-sensitivity data systems to hybrid or pure PQC configurations.
5. Broad migration and legacy decommission (Months 24–48+): Extend migration to internal systems and begin deprecating quantum-vulnerable configurations.

Timelines will vary significantly by organisation size, estate complexity, and supply chain dependencies. The CCCS roadmap (published June 2025) suggests that organisations targeting compliance with anticipated post-2030 requirements should have high-priority systems migrated by 2028–2029, allowing time for testing and audit before regulatory deadlines.

Setting realistic milestones aligned with NCSC and NIST guidance

The NCSC recommends that UK organisations:

• Complete cryptographic discovery by 2026–2027.
• Implement hybrid schemes for internet-facing services as a near-term priority.
• Begin PKI migration planning, including CA key replacement timelines, immediately.
• Monitor NCSC algorithm guidance for updates, particularly regarding FN-DSA implementation security and the maturation of PQC libraries.

NIST’s deprecation timeline for quantum-vulnerable algorithms — no use of RSA or ECC for key establishment by 2030, complete disallowance by 2035 — provides hard external milestones for US federal systems and a strong directional signal for UK organisations, particularly those interoperating with US government systems or subject to US-aligned compliance frameworks.

Handling interoperability during the transition period

During migration, systems will need to communicate securely with counterparts that have not yet migrated. The primary mechanisms for managing this transition are:

• Hybrid TLS: TLS 1.3 supports hybrid key exchange groups. Clients and servers that both support hybrid groups negotiate quantum-resistant key encapsulation; those that do not fall back to classical key exchange. This allows a gradual rollout without breaking compatibility.
• Dual-certificate PKI: Issuing both a classical and a PQC certificate for the same entity, allowing systems to negotiate based on capability. This approach has operational overhead but maximises compatibility.
• Algorithm agility in applications: Applications should be designed or updated to select cryptographic algorithms based on configuration rather than hard-coded choices, enabling algorithm updates without code changes.

Interoperability standards for hybrid TLS are actively being developed through the IETF. The X25519MLKEM768 hybrid key exchange group is already implemented in major TLS libraries and browsers as of 2025–2026, and its use in production environments is explicitly supported by NCSC and NIST guidance.

Phase 4 — Implementation: Replacing Quantum-Vulnerable Algorithms

Implementation is where roadmaps meet engineering reality. This phase covers the concrete changes needed at the protocol and infrastructure level.

Updating TLS configurations to support PQC key encapsulation

TLS is the most widespread consumer of public-key cryptography and the highest-priority implementation target for most organisations. The key changes required:

• Upgrade to TLS 1.3 if not already done — TLS 1.2 and earlier do not support the hybrid key exchange groups used for PQC migration.
• Enable hybrid key exchange groups in your TLS library and server configuration. In OpenSSL 3.5+, this includes enabling the X25519MLKEM768 group. LibreSSL and BoringSSL have similar support.
• Update load balancer and reverse proxy configurations (NGINX, HAProxy, AWS ALB, Cloudflare) — these often negotiate TLS independently of application servers and must be updated separately.
• Prioritise hybrid key encapsulation in cipher suite ordering while maintaining classical fallback for clients that do not yet support PQC.

Key encapsulation mechanism (KEM) performance is a consideration: ML-KEM-768 adds modest latency overhead compared to X25519 due to larger key and ciphertext sizes, but benchmarks from the NIST evaluation demonstrate that the overhead is acceptable for the vast majority of web and API traffic. Performance-critical environments should conduct their own benchmarking under realistic load.

Re-issuing certificates and PKI infrastructure with PQC algorithms

Replacing TLS key exchange provides quantum-resistant forward secrecy for data in transit but does not address the authentication layer — the certificates used to verify server identity. Certificate re-issuance with PQC algorithms (ML-DSA or SLH-DSA for signing) requires:

• PQC-capable certificate authorities — either internal CAs updated to support FIPS 204/205, or commercial CAs with PQC issuance capability (availability varies by CA as of 2026).
• Updated certificate lifecycle management tooling to handle PQC certificate enrolment, renewal, and revocation.
• Root and intermediate CA key generation using PQC algorithms, which may require HSM firmware updates or hardware replacement.
• Client-side trust store updates to include PQC root CAs — browser and OS vendors are actively working on this, but enterprise trust stores managed internally require explicit updates.

Certificate re-issuance should be sequenced from the root CA downwards. Replacing a leaf certificate signed by a classical intermediate CA provides limited quantum resistance if the CA signing key itself remains quantum-vulnerable to a HNDL attack targeting the CA’s signing operations.

Code signing, SSH, and VPN: protocol-by-protocol guidance

Code signing: Software supply chain integrity relies on digital signatures. Migrating code signing to ML-DSA or SLH-DSA requires updated signing infrastructure and, depending on the platform, updated verification tooling in build pipelines and package managers. Prioritise signing keys with long validity periods or high-value software artefacts.

SSH: OpenSSH does not yet have a finalised PQC key type in mainstream releases as of early 2026, though hybrid key exchange support is available in some builds. Monitor OpenSSH releases and apply hybrid key exchange support as it becomes available. Audit SSH host keys and user keys against your CBOM and plan re-keying once PQC SSH key types stabilise.

VPN and IPsec: IKEv2 (used in IPsec VPNs) supports additional key exchange (AKE) mechanisms that can incorporate ML-KEM. Major VPN vendors are adding PQC support; check your vendor roadmap. Wireguard uses a custom handshake that does not yet have a finalised PQC integration path — monitor the Wireguard project for updates.

Implementation security pitfalls to avoid

Several failure modes are specific to PQC implementation and warrant explicit attention:

• Side-channel attacks: FN-DSA (FALCON) in particular is sensitive to implementation-level side channels. Use only vetted, constant-time implementations — do not implement PQC algorithms from scratch. Prefer well-audited libraries (liboqs, the Open Quantum Safe project) or those integrated into FIPS-validated modules.
• Mismatched hybrid combinations: Ensure that hybrid scheme implementations actually combine the two algorithms’ outputs (typically via key derivation function combination) rather than using them in parallel without binding. An incorrectly combined hybrid may provide the security of neither.
• Premature deprecation of classical fallback: Do not remove classical algorithm support before your entire ecosystem (clients, servers, suppliers, partners) has migrated. A premature hard cutover can break interoperability with systems you do not control.
• PKCS and ASN.1 compatibility: PQC public keys and signatures are larger than classical equivalents. Some systems have hard-coded size limits in certificate parsing, PKCS#11 interfaces, or HSM key storage. Validate that your full stack handles larger cryptographic objects correctly before production deployment.
• Library version management: PQC library APIs are still stabilising. Pin versions carefully and establish a process for tracking security updates in PQC-related dependencies.

Phase 5 — Testing, Monitoring, and Governance

Migration does not end at deployment. A sustainable PQC programme requires ongoing monitoring, testing, and governance to remain effective as algorithms, threats, and standards evolve.

How to test PQC algorithm performance and compatibility

Before and after deployment, validate:

• Performance benchmarking: Measure TLS handshake latency, throughput, and CPU overhead under realistic load. ML-KEM-768 adds modest overhead; SLH-DSA has larger signature sizes that affect certificate chain sizes and may impact protocols with size constraints. Document baselines and re-test after configuration changes.
• Interoperability testing: Test against a representative sample of clients — browsers, mobile operating systems, API consumers, and partner systems. Use TLS scanning tools to verify negotiated algorithm choices in production.
• Regression testing: Cryptographic changes can surface unexpected failures in systems that assumed specific key or signature sizes. Run full regression suites after any PQC library or configuration change.
• Penetration testing: Include PQC implementation review in red team and penetration testing engagements. Test for side-channel exposure, hybrid combination correctness, and fallback behaviour.

Ongoing crypto-agility: keeping your inventory current

Crypto-agility is not a one-time project. The CBOM must be maintained as a live operational asset:

• Integrate CBOM updates into your CI/CD pipeline so that new software deployments automatically register their cryptographic dependencies.
• Set automated alerts for certificate expiry, algorithm deprecation notices, and library vulnerability disclosures.
• Monitor NIST, NCSC, and ENISA publications for algorithm deprecation timelines and new standardisation activity. NIST is continuing to evaluate additional PQC algorithms (particularly additional key encapsulation candidates) that may be standardised in future rounds.
• Establish a cryptographic change management process so that algorithm updates follow a documented review and approval path rather than ad hoc changes.

Governance frameworks and reporting to leadership

PQC migration is a multi-year, cross-functional programme that requires board-level visibility and executive sponsorship. Governance considerations include:

• CISO reporting: Produce regular (quarterly) programme status reports covering CBOM completeness, migration progress by priority tier, open dependencies, and risk exceptions. Map progress against the NIST deprecation timeline and any sector-specific regulatory requirements.
• Compliance mapping: For UK organisations, map PQC migration progress against NCSC Cyber Essentials Plus, ISO 27001 cryptographic controls, and any sector-specific guidance (FCA, NHS, MOD, and so on). For organisations with EU data obligations, ENISA’s post-quantum guidance is relevant.
• Supplier assurance: Include PQC migration status in third-party risk assessments. For critical suppliers, seek written confirmation of their PQC roadmap and timelines.
• Algorithm deprecation planning: Establish a formal process for responding to NIST or NCSC algorithm deprecation notices, including defined response timelines and escalation paths.
• Budget and resourcing: PQC migration has genuine cost implications — HSM replacement, CA re-issuance, library upgrades, engineering time, and external specialist support. Secure multi-year budget commitments with realistic estimates.

Key Resources: NCSC, NIST, and CCCS Guidance for 2026

The following authoritative sources should be the primary references for any PQC migration programme. This guide is grounded in their published positions; readers should consult the originals directly for the most current guidance.

NCSC post-quantum cryptography guidance summary

The UK National Cyber Security Centre has published a series of PQC guidance documents, including Next Steps in Preparing for Post-Quantum Cryptography (updated 2025–2026). Key NCSC positions include: endorsement of the NIST-standardised algorithms (ML-KEM, ML-DSA, SLH-DSA, and FN-DSA with caveats on implementation complexity); explicit support for