Post-Quantum Cryptography Migration Guide for Enterprises

Why the Quantum Threat Is Real — and the Clock Is Already Ticking

The case for post-quantum cryptography does not rest on speculation. It rests on mathematics, published timelines from national security agencies, and an attack that is already under way — even before a single quantum computer has broken a single key.

What makes current encryption vulnerable to quantum computers

Most enterprise cryptography today relies on two families of public-key algorithms: RSA and elliptic curve cryptography (ECC). Both derive their security from mathematical problems that are computationally infeasible for classical computers to solve — integer factorisation for RSA, and the discrete logarithm problem for ECC.

In 1994, mathematician Peter Shor published an algorithm — now known as Shor’s algorithm — that solves both problems in polynomial time on a sufficiently powerful quantum computer. A machine capable of running Shor’s algorithm at scale, referred to as a Cryptographically Relevant Quantum Computer (CRQC), would render RSA-2048 and standard ECC key lengths effectively broken. Symmetric encryption (AES-256, for example) faces a different and less severe quantum threat, discussed further in the FAQ section below.

Current quantum hardware cannot yet execute Shor’s algorithm against real-world key sizes. The operative question is not if a CRQC will emerge, but when — and expert estimates vary considerably. The NCSC UK, NIST, and the NSA all decline to state a specific year, and that intellectual honesty should be reflected in any enterprise planning. However, most credible assessments place a CRQC within the next ten to fifteen years. That window is shorter than the lifespan of infrastructure decisions being made today.

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

The most immediate and underappreciated risk is the harvest now, decrypt later (HNDL) attack. An adversary intercepts and stores encrypted traffic today — TLS sessions, VPN tunnels, encrypted email — without being able to read it. When a CRQC eventually becomes available, that stored ciphertext can be decrypted retrospectively.

Think of it as a sophisticated adversary taking a sealed safe-deposit box they cannot yet open, and waiting until they acquire the tools to crack it. Any data encrypted now with classical algorithms and transmitted over networks should be considered at risk if its confidentiality needs to extend beyond the likely emergence window of a CRQC. For classified government data, long-term financial records, healthcare information, or intellectual property with a decade-plus shelf life, the threat is active today.

Key deadlines: NIST standards (2024), NSA CNSA 2.0, UK NCSC guidance

Several authoritative bodies have published concrete transition timelines:

• NIST (August 2024): Published the first finalised post-quantum cryptography standards — FIPS 203, FIPS 204, and FIPS 205 — marking the end of a multi-year standardisation process and the formal starting point for enterprise migration.
• NSA CNSA 2.0: The US National Security Agency’s Commercial National Security Algorithm Suite 2.0 sets a target of completing PQC transitions for most systems by 2030, with some categories required even earlier. Enterprises handling US government or defence contracts should treat CNSA 2.0 as a hard deadline, not a guideline.
• NCSC UK: The National Cyber Security Centre has published guidance on preparing for post-quantum cryptography, advising UK organisations to begin migration planning now. The NCSC explicitly identifies the HNDL threat as a present-day concern, not a future one.

Taken together, these signals point to a migration window of roughly six years — from 2024 to 2030 — that is tighter than it appears once organisational complexity is factored in.

Understanding the NIST Post-Quantum Cryptography Standards

Before your organisation can make migration decisions, it is essential to understand what NIST has actually standardised, and why some familiar algorithm names no longer apply.

The four finalised algorithms: ML-KEM, ML-DSA, SLH-DSA, FN-DSA

In August 2024, NIST finalised three post-quantum cryptography standards and released a fourth for public review under draft status:

Additionally, two algorithms — BIKE and HQC — remain under evaluation in NIST’s Round 4 process as potential alternatives, particularly for code-based cryptography. These have not yet been finalised and should not be deployed in production without careful risk assessment.

What happened to CRYSTALS-Kyber and CRYSTALS-Dilithium (naming update explained)

Much of the existing enterprise guidance and vendor documentation references CRYSTALS-Kyber and CRYSTALS-Dilithium. These were the candidate algorithm names used throughout NIST’s evaluation process. Upon finalisation, NIST adopted new, standardised names:

• CRYSTALS-Kyber → now ML-KEM (FIPS 203)
• CRYSTALS-Dilithium → now ML-DSA (FIPS 204)
• SPHINCS+ → now SLH-DSA (FIPS 205)
• FALCON → now FN-DSA (Draft FIPS 206)

