Post-Quantum Cryptography Migration Guide (2026)

Why Quantum Computing Threatens Today’s Cryptography

The security of today’s internet depends overwhelmingly on the computational hardness of two mathematical problems: integer factorisation (underpinning RSA) and the discrete logarithm problem (underpinning Elliptic Curve Cryptography, or ECC). A sufficiently powerful quantum computer would render both trivially solvable — and that has direct consequences for nearly every encrypted connection, signed certificate, and secure protocol in your organisation.

How Shor’s algorithm breaks RSA and ECC

In 1994, mathematician Peter Shor demonstrated that a quantum computer could solve integer factorisation and discrete logarithm problems in polynomial time, compared to the exponential time required by classical computers. In practice, this means a cryptographically relevant quantum computer (CRQC) running Shor’s algorithm could break a 2,048-bit RSA key or a 256-bit ECDSA key in a matter of hours, not geological timescales. The algorithms themselves are not flawed — they are simply built on assumptions that quantum mechanics invalidates.

Symmetric algorithms such as AES-256 and SHA-2 are also weakened by quantum attacks (specifically Grover’s algorithm), but doubling key lengths is generally sufficient to restore their security margin. The existential threat is concentrated in quantum-vulnerable public-key algorithms: RSA, Diffie-Hellman, ECC in all its forms (ECDH, ECDSA, EdDSA), and any protocol that depends on them.

The ‘harvest now, decrypt later’ attack model

A CRQC capable of breaking 2,048-bit RSA does not yet exist. Estimates from the UK’s National Cyber Security Centre (NCSC) and IBM’s quantum roadmap suggest the timeline to such capability remains uncertain, but credible assessments place the risk window within the 2030s. The NCSC’s 2025 guidance notes that whilst a CRQC is not imminent, the uncertainty itself is sufficient to justify action now.

The reason urgency is warranted today is the harvest now, decrypt later attack model. Adversaries — particularly well-resourced nation-state actors — are plausibly recording encrypted traffic today with the intention of decrypting it once a CRQC becomes available. Any data that must remain confidential for ten or more years is already at risk. This includes health records, intellectual property, legal communications, government intelligence, and long-lived authentication credentials.

Which algorithms are at risk — and which are not

The table below summarises the exposure landscape:

The core takeaway: if your system uses any form of public-key cryptography for key exchange or digital signatures, it requires migration.

The PQC Standards Landscape in 2026

Before scoping a migration programme, security teams need clarity on which algorithms are standardised, authoritative, and safe to deploy. That clarity now exists.

NIST FIPS 203, 204 and 205 — what they standardise

Following an eight-year public evaluation process, the US National Institute of Standards and Technology (NIST) finalised three post-quantum cryptography standards in August 2024:

• FIPS 203 — ML-KEM (Module-Lattice Key Encapsulation Mechanism, based on Kyber): the primary standard for key encapsulation. ML-KEM is lattice-based and offers three security levels (ML-KEM-512, ML-KEM-768, ML-KEM-1024). Most organisations should target ML-KEM-768 as a baseline.
• FIPS 204 — ML-DSA (Module-Lattice Digital Signature Algorithm, based on Dilithium): the primary standard for digital signatures, also lattice-based. ML-DSA-65 is the recommended baseline security level.
• FIPS 205 — SLH-DSA (Stateless Hash-Based Digital Signature Algorithm, based on SPHINCS+): a hash-based signature scheme retained as a diversity option where lattice-based signatures are not appropriate. SLH-DSA produces larger signatures and is computationally slower, but its security relies solely on the properties of hash functions rather than lattice hardness assumptions.

NIST’s NCCoE Migration to Post-Quantum Cryptography project provides supplementary migration guidance alongside these standards, including practice guides for specific technology domains.

NCSC guidance and the UK roadmap

The NCSC published updated post-quantum guidance in 2025, endorsing the NIST FIPS algorithms and providing a UK-specific migration roadmap. The NCSC recommends that organisations begin planning now, prioritise long-lived sensitive data for early migration, and adopt hybrid schemes during the transition period. The NCSC’s guidance explicitly endorses ML-KEM, ML-DSA, and SLH-DSA as the algorithms around which UK organisations should build their quantum-safe posture.

CNSA 2.0, EU ENISA and global alignment

Global alignment is strong, which simplifies vendor sourcing and interoperability planning:

• NSA CNSA 2.0 (Commercial National Security Algorithm Suite 2.0) mandates full PQC adoption for US National Security Systems by 2033, with specific algorithm requirements that mirror the NIST FIPS selections.
• ENISA (the EU Agency for Cybersecurity) published recommended cryptographic measures in 2024 that align with the NIST selections and provide guidance relevant to UK organisations subject to NIS2 or DORA obligations.
• Canada, Australia, and Germany have each issued national roadmaps that similarly converge on the FIPS 203/204/205 algorithm set, as documented by PQShield’s comparative analysis of global PQC transition roadmaps.

The PQC standardisation process is not finished — NIST continues to evaluate additional signature schemes — but for the vast majority of enterprise use cases, the three finalised standards provide a stable, authoritative target.

Step 1 — Establish a Quantum Readiness Programme

Before touching a single system, your organisation needs a governance structure. Without executive sponsorship and defined ownership, cryptographic migrations stall at the discovery phase.

Appointing a cryptographic governance owner

Designate a cryptographic governance owner — typically the CISO, a senior security architect, or a dedicated programme lead. This person is accountable for the organisation’s overall cryptographic posture management, including the PQC transition. The NCSC recommends that this role sits at a level with authority to direct procurement decisions and mandate changes to development standards.

Scoping: which systems, data and timelines matter most

Define scope early. A quantum readiness programme should cover:

• All systems that store, process, or transmit data requiring confidentiality beyond 2030
• All public-key infrastructure (PKI) components — Certificate Authorities, certificate lifecycle management, registration authorities
• All external-facing services using TLS, SSH, or S/MIME
• Supply chain interfaces: APIs, EDI connections, software signing pipelines

Scoping also means defining your organisation’s risk appetite: how long does your sensitive data need to remain confidential? A ten-year data retention policy creates a different urgency profile than a two-year one.

Building cross-functional buy-in (security, DevOps, procurement)

PQC migration is not a security team project. It requires stakeholder alignment across security, infrastructure, DevOps, application development, legal, and procurement. Procurement matters particularly because vendor and library readiness varies enormously — buying new hardware or renewing long-term SaaS contracts without checking PQC support locks you into quantum-vulnerable systems for years. Build PQC requirements into procurement checklists immediately. Establish crypto agility as a standard architectural requirement for all new development from this point forward.

Step 2 — Perform a Cryptographic Discovery and Build Your Inventory

You cannot migrate what you cannot see. A comprehensive cryptographic discovery exercise is the technical foundation of any PQC programme — and it is almost always more complex than organisations anticipate.

What to scan: certificates, libraries, protocols, APIs

Cryptographic discovery must be exhaustive. At minimum, scan for:

• X.509 certificates: every TLS certificate, code-signing certificate, and client certificate, including those issued by internal Certificate Authorities
• Cryptographic libraries: OpenSSL, BouncyCastle, NSS, Java JCE providers, and any custom or vendored cryptographic code
• Protocol configurations: TLS cipher suites and versions, SSH key exchange algorithms, IPsec IKE configurations, PGP/S/MIME key material
• API integrations: third-party APIs that use JWT, OAuth, or mutual TLS — particularly where key material is shared or long-lived
• Embedded firmware and IoT devices: hardware that cannot be easily updated and may be running hard-coded cryptographic parameters

Automated discovery tools and CBOM (Cryptographic Bill of Materials)

Manual discovery is insufficient at enterprise scale. Use automated discovery tooling — certificate management platforms, code-scanning tools, network traffic analysis — to build a structured cryptographic inventory. The emerging standard for representing this inventory is the Cryptographic Bill of Materials (CBOM), an extension of the Software Bill of Materials (SBOM) concept that catalogues every cryptographic asset, its algorithm, key length, and location in the system. A CBOM enables systematic tracking of quantum-vulnerable dependencies throughout your software supply chain — a significant gap in most current security programmes.

Mapping data flows that use public-key cryptography

Beyond static asset inventory, map the data flows: where is public-key cryptography used for key exchange, where for authentication, and where for long-term data encryption at rest? Understanding the purpose of each cryptographic usage determines the right migration path. A TLS handshake and an encrypted database backup have very different migration priorities and timelines.

Step 3 — Assess Risk and Prioritise Migration Targets

Not all quantum-vulnerable systems carry equal risk. A structured prioritisation framework prevents organisations from spending migration effort on low-value targets while high-risk systems remain exposed.

Classifying long-lived sensitive data (‘harvest now’ exposure)

The primary driver for early migration priority is data sensitivity classification combined with data longevity. Ask: if this encrypted data were harvested today and decrypted in 2032, what would the impact be? Data categories warranting urgent attention include:

• Personally identifiable information (PII) subject to long retention periods
• Financial transaction records
• Intellectual property, trade secrets, and R&D data
• Legal and contractual communications
• Credentials and key material that authenticate privileged access

Scoring systems by sensitivity, exposure and migration complexity

Score each system across three dimensions: data sensitivity (how damaging is exposure?), network exposure (is this internet-facing, or isolated?), and migration complexity (how hard is it to change the cryptography?). Systems that score high on sensitivity and exposure but low on complexity should be migrated first. Systems with high migration complexity — deeply embedded firmware, legacy mainframes, OT/ICS environments — require longer lead times and should appear early in planning even if their operational exposure seems low.

Regulatory and compliance obligations (NIS2, DORA, UK GDPR)

UK organisations with EU operations, or those providing services to EU entities, face direct regulatory drivers. NIS2 (the EU Network and Information Security Directive, transposed across EU member states from October 2024) includes explicit requirements for cryptographic controls and supply chain security. DORA (the Digital Operational Resilience Act, applicable to financial entities from January 2025) mandates ICT risk management frameworks that encompass cryptographic resilience. The UK’s own NIS Regulations and UK GDPR impose comparable obligations on data security. Mapping your PQC migration roadmap against these compliance frameworks creates a regulatory justification for investment and helps prioritise systems in scope for each regulation.

Step 4 — Select Post-Quantum Algorithms for Each Use Case

Algorithm selection is not a single decision — it depends on what cryptographic function you need, in which protocol, and in which operational context. The following guidance reflects the NIST FIPS standards and NCSC recommendations current as of 2026.

Key encapsulation mechanisms (KEM) vs. digital signatures

Post-quantum algorithms divide into two functional families:

• Key Encapsulation Mechanisms (KEM): used to establish shared secrets for symmetric encryption. The standardised choice is ML-KEM (Kyber) per FIPS 203. Use ML-KEM-768 as the default; ML-KEM-1024 for the highest security tier.
• Digital signature schemes: used for authentication, code signing, and certificate issuance. The primary choice is ML-DSA (Dilithium) per FIPS 204. Where algorithm diversity is required — particularly for long-term signatures or where lattice assumptions require a hedge — SLH-DSA (SPHINCS+) per FIPS 205 provides a hash-based alternative with well-established security properties.

PQ/T hybrid schemes: when and why to use them

A post-quantum/traditional hybrid (PQ/T) scheme combines a classical algorithm (e.g. X25519, RSA) with a PQC algorithm (e.g. ML-KEM) such that security is maintained if either component remains unbroken. Both the NCSC and NIST recommend hybrid schemes during the transition period for two reasons: they protect against unforeseen weaknesses in new PQC algorithms, and they maintain backward compatibility with systems that do not yet support PQC. The IETF has standardised hybrid key exchange for TLS 1.3 (draft-ietf-tls-hybrid-design); X25519MLKEM768 is the currently recommended hybrid group. Plan to migrate to pure PQC once confidence in algorithm maturity is established, likely in the late 2020s.

Performance trade-offs: lattice vs. hash-based algorithms

Performance differences are real and must be factored into deployment planning. As a concrete illustration: an ML-KEM-768 public key is approximately 1,184 bytes, compared to 32 bytes for X25519. ML-DSA-65 signatures are approximately 3,309 bytes, compared to 64 bytes for Ed25519. These larger sizes affect TLS handshake latency, certificate chain sizes, and bandwidth on constrained networks. SLH-DSA signatures are considerably larger still (up to 50 KB for some parameter sets), making them unsuitable for latency-sensitive or bandwidth-constrained applications. For IoT and embedded environments, evaluate whether ML-KEM-512 or alternative lightweight schemes meet both security and resource constraints.

Protocol constraints (TLS 1.3, SSH, S/MIME, code signing)

Algorithm selection must account for protocol support maturity:

• TLS 1.3: hybrid PQC key exchange is available in current versions of OpenSSL (3.x), BoringSSL, and leading cloud load balancers. Certificate signatures in TLS chains require PQC-capable Certificate Authorities — availability is growing but not universal in 2026.
• SSH: OpenSSH 9.0+ supports ML-KEM hybrid key exchange. Update SSH configurations to include hybrid groups explicitly.
• S/MIME and code signing: standards work is ongoing; plan for migration in 2027–2028 as CA/Browser Forum and RFC processes mature.
• Implementation security: use vetted, maintained library implementations — do not implement PQC algorithms from scratch. Side-channel resistance is non-trivial even for standardised schemes.

Step 5 — Build and Execute Your Migration Roadmap

