Post-Quantum Cryptography Migration Guide 2025–2026

Why the Quantum Threat Is No Longer a Distant Concern

For most of the past decade, quantum computing felt like a problem for the next generation of security professionals to solve. That framing is no longer defensible. The convergence of maturing quantum hardware, finalised post-quantum cryptography (PQC) standards from the National Institute of Standards and Technology (NIST), and explicit guidance from the UK’s National Cyber Security Centre (NCSC) has moved this from horizon-scanning to active risk management.

What makes quantum computers a threat to current encryption

The encryption algorithms that protect the vast majority of internet traffic — RSA, Elliptic Curve Cryptography (ECC), and Diffie-Hellman key exchange — derive their security from mathematical problems that classical computers cannot solve in a practical timeframe. Factoring a 2,048-bit RSA modulus, for instance, would take a classical machine longer than the age of the universe.

Shor’s algorithm, published by mathematician Peter Shor in 1994, changes this equation entirely. Running on a sufficiently powerful quantum computer, Shor’s algorithm can solve integer factorisation and discrete logarithm problems in polynomial time — effectively breaking RSA and ECC. A cryptographically relevant quantum computer (CRQC), defined as one with enough error-corrected qubits to run Shor’s algorithm against real-world key sizes, would render today’s asymmetric encryption obsolete.

Symmetric encryption is less immediately threatened. Grover’s algorithm can theoretically halve the effective key length of a symmetric cipher, reducing AES-256 to roughly AES-128 equivalent security — significant, but not catastrophic. The primary concern is asymmetric cryptography.

The ‘harvest now, decrypt later’ attack strategy

The most pressing near-term risk is not that adversaries will use a CRQC today. It is that they are collecting encrypted data now, with the intention of decrypting it once a sufficiently powerful quantum computer becomes available. This strategy — commonly called harvest now, decrypt later (HNDL) — is analogous to photographing a locked safe today and working out the combination over the following years.

Intelligence agencies, nation-state actors, and well-resourced criminal groups are assumed to be harvesting sensitive encrypted traffic. Any data that must remain confidential for ten or more years — classified government communications, healthcare records, financial transaction histories, intellectual property — is already at risk under this model.

Why 2025–2026 is the critical preparation window

Forecasts for when a CRQC will exist vary considerably, and it would be misleading to cite a single “Q-Day” year as fact. Credible estimates from bodies including the NCSC range from the early 2030s to the mid-2040s, with significant uncertainty on both sides. What is not uncertain is the lead time required for enterprise cryptographic migration.

Historical precedent is instructive: the transition from SHA-1 to SHA-2, and from TLS 1.0 to TLS 1.3, each took the better part of a decade to complete across real-world infrastructure. PQC migration is considerably more complex. Organisations that begin their cryptographic inventory and governance work in 2025 will be in a position to execute a managed transition. Those that wait for a CRQC to appear will not.

Understanding the New NIST Post-Quantum Cryptography Standards

In August 2024, NIST published three finalised Federal Information Processing Standards (FIPS) for post-quantum cryptography, completing a standardisation process that began in 2016 and drew submissions from cryptographers worldwide. These are the algorithms organisations should be planning to adopt.

ML-KEM (formerly CRYSTALS-Kyber): key encapsulation

Standardised as FIPS 203, ML-KEM (Module-Lattice-Based Key-Encapsulation Mechanism) is the primary standard for key exchange and key encapsulation. It replaces RSA and ECC-based key exchange in protocols such as TLS and is the algorithm most immediately relevant to securing data in transit.

ML-KEM is based on lattice-based cryptography — specifically, the hardness of the Module Learning With Errors (MLWE) problem. It comes in three security levels: ML-KEM-512, ML-KEM-768, and ML-KEM-1024. ML-KEM-768 is broadly considered equivalent in security to AES-192 and is the recommended starting point for most enterprise deployments. Its public key is 1,184 bytes — larger than an RSA-2048 public key (256 bytes), but manageable within most protocol constraints.