When evaluating vendor solutions or reviewing technical documentation, verify whether the implementation conforms to the finalised FIPS specifications. Any tool that references only the legacy candidate names without mapping to FIPS standards may not reflect current requirements.

Which algorithms to prioritise and for which use cases

The choice of algorithm depends primarily on the cryptographic function required:

• Key agreement and encryption (KEM): ML-KEM (FIPS 203) is the primary recommendation. It is the most mature lattice-based key encapsulation mechanism and should be the default choice for replacing RSA-based and ECDH-based key exchange in TLS and similar protocols.
• General-purpose digital signatures: ML-DSA (FIPS 204) is the primary recommendation, offering a balance of performance and security. It is suitable for code signing, certificate authorities, and authentication protocols.
• Signature schemes requiring conservative security assumptions: SLH-DSA (FIPS 205) is based on well-understood hash-based cryptography rather than lattices. It is slower and produces larger signatures but carries a different mathematical risk profile — appropriate where long-term signature validity is critical and performance is less constrained.
• Constrained or high-performance environments: FN-DSA (Draft FIPS 206) produces compact signatures and is efficient for certain use cases, but as a draft standard, production deployment warrants caution.

Step 1 — Conduct a Cryptographic Inventory Audit

Your organisation cannot migrate what it has not mapped. A cryptographic inventory audit is the non-negotiable first step, and it is consistently the most underestimated one. Enterprises frequently discover cryptographic usage embedded in third-party libraries, cloud services, and legacy systems they did not know existed.

What to discover: certificates, keys, protocols, libraries, and dependencies

A comprehensive cryptographic inventory should capture:

• X.509 certificates: Public key infrastructure (PKI) components including TLS certificates, code-signing certificates, client authentication certificates, and internal CA hierarchies. Note algorithm type, key length, and expiry date.
• Cryptographic keys: Keys stored in hardware security modules (HSMs), key management services (KMS), and software keystores. Identify key lengths, algorithms, and associated data classifications.
• Protocols: TLS versions in use (including TLS 1.3 readiness), IPsec configurations, SSH key types, and any proprietary secure channel implementations.
• Libraries and frameworks: OpenSSL, BouncyCastle, LibreSSL, and other cryptographic libraries embedded in applications. Record versions and whether PQC-compatible versions are available.
• Third-party and supply chain dependencies: SaaS platforms, cloud providers, payment processors, and any third party that handles encrypted data on your behalf.

Tools and frameworks for automated crypto discovery

Manual auditing is insufficient at enterprise scale. A number of automated approaches are available:

• Software bill of materials (SBOM) tooling: SBOM generation tools (such as Syft, CycloneDX, or SPDX-compatible toolchains) can identify cryptographic library dependencies across application codebases and container images.
• Network scanning: Tools such as SSLyze, testssl.sh, or commercial vulnerability scanners can enumerate cipher suites, certificate details, and protocol versions across network-facing services.
• Cloud-native discovery: AWS Certificate Manager, Azure Key Vault auditing, and GCP Certificate Authority Service provide inventory capabilities for cloud-managed cryptographic assets. Verify whether your cloud providers have published PQC support roadmaps.
• Dependency scanning in CI/CD pipelines: Integrate cryptographic library detection into existing software composition analysis (SCA) tooling to catch newly introduced vulnerable dependencies at the point of development.

Crypto-agility — the architectural capability to swap cryptographic algorithms without significant rework — should be assessed during this phase. Systems hardcoded to specific algorithms will require more substantial remediation effort.

Prioritising assets by sensitivity and exposure window

Not every asset requires immediate migration. Apply data classification to the inventory output:

1. Highest priority: Long-lived sensitive data (patient records, financial histories, intellectual property, classified information) that is transmitted over networks today and must remain confidential for ten or more years.
2. High priority: Authentication infrastructure (root CAs, HSM-stored keys, identity provider certificates) where compromise would enable broad access.
3. Medium priority: Internal services with limited external exposure and shorter data-sensitivity windows.
4. Lower priority: Short-lived transactional data with no long-term confidentiality requirement, or systems already scheduled for decommission.

Step 2 — Assess Your Risk Exposure and Prioritise Workloads

With an inventory in hand, the next step is translating the threat into organisational risk — accounting for the specific nature of your data, your sector’s threat profile, and the time available before a CRQC becomes a realistic adversarial tool.