With discovery complete, risk prioritised, and algorithms selected, the migration roadmap translates strategy into sequenced, deliverable action. A phased approach reduces operational risk and allows lessons from early deployments to inform later rollouts.

Phasing the rollout: pilot → staged → full production

1. Pilot phase: select two to four non-critical but representative systems — ideally one internet-facing service using TLS and one internal service using SSH or a code-signing pipeline. Deploy hybrid PQC configurations, validate performance, and document operational lessons.
2. Staged rollout: expand to high-priority systems identified in Step 3, beginning with internet-facing services and certificate-dependent infrastructure. Validate interoperability with third parties at each stage.
3. Full production: complete migration of all in-scope systems; retire quantum-vulnerable algorithm configurations; update cryptographic standards documentation.

Prioritising internet-facing and certificate-dependent systems first

Internet-facing systems have the highest exposure to passive traffic collection — harvest now, decrypt later attacks target these specifically. Certificate-dependent systems (web servers, API gateways, email gateways) also drive supply chain dependencies: your certificate lifecycle management processes, ACME integrations, and CA relationships all need updating in parallel with server configuration. Coordinate certificate renewals with your CA to request PQC or hybrid certificates; leading commercial CAs began offering hybrid certificate options in 2025.

Vendor and supply-chain readiness checks

Your migration is only as complete as your supply chain. For each third-party vendor or SaaS provider, confirm: does their product support PQC or hybrid key exchange? What is their published migration timeline? Embed PQC readiness as a criterion in annual vendor reviews and contract renewals. The NCCoE Migration to Post-Quantum Cryptography project publishes practice guides for specific technology sectors that can be used as reference checklists in vendor assessments.

Suggested timeline milestones for 2026–2030

These milestones are indicative targets consistent with NCSC and NIST NCCoE guidance; the right timeline for your organisation depends on your specific risk profile, regulatory obligations, and system complexity.

Step 6 — Maintain Crypto Agility for the Long Term

Migration to post-quantum algorithms is not a one-time project — it is the beginning of an ongoing cryptographic governance discipline. Crypto agility, the ability to change cryptographic algorithms across your systems without requiring re-architecture, is the property that will determine how efficiently your organisation responds to future algorithm deprecations, vulnerabilities, or evolving standards.

What cryptographic agility means in practice

Algorithm agility means your systems select algorithms through configuration or policy, not hardcoded constants. In practice, this means:

• TLS cipher suite selection driven by a central policy engine, not per-application code
• Cryptographic libraries referenced as versioned dependencies that can be updated independently
• Certificates managed through automated certificate management platforms (supporting ACME or equivalent) rather than manual processes
• Algorithm parameters (key sizes, signature schemes) configurable without application redeployment wherever possible

Designing systems to swap algorithms without re-architecture

For new system development, establish crypto agility as an architectural requirement from day one. Abstract cryptographic operations behind well-defined interfaces; do not scatter direct calls to specific algorithm implementations throughout application code. For legacy systems undergoing PQC migration, use the migration as an opportunity to introduce this abstraction layer — it is the primary long-term return on the migration investment.

Ongoing monitoring and posture management

Establish continuous cryptographic posture management: automated scanning of certificate inventories, protocol configurations, and dependency versions on a recurring schedule. When NIST or the NCSC issue algorithm deprecation notices or security advisories — as they did for SHA-1 and for several PQC candidates during the evaluation period — your organisation should be able to assess impact within days, not months. Build cryptographic posture into your existing security monitoring and vulnerability management workflows rather than treating it as a separate discipline.

Common PQC Migration Pitfalls to Avoid

The following are the most frequently observed failure modes, drawn from early PQC pilot deployments and the migration literature. Avoiding them will save significant remediation effort.

Underestimating performance overhead in constrained environments

ML-KEM and ML-DSA perform well on modern server hardware, but performance overhead in constrained environments — IoT devices, embedded controllers, older mobile hardware, high-frequency trading systems with microsecond latency budgets — can be significant. Test PQC algorithms against your actual hardware and latency requirements before committing to a deployment approach. For some IoT and embedded use cases, a migration to PQC may require hardware refresh alongside software changes; factor this into programme planning and budget. Do not assume that server benchmarks translate to edge or operational technology environments.

Migrating TLS without addressing non-TLS protocols