ML-DSA (formerly CRYSTALS-Dilithium): digital signatures

Standardised as FIPS 204, ML-DSA (Module-Lattice-Based Digital Signature Algorithm) is the primary standard for digital signatures. It is the successor to CRYSTALS-Dilithium and covers use cases including code signing, document authentication, certificate issuance, and TLS handshake authentication.

Like ML-KEM, ML-DSA is grounded in lattice-based cryptography and offers three security levels. Signature sizes are larger than ECDSA equivalents — an ML-DSA-65 signature is approximately 3,293 bytes versus roughly 72 bytes for ECDSA P-256 — which has implications for high-throughput signing environments and bandwidth-constrained systems.

SLH-DSA (formerly SPHINCS+): hash-based signatures

Standardised as FIPS 205, SLH-DSA (Stateless Hash-Based Digital Signature Standard) provides an alternative signature scheme based on hash functions rather than lattices. Its security assumptions are more conservative — hash functions have been studied for decades — making it a useful hedge if lattice-based cryptography were ever found to have exploitable weaknesses.

The trade-off is performance: SLH-DSA signatures are substantially larger and slower to generate than ML-DSA. It is best suited to lower-frequency, high-assurance signing scenarios, such as root certificate authority (CA) operations, firmware signing for critical systems, or long-term archival signatures.

What happened to FALCON / FN-DSA?

FALCON, a lattice-based signature scheme based on NTRU lattices, is being standardised separately as FN-DSA under FIPS 206, which was still in draft form at the time of writing. FN-DSA offers smaller signatures than ML-DSA and is well-suited to constrained environments, but its implementation complexity is higher. Organisations should monitor FIPS 206’s progress but need not wait for it before beginning migration planning.

A useful reference for understanding the selection rationale is NIST IR 8413, the status report on the third round of the NIST PQC standardisation process, which documents why these algorithms were selected over others.

Assessing Your Organisation’s Cryptographic Exposure

Before selecting algorithms or procuring new libraries, your organisation needs to know what it is protecting and where cryptography is currently in use. This step is consistently underestimated — and consistently the one that causes migrations to stall.

How to conduct a cryptographic inventory (crypto-agility audit)

A cryptographic inventory is a systematic catalogue of every place your organisation uses cryptography: which algorithms, for what purpose, on what systems, and with what key lifetimes. The goal is not perfection on the first pass; it is building sufficient visibility to prioritise.

Practical steps include:

• Network traffic analysis: Use tools such as Wireshark or commercial network detection platforms to identify TLS versions and cipher suites in active use across your environment.
• Certificate lifecycle audit: Inventory all X.509 certificates, their issuing CAs, validity periods, and the key algorithms they use. Many organisations discover they have hundreds of certificates they did not know existed.
• Application code review: Identify where cryptographic primitives are called directly in application code, rather than inherited from a protocol library. These are often the hardest to migrate.
• Vendor and supply chain review: For software and hardware you do not control, ask vendors directly about their PQC roadmap and whether their products support algorithm agility.

Crypto-agility — the design principle of building systems so that cryptographic algorithms can be swapped without architectural changes — is the underlying capability you are working towards. Systems that hard-code RSA-2048 throughout their stack will be far more expensive to migrate than those built with configurable algorithm selection.

Identifying high-risk data: what needs protecting first

Not all data is equally sensitive, and not all data has the same confidentiality lifespan. Prioritise systems that handle:

• Data with a sensitivity window exceeding ten years (healthcare records, financial transaction histories, classified information, intellectual property)
• Authentication credentials and private keys with long validity periods
• Data that, if disclosed in future, would cause irreversible harm (personal health information, biometric data)

Data with a short sensitivity window — a session token, a cached web response — is low priority. Focus effort where exposure under HNDL creates real organisational or regulatory risk.