Mapping data longevity against the quantum threat timeline

The fundamental equation for risk assessment is straightforward: if the sensitivity lifetime of your data extends beyond the likely emergence window of a CRQC, that data is at present risk from HNDL attacks.

Threat modelling for PQC should factor in:

• How long does this data need to remain confidential?
• Is it currently transmitted over networks where it could be intercepted?
• What is the regulatory or contractual consequence of future disclosure?
• Which threat actors are plausible adversaries, and do they have the capability and motivation to store traffic now?

Nation-state actors are widely assessed to be conducting HNDL collection at present. Organisations in sectors that attract sustained nation-state interest should treat their risk appetite accordingly.

High-priority sectors: financial services, healthcare, critical national infrastructure

Certain sectors face both higher inherent risk and tighter regulatory oversight:

• Financial services: Long-term transaction records, inter-bank communications, and payment infrastructure face both confidentiality and integrity risks. PQC for digital signatures is as important as encryption — an attacker who can forge a signature on a historical transaction has significant leverage.
• Healthcare: Patient data under GDPR and national health data protection frameworks may retain sensitivity for the patient’s lifetime. NHS and private healthcare providers should treat long-lived patient records as priority candidates.
• Critical national infrastructure (CNI): Operators of energy, water, transport, and communications infrastructure are explicitly referenced in NCSC UK guidance and CISA’s Post-Quantum Cryptography Initiative as requiring early migration planning. Operational technology (OT) environments present particular challenges due to long hardware refresh cycles.

Hybrid cryptography as a bridge strategy

Full PQC migration will not happen overnight. Hybrid PQC — running classical and post-quantum algorithms in parallel — provides meaningful protection during the transition period. A hybrid key exchange combines, for example, ECDH and ML-KEM such that an attacker must break both algorithms to compromise the session.

Composite certificates adopt a similar approach for PKI, embedding both a classical and a post-quantum public key within a single X.509 certificate. The IETF and several standards bodies are actively developing specifications for hybrid and composite approaches. This is not a permanent destination — it is a practical mechanism for managing risk while full migration proceeds, and it is consistent with a zero-trust architecture that assumes no single control is sufficient.

Step 3 — Build a PQC Migration Roadmap Aligned to Business Timelines

A migration roadmap that ignores budget cycles, vendor contract windows, and existing infrastructure refresh schedules will not be implemented. The most effective PQC migration programmes are those that integrate with decisions already being made, not those that demand a separate, parallel effort.

A phased approach: awareness → pilot → production migration → full transition

The following phased model reflects the approach recommended by NIST and broadly consistent with NCSC UK guidance:

1. Awareness and inventory (now — 2025): Complete the cryptographic inventory audit described in Step 1. Establish internal awareness at board and CISO level. Identify vendor dependencies and begin conversations with key suppliers about their PQC roadmaps.
2. Pilot and proof of concept (2025 — 2026): Deploy hybrid PQC in low-risk but representative environments. Test ML-KEM in TLS for internal services. Validate tooling, assess performance overhead, and train relevant technical staff.
3. Production migration — high-priority systems (2026 — 2028): Migrate the highest-risk assets identified in Step 2. Prioritise long-lived sensitive data, external-facing PKI, and authentication infrastructure. Require PQC readiness in new vendor contracts from this point forward.
4. Full transition — all systems (2028 — 2030): Complete migration across the full estate, including legacy and OT environments. Achieve crypto-agility across all new development. Align with CNSA 2.0 and NCSC UK deadlines.

Aligning migration with existing refresh cycles (cert renewals, hardware upgrades)

Certificate lifecycle management offers a practical migration lever. Every certificate renewal is an opportunity to introduce PQC or hybrid algorithms without additional disruption. Organisations running two-year certificate validity cycles will have two to three natural migration windows before 2030.

Similarly, hardware refresh cycles for HSMs, network appliances, and servers should be evaluated for PQC compatibility. An HSM that cannot generate or store ML-KEM keys will need replacement; purchasing HSMs without verifying PQC roadmap support today extends the migration problem unnecessarily.

Cloud provider PQC support is advancing. AWS, Google Cloud, and Microsoft Azure have each begun publishing PQC integration roadmaps. Review these commitments when evaluating cloud service renewals and negotiate PQC readiness as a contractual requirement where possible.

Governance: who owns PQC migration in your organisation?