TLS is the most visible target, but it is rarely the only quantum-vulnerable protocol in an enterprise environment. SSH, IPsec, PGP email, code-signing certificates, firmware update authentication, and DNSSEC all rely on public-key cryptography. Migrating TLS whilst leaving SSH key exchange or code-signing infrastructure on RSA/ECC is a common gap that creates a false sense of completeness. Your cryptographic inventory (Step 2) should explicitly flag non-TLS protocols; ensure the migration roadmap addresses them with equivalent rigour. Backward compatibility negotiation in SSH and IPsec also needs careful testing to avoid connectivity failures with unupgraded peers.

Skipping interoperability testing with third parties

PQC interoperability testing is non-trivial because different vendors implement the same algorithms using different library versions, parameter encodings, or hybrid key exchange formats. Connecting two systems that each claim PQC support does not guarantee they will successfully negotiate a PQC session. Before deploying to production, test PQC connectivity explicitly with each significant third-party integration: payment processors, cloud providers, government gateways, B2B API partners. Use the NIST interoperability testing resources and IETF test vectors where available. Document which hybrid groups and algorithm versions each integration supports, and version-pin configurations until interoperability is confirmed stable.

Frequently Asked Questions on PQC Migration

When do quantum computers pose a real threat to current encryption?

No publicly known quantum computer is close to the scale required to break RSA-2048 or ECC-256 today. CRQC timeline estimates from credible bodies — including the NCSC and IBM’s published quantum roadmap — suggest that a cryptographically relevant quantum computer capable of running Shor’s algorithm at useful scale is unlikely before the early 2030s, and may take longer. However, given the harvest now, decrypt later threat model, organisations with long-lived sensitive data should treat the threat as present, not future. The NCSC advises beginning planning immediately regardless of CRQC timeline uncertainty.

Is post-quantum cryptography already standardised?

Yes. NIST finalised three PQC standards in August 2024: FIPS 203 (ML-KEM), FIPS 204 (ML-DSA), and FIPS 205 (SLH-DSA). These are production-ready standards, not experimental proposals. Multiple major cryptographic libraries (OpenSSL 3.x, BouncyCastle, liboqs) and cloud providers already support them. The NCSC endorses the NIST selections for UK use. The FIPS finalisation in 2024 marked the end of the experimental phase — organisations can and should begin deploying against these standards now.

Can I use PQC algorithms alongside existing ones?

Yes — and for most use cases during the transition period, you should. Post-quantum/traditional hybrid (PQ/T) schemes combine a classical algorithm with a PQC algorithm, maintaining security if either remains unbroken. This is the approach recommended by both the NCSC and NIST for the current transition period. It addresses the practical concern that PQC algorithms, whilst rigorously evaluated, have not yet accumulated the decades of real-world cryptanalytic scrutiny that RSA and ECC have. The hybrid transition also eases deployment by maintaining interoperability with systems that do not yet support pure PQC.

Where should a small organisation start with PQC migration?

For small and medium-sized organisations, the NCSC provides specific SME guidance that prioritises pragmatism over comprehensiveness. Start with three actions: (1) identify whether your organisation holds data that must remain confidential beyond 2030 — if not, your urgency is lower; (2) check whether your key software vendors and cloud providers have published PQC roadmaps, and factor this into renewal decisions; (3) ensure any new systems, cloud services, or SaaS contracts you sign from today include PQC support commitments. A full cryptographic discovery exercise and formal programme may be disproportionate for a ten-person organisation — but vendor lock-in and long-lived sensitive data are risks that apply at any scale. The NCSC’s advice is a practical starting point for smaller teams working without dedicated security architects.

Disclaimer: Algorithm selections and migration timelines in this guide reflect NCSC, NIST, and ENISA guidance current as of early 2026. Cryptographic standards evolve; validate all algorithm choices against your organisation’s specific threat model, regulatory obligations, and the latest published guidance before implementation. This article will be reviewed and updated as standards develop.

Key Takeaways

• All public-key cryptography based on RSA, ECC, or Diffie-Hellman is quantum-vulnerable and requires migration.
• The harvest now, decrypt later threat makes long-lived sensitive data at risk today, not only when a CRQC exists.
• NIST finalised three production-ready PQC standards in August 2024: FIPS 203 (ML-KEM), FIPS 204 (ML-DSA), and FIPS 205 (SLH-DSA). The NCSC endorses all three for UK use.
• Begin with governance and a complete cryptographic inventory (CBOM) before touching any system.
• Use PQ/T hybrid schemes during the transition period; move to pure PQC as ecosystem maturity allows.
• UK regulatory drivers — NIS2, DORA, UK GDPR — provide compliance justification for investment alongside the security case.
• Build crypto agility into every new system from today; it will reduce the cost of every future cryptographic transition.