Mapping dependencies: TLS, PKI, VPNs, code signing, IoT devices

Cryptography is embedded throughout enterprise infrastructure, often invisibly. A risk assessment must map at minimum:

• TLS 1.3 endpoints: Web servers, APIs, load balancers, CDNs — all negotiate key exchange and need PQC-compatible cipher suites.
• Public Key Infrastructure (PKI): Internal and external certificate authorities, certificate management systems, and the processes that rely on them (device enrolment, code signing pipelines).
• VPN gateways: IPsec and SSL VPN products vary widely in their PQC support timelines.
• Code signing: Software update mechanisms that verify signatures must migrate before the signing keys they protect.
• IoT and operational technology (OT) devices: Firmware update mechanisms, device authentication, and embedded cryptographic libraries are frequently the most constrained and the most overlooked.
• SSH, S/MIME, and secure email: Often neglected in favour of TLS, but equally exposed.

Building Your PQC Migration Roadmap: A Phased Approach

Migration to post-quantum cryptography is not a single project with a completion date. It is a multi-year programme that must be planned in phases, with governance structures that can sustain effort across budget cycles and organisational changes.

Phase 1 (2025): inventory, prioritisation, and governance

The immediate priority is establishing the foundations. In 2025, organisations should aim to:

• Complete a first-pass cryptographic inventory covering all production systems.
• Establish a PQC steering group with representation from security, infrastructure, application development, procurement, and legal/compliance.
• Classify assets by risk tier, based on data sensitivity and lifespan.
• Engage key vendors — HSM (hardware security module) suppliers, PKI providers, cloud platform teams — to understand their PQC support timelines.
• Review NCSC and NIST guidance documents and incorporate PQC requirements into procurement standards going forward.

Phase 2 (2025–2026): hybrid cryptography and pilot deployments

Hybrid cryptography involves running a classical algorithm and a post-quantum algorithm in parallel, so that the combined key exchange is secure as long as either algorithm remains unbroken. For example, combining X25519 (a widely deployed elliptic curve algorithm) with ML-KEM produces a hybrid key exchange that is protected against both classical attacks and quantum attacks simultaneously.

This approach is recommended by both NIST and the NCSC for the transition period. It provides a safety net: if unforeseen weaknesses emerge in a new PQC algorithm, the classical component still provides protection. Major browsers and TLS libraries have already begun implementing X25519 + ML-KEM hybrid modes.

During this phase, organisations should:

• Deploy hybrid TLS cipher suites on internet-facing services handling sensitive data.
• Run pilot PQC deployments in controlled environments to measure performance overhead and integration complexity.
• Begin PKI migration planning — the certificate authority hierarchy is one of the most complex dependencies to change.
• Update cryptographic coding standards and developer guidance to reference the new FIPS standards.

Phase 3 (2026 onwards): full PQC transition and deprecation of legacy algorithms

Once hybrid deployments are validated and vendor support is sufficiently mature, the roadmap moves to deprecating legacy asymmetric algorithms from production systems. This phase involves:

• Removing RSA and ECC-only cipher suites from TLS configurations where hybrid or pure-PQC alternatives are available.
• Issuing PQC-signed certificates for internal and external PKI hierarchies.
• Migrating code signing pipelines to ML-DSA or SLH-DSA.
• Updating firmware signing for IoT and OT devices — this typically requires co-ordination with hardware manufacturers and may be constrained by device lifecycle timelines.

The NIST IR 8413 report provides useful background on algorithm agility as a design principle — the ability to update cryptographic algorithms without replacing entire systems — which underpins all three phases.

Hybrid cryptography: combining classical and post-quantum algorithms

It is worth being precise about what hybrid cryptography does and does not achieve. It provides belt-and-braces security during the transition period; it does not eliminate the need to complete the transition. Running X25519 + ML-KEM indefinitely is not the goal. The goal is to reach a state where ML-KEM (or its successors) can stand alone, with classical algorithms fully deprecated from sensitive contexts.