PQC migration cuts across information security, infrastructure, application development, legal, compliance, and procurement. Without clear ownership, it will default to no one. Security governance frameworks should assign accountability explicitly:

• The CISO should own the overall migration programme and report progress at board level.
• PKI and identity teams own certificate and key migration.
• Application security teams own library and protocol-level migration within the software estate.
• Procurement and vendor management own PQC requirements in third-party contracts.
• Compliance and legal own the regulatory mapping described in the compliance section below.

Establishing a cross-functional working group with defined milestones and executive sponsorship is not optional at this scale. Organisations that treat PQC migration as a purely technical problem, without governance structures, consistently underdeliver.

Step 4 — Test, Validate, and Harden Your PQC Implementation

Deploying a NIST-standardised algorithm is necessary but not sufficient. Implementation quality matters enormously in cryptography — and PQC algorithms introduce new considerations around performance, interoperability, and implementation-level vulnerabilities that enterprise teams must address before production rollout.

Performance benchmarking: latency and key-size implications of PQC algorithms

Post-quantum algorithms carry a performance cost relative to classical equivalents. Understanding these trade-offs before deployment prevents unexpected problems in production.

Key size overhead has practical consequences: TLS handshake sizes increase, certificate chains grow, and network-constrained environments (IoT, OT, mobile) may need specific optimisation. Measure actual latency and throughput in your environment — published benchmarks from NIST provide a baseline, but production performance will vary with hardware and implementation.

Interoperability testing across hybrid environments

During the transition period, systems will need to negotiate cryptographic parameters with peers running classical-only, hybrid, or fully PQC configurations. Test explicitly for:

• TLS negotiation between PQC-capable and classical clients and servers.
• Certificate chain validation where intermediate or root CAs use different algorithms.
• API and protocol compatibility with third-party services and partners.
• HSM support for generating, storing, and using PQC keys — not all current-generation HSMs support FIPS 203/204/205 natively.

FIPS 140-3 validation is the relevant standard for cryptographic module security. Confirm that any HSM or software cryptographic library used in production is on the NIST Cryptographic Module Validation Programme (CMVP) list, or has a clear path to validation for PQC algorithms.

Avoiding implementation pitfalls: side-channel attacks and weak RNG

Lattice-based algorithms are not immune to implementation-level attacks. Side-channel attacks — which exploit timing information, power consumption, or electromagnetic emissions to infer secret keys — remain a real concern, particularly for hardware implementations. Use implementations that have been independently reviewed or certified, rather than rolling your own.

Random number generator (RNG) quality is critical for all asymmetric cryptography. A weak or predictable RNG undermines the security of even a correctly implemented PQC algorithm. Ensure that entropy sources comply with NIST SP 800-90 series recommendations.

Penetration testing of PQC implementations should be included in your validation programme before production deployment. Standard cryptographic penetration testing methodologies apply; additionally, test for hybrid downgrade attacks where an adversary forces negotiation to the classical component of a hybrid scheme.

Regulatory and Compliance Landscape for UK Enterprises

US-centric migration guides often treat the regulatory landscape as if it consists solely of NIST and CISA. UK enterprises operate under a distinct — and in some respects more demanding — set of obligations that deserve direct attention.

NCSC UK guidance on quantum-safe cryptography

The NCSC UK has published specific guidance on preparing for post-quantum cryptography, addressed to organisations across the private and public sectors. The NCSC’s position is clear: the threat from harvest now, decrypt later attacks is present today, and organisations holding sensitive data with long-term confidentiality requirements should begin migration planning immediately.

NCSC UK guidance aligns with NIST’s standardised algorithms and encourages organisations to follow the NIST PQC standards as the basis for migration. The NCSC does not prescribe a rigid timeline equivalent to CNSA 2.0, but its advisory language makes the directional expectation clear. UK Government departments and operators of critical national infrastructure should treat NCSC guidance as effectively mandatory.

How PQC intersects with GDPR, NIS2, and the UK Cyber Resilience Act

No current UK or EU regulation explicitly mandates post-quantum cryptography by a specific date. However, several frameworks create obligations that PQC migration directly addresses:

• GDPR Article 32 requires organisations to implement “appropriate technical and organisational measures” to ensure a level of security appropriate to the risk. As the quantum threat becomes more widely understood and NIST standards are published, regulators and courts may increasingly view failure to begin PQC migration as a failure to implement appropriate measures. Organisations should seek legal and compliance counsel on how Article 32 applies to their specific risk profile — this is not a settled point of law, but the direction of travel is clear.
• NIS2 Directive: The NIS2 Directive, applicable from October 2024 across EU member states and with UK equivalents under ongoing development, requires operators of essential and important entities to implement state-of-the-art security measures. Post-quantum cryptography, now standardised by NIST and endorsed by NCSC UK and ETSI’s Quantum Safe Cryptography Working Group, is increasingly part of the state of the art.
• UK Cyber Resilience Act and successor frameworks: The UK’s evolving cyber resilience legislation is expected to increase baseline security requirements for digital products and essential services. Organisations that have begun PQC migration will be better placed to demonstrate compliance as obligations crystallise.

The practical advice is this: do not wait for regulators to mandate PQC explicitly. The combination of existing obligations, authoritative guidance, and the genuine threat landscape already creates a strong compliance case for migration. Document your risk assessment and migration plan now — this demonstrably supports compliance obligations under GDPR Article 32 and NIS2, even in the absence of a specific PQC mandate.

Supply chain obligations: requiring PQC readiness from vendors

Third-party risk management is a significant and often overlooked dimension of PQC migration. Your organisation’s cryptographic posture is only as strong as the weakest link in your supply chain. If a critical SaaS provider, payment processor, or managed security service continues to use classical-only cryptography to handle your sensitive data, your migration effort is materially undermined.

Practical actions for supply chain security:

1. Add PQC readiness questions to vendor security assessments and due diligence questionnaires.
2. Include PQC migration milestones as requirements in new contracts and renewals for high-risk suppliers from 2025 onwards.
3. Request published PQC roadmaps from cloud providers and critical technology suppliers.
4. Align with CISA’s Post-Quantum Cryptography Initiative guidance on supply chain obligations, which is relevant to UK organisations with US supply chain exposure.

Frequently Asked Questions About PQC Migration

Is AES-256 safe from quantum attacks?

AES-256 is not broken by quantum computers in the way that RSA and ECC are. The relevant quantum algorithm here is Grover’s algorithm, which provides a quadratic speedup for searching an unstructured key space. In practice, this halves the effective security of a symmetric cipher: AES-256 drops to approximately 128-bit effective security against a quantum attacker. The consensus among cryptographers is that 128-bit quantum security remains computationally infeasible to attack, and AES-256 is considered quantum-resistant for the foreseeable future. It does not need to be replaced as part of PQC migration, though key management practices around symmetric keys should be reviewed.

When will quantum computers actually break RSA?

There is no expert consensus on a specific year. Estimates range from less than a decade to more than twenty years, with significant uncertainty arising from engineering challenges in qubit stability, error correction, and scale. NIST, NCSC UK, and the NSA all deliberately avoid stating a definitive date. What is agreed is that the uncertainty itself is the risk: an organisation that waits for a confirmed CRQC before migrating will have waited too long. The migration window recommended by CNSA 2.0 — targeting completion by 2030 — accounts for this uncertainty by providing lead time regardless of when a CRQC actually emerges.

Can we run PQC and classical cryptography simultaneously?

Yes — this is the hybrid mode approach described earlier in this guide, and it is actively recommended for the transition period. Hybrid key encapsulation combines an established classical mechanism (such as ECDH) with ML-KEM, producing a shared secret that requires breaking both algorithms. An attacker who can break one cannot recover the plaintext without also breaking the other. This approach is supported in TLS 1.3 extensions, is being standardised by the IETF, and is already implemented in several major cryptographic libraries. Running hybrid mode introduces some additional overhead in key and message sizes, but the security benefit during the transition period is substantial.

How long does a full PQC migration take for a large enterprise?

For a large, complex enterprise, a complete migration across all systems is realistically a five-to-seven-year programme. This reflects the time required for cryptographic inventory at scale, vendor and supply chain alignment, testing and validation, legacy system remediation, and iterative rollout across business units. Organisations with strong crypto-agility — where cryptographic algorithms are abstracted and configurable rather than hardcoded — will complete migration faster. Organisations with large estates of legacy systems, OT environments, or heavily customised applications will face greater complexity. Starting in 2025 with high-priority systems and maintaining consistent momentum is the most effective path to meeting a 2030 target. Do not underestimate the organisational and governance effort alongside the technical work — experience consistently shows that the human and process dimensions are as demanding as the engineering.