Key Sectors and Use Cases With Elevated Risk

Financial services and long-lived transaction records

Financial institutions operate under regulatory data retention requirements that frequently extend to seven years or more. Transaction records, audit trails, and contractual agreements signed today could plausibly be decrypted by a CRQC within their mandatory retention period. The Financial Conduct Authority (FCA) has not yet published specific PQC mandates, but prudent organisations are already incorporating PQC timelines into their technology risk frameworks.

Healthcare: protecting patient data with extended sensitivity windows

Patient health records carry sensitivity for a lifetime and beyond. Under the UK General Data Protection Regulation (UK GDPR) and NHS data governance frameworks, healthcare providers have obligations around the confidentiality of health information that extend far into the future. The NHS’s reliance on legacy systems — some of which run cryptographic libraries that predate TLS 1.2 — makes this sector particularly exposed to both HNDL risk and migration complexity.

Critical national infrastructure and government systems

Critical national infrastructure (CNI) — energy, water, transport, communications — operates systems with long asset lifecycles, sometimes measured in decades. Operational technology deployed today may still be in service when a CRQC arrives. For these sectors, the combination of long asset life, safety-critical dependencies, and the difficulty of patching embedded systems makes early planning essential.

UK-specific guidance: NCSC recommendations

The NCSC’s guidance on preparing for post-quantum cryptography is required reading for UK organisations. The NCSC recommends that organisations begin migration planning now, prioritise systems handling data with long confidentiality requirements, and adopt a crypto-agile approach. The NCSC explicitly endorses the NIST-standardised algorithms (FIPS 203, 204, 205) and advises against relying on quantum key distribution (QKD) as a primary solution for most enterprise contexts.

UK organisations operating in regulated sectors should also monitor outputs from the UK Cyber Security Council and sector-specific regulators, which are expected to publish more prescriptive guidance as the NIST standards mature.

Practical Tools, Frameworks, and Vendor Landscape

Open-source PQC libraries: liboqs and the Open Quantum Safe project

The Open Quantum Safe (OQS) project is the most widely used open-source resource for PQC implementation. Its core library, liboqs, provides implementations of the NIST-standardised algorithms and is integrated into forks of OpenSSL (liboqs-OpenSSL) and other widely deployed cryptographic libraries.

For development and testing teams, OQS provides a practical starting point that does not require building PQC algorithm implementations from scratch. Importantly, the project also provides test vectors and interoperability tools, which are essential for validating that hybrid implementations behave correctly across different systems.

Note that production deployments should use vendor-validated or FIPS-certified implementations once these become available, rather than relying on development-grade open-source code in high-assurance environments.

Cloud provider PQC support: AWS, Google Cloud, Microsoft Azure

Major cloud providers have begun integrating PQC support into their cryptographic services, though the picture is evolving rapidly:

• AWS Key Management Service (KMS): AWS has published PQC hybrid TLS support and is integrating ML-KEM into its cryptographic stack. Monitor AWS Security Blog for updates on KMS PQC support timelines.
• Google Cloud KMS: Google has been an early implementer of hybrid PQC in Chrome and is extending this to Cloud KMS. Google’s BoringSSL library includes ML-KEM support.
• Microsoft Azure: Azure has published a PQC migration roadmap and is integrating hybrid key exchange into Azure services. Microsoft is also a contributor to the NIST PQC process.

Organisations using managed cloud cryptography services should check current vendor documentation rather than relying on announcements, as support levels change frequently.

How to evaluate vendors for PQC readiness

When assessing vendors — whether for hardware security modules (HSMs), PKI platforms, network appliances, or SaaS applications — ask the following questions:

• Do your products support the NIST-standardised PQC algorithms (FIPS 203, 204, 205)?
• What is your published roadmap for PQC support, and what is the expected delivery timeline?
• Do you support hybrid classical/PQC modes during the transition period?
• Are your PQC implementations independently validated or FIPS-certified?
• What is the performance overhead of PQC algorithms on your platform, and have you published benchmarks?

The ETSI Quantum-Safe Cryptography Working Group has also published technical specifications and migration guidance that are particularly relevant for organisations operating in European regulatory contexts or dealing with EU-based partners.

Common Mistakes to Avoid During PQC Migration

Waiting for a ‘complete’ standard before starting

A common deferral tactic is to wait until all relevant standards are finalised before beginning. With FIPS 206 (FN-DSA) still in draft and additional NIST work underway, this reasoning can justify indefinite inaction. The three finalised FIPS standards (203, 204, 205) provide a sufficient basis to begin inventory, governance, and hybrid deployment work. Organisations that wait for a complete, static standard landscape will simply not have enough time to migrate before the risk materialises.

Ignoring performance overhead of PQC algorithms

PQC algorithms carry a performance cost. ML-KEM-768 public keys are roughly five times larger than RSA-2048 keys; ML-DSA signatures are significantly larger than ECDSA equivalents. In most enterprise TLS contexts, this overhead is modest and manageable. In high-frequency signing environments, constrained network conditions, or latency-sensitive applications, the impact can be material.

Teams should benchmark PQC algorithms against their specific workloads during Phase 2 pilots, rather than assuming performance will be acceptable. Published benchmarks from the OQS project and hardware vendors provide useful baselines, but actual performance will vary by hardware and implementation.

Neglecting firmware and IoT endpoints

Enterprise PQC programmes frequently focus on TLS and PKI, which are visible and well-understood. IoT firmware update mechanisms, embedded device authentication, and operational technology control systems often use the same vulnerable asymmetric algorithms — but are far harder to update. Firmware that is signed with RSA today will remain signed with RSA until the device is replaced or a firmware update mechanism is itself migrated. Ignoring these endpoints creates a long tail of vulnerability that persists well beyond the main migration.

Conflating quantum-resistant with quantum-safe

These terms are sometimes used interchangeably, but they carry meaningfully different implications. Quantum-resistant typically means that an algorithm is believed to resist known quantum attacks — it is a claim about current analysis. Quantum-safe implies a higher level of confidence in long-term security. Neither term has a single, universally agreed definition.

More importantly, a product marketed as “quantum-safe” without reference to specific algorithms and implementation standards provides a false sense of security. Always ask which algorithms are in use, at which key sizes, and whether they are NIST-standardised or proprietary. Marketing language does not confer security.

Frequently Asked Questions About PQC Migration

Is AES-256 safe from quantum attacks?

Largely, yes. Grover’s algorithm can theoretically reduce the effective security of AES-256 to roughly 128 bits by enabling a quadratic speedup in brute-force searches. AES-256 with 128-bit post-quantum security remains well above any practical attack threshold. Symmetric encryption is not a priority concern for PQC migration. The focus should be on asymmetric algorithms — RSA, ECC, and Diffie-Hellman — which Shor’s algorithm can break entirely.

Does my organisation need to act before quantum computers exist?

Yes. The harvest now, decrypt later threat means adversaries may already be collecting your encrypted data for future decryption. If any of your sensitive data must remain confidential for ten or more years, the risk window is open now — not when a CRQC is announced. Additionally, cryptographic migration takes years; starting after a CRQC appears is starting too late. The Y2Q (years to quantum) problem is a preparation problem, not a reaction problem.

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

Post-quantum cryptography (PQC) refers to classical mathematical algorithms — running on conventional computers — that are designed to resist attacks by quantum computers. Quantum key distribution (QKD) is a separate technology that uses the physical properties of quantum mechanics to exchange cryptographic keys. QKD and PQC are complementary rather than competing approaches. However, the NCSC and most enterprise security guidance recommends PQC as the primary migration path, as QKD requires specialised hardware and has significant deployment constraints. Do not treat QKD as a substitute for PQC migration.