PQC Migration Guide: How to Prepare Before 2030

Why 2030 Is the Real Deadline — Not 2035

Most coverage of post-quantum cryptography focuses on 2035 as the horizon — the point by which NCSC and allied agencies expect organisations to have fully deprecated vulnerable algorithms. That framing is technically accurate but operationally misleading. For many organisations, the effective deadline is considerably earlier, and for some it has already passed.

The ‘Harvest Now, Decrypt Later’ (HNDL) threat explained

The Harvest Now, Decrypt Later attack model is straightforward: an adversary captures encrypted data today, stores it, and decrypts it once a cryptographically relevant quantum computer (CRQC) becomes available. The decryption happens in the future; the damage is done now. Any data with long-term sensitivity — medical records, legal communications, defence contracts, financial agreements — is already at risk if it is being transmitted over classical asymmetric encryption.

This is not a theoretical concern. Intelligence agencies and sophisticated state actors have both the motivation and the storage capacity to execute HNDL campaigns at scale. The UK’s NCSC has explicitly named HNDL as a primary driver of its migration timeline, noting that organisations holding sensitive long-lived data should treat the threat as active rather than prospective.

What NCSC, NIST and ENISA say about the urgency

In its March 2025 publication Timelines for migration to post-quantum cryptography, NCSC set 2028 as the milestone by which organisations should have completed discovery and planning, with high-priority systems migrated by 2031. NIST finalised the first three post-quantum cryptography standards — FIPS 203 (ML-KEM), FIPS 204 (ML-DSA), and FIPS 205 (SLH-DSA) — in August 2024, meaning the technical foundation for migration is now in place. As of 2026, these standards are in active adoption across government and critical infrastructure.

ENISA’s EU co-ordinated PQC roadmap similarly identifies end-2030 as the target for completing migration of high-risk use cases, explicitly acknowledging the HNDL threat as the reason the window is shorter than the full 2035 deprecation horizon suggests.

Why organisations that wait until 2029 will already be too late

A realistic PQC migration for a mid-sized organisation — covering cryptographic discovery, risk assessment, vendor engagement, pilot deployments, and full rollout — takes two to four years when legacy systems are involved. Starting in 2029 means completing in 2031 at the earliest, by which point HNDL-exposed data will have been at risk for years. The 2030 deadline is not about when quantum computers arrive; it is about how long your sensitive data can remain exposed before that arrival.

Understanding PQC: What Changes and What Doesn’t

Post-quantum cryptography refers specifically to classical (software-based) algorithms designed to resist attack by both classical and quantum computers. It is distinct from quantum key distribution (QKD), which uses quantum physics for key exchange — a hardware-dependent approach with significant infrastructure limitations that is not a substitute for PQC in most enterprise contexts.

Which algorithms are vulnerable: RSA, ECC, Diffie-Hellman

The algorithms most commonly used to secure communications today — RSA, elliptic curve cryptography (ECC), and Diffie-Hellman key exchange — all derive their security from mathematical problems (integer factorisation and discrete logarithm) that Shor’s algorithm can solve efficiently on a sufficiently powerful quantum computer. A CRQC running Shor’s algorithm would render these algorithms effectively broken. This affects the majority of current TLS handshakes, X.509 certificate signing, code signing, and VPN authentication.

NIST-standardised PQC algorithms in 2026: ML-KEM, ML-DSA, SLH-DSA

The three algorithms standardised by NIST in August 2024 form the current baseline for migration:

• ML-KEM (FIPS 203) — a lattice-based key encapsulation mechanism, the primary replacement for RSA and ECDH key exchange.
• ML-DSA (FIPS 204) — a lattice-based digital signature algorithm, replacing RSA and ECDSA signatures.
• SLH-DSA (FIPS 205) — a hash-based signature scheme offering a conservative, non-lattice alternative for high-assurance signing use cases.

NIST has also progressed FALCON (now FN-DSA) and is evaluating additional candidates. For most enterprise deployments in 2026, ML-KEM and ML-DSA are the primary algorithms to implement, with SLH-DSA as a secondary option where hash-based signatures are preferred for their different security assumptions.

Symmetric cryptography (AES-256) and its quantum resilience

Symmetric encryption such as AES-256 is affected by Grover’s algorithm, which provides a quadratic speedup in brute-force key search — effectively halving the security level. AES-256 at 256-bit key length retains approximately 128 bits of quantum security, which NIST and NCSC both consider adequate. AES-128, however, would be reduced to 64-bit effective security, which is insufficient. Organisations should ensure they are using AES-256 (not AES-128) for data at rest and in transit, but do not need to replace symmetric encryption with a new algorithm.

Step 1 — Build a Cryptographic Inventory (CBOM)

You cannot migrate what you cannot see. The first and most critical step in any PQC migration is producing a complete picture of every cryptographic asset in your environment — a Cryptographic Bill of Materials (CBOM).

What a Cryptographic Bill of Materials (CBOM) is and why you need one

A CBOM is a structured catalogue of all cryptographic algorithms, key lengths, certificates, libraries, and protocols in use across an organisation’s systems. Modelled conceptually on the Software Bill of Materials (SBOM) used in supply chain security, a CBOM maps where cryptography is used, which algorithms and key lengths are in play, and what data or services each cryptographic asset protects. Without this inventory, migration planning is guesswork.

NCSC’s PQC guidance lists cryptographic discovery as the foundational prerequisite for all subsequent migration activity — a position echoed in NIST’s migration documentation and in ENISA’s roadmap.

How to discover cryptographic assets: tools and manual audit approaches

Cryptographic discovery combines automated scanning with manual review. On the automated side, tools such as CISA’s SCuBA (Secure Cloud Business Applications) project, open-source cryptographic scanners (including IBM’s open-source cbomkit), and network traffic analysis tools can surface TLS versions, cipher suites, and certificate details across external-facing services. For internal systems, code repository scanning can identify hardcoded keys or deprecated library calls.

Manual review remains necessary for legacy systems, bespoke applications, and hardware security modules (HSMs), where automated tools often have limited visibility. PKI environments warrant particular attention: X.509 certificates carry algorithm information explicitly, making certificate stores a useful starting point before broader discovery.

Prioritising assets by sensitivity and HNDL exposure

Not all cryptographic assets carry equal risk. Prioritisation should weight two factors: data sensitivity (how harmful would disclosure be?) and HNDL exposure (how long does this data need to remain confidential, and is it being transmitted in a way that could be harvested?). Long-lived data — patient records, legal contracts, classified communications, intellectual property — should be treated as already at risk if protected only by classical asymmetric algorithms. Cryptographic agility at the asset level — the ability to swap algorithms without architectural changes — should be assessed for each system and flagged where it is absent.

Step 2 — Assess Risk and Define Migration Priorities

Classifying data by long-term sensitivity and HNDL risk

Once the CBOM is in place, risk classification assigns a migration urgency to each asset. A practical three-tier model works well for most organisations:

1. Critical — data that must remain confidential for ten or more years, or that underpins safety-critical systems (government classified data, patient records, financial instruments, CNI operational technology).
2. High — data with a five-to-ten-year confidentiality requirement, or systems where compromise would have significant business or reputational impact.
3. Standard — data with shorter sensitivity windows or lower impact on compromise, where migration can follow the general 2031–2035 timeline.

Mapping regulatory and contractual obligations (UK GDPR, NIS2, DORA)

UK organisations face an evolving regulatory landscape. Under UK GDPR, the requirement to implement “appropriate technical measures” to protect personal data will increasingly be interpreted in light of PQC migration guidance from the ICO and NCSC. NIS2 — which applies to UK organisations with EU-facing operations or EU-based subsidiaries — includes explicit obligations around cryptographic controls for operators of essential services. DORA, applicable to financial entities operating in the EU, similarly requires technology risk management programmes that would encompass PQC migration planning.

Contractual obligations may accelerate timelines further: government supply chain requirements, defence sector contracts, and financial sector frameworks are already beginning to reference NCSC and NIST PQC standards compliance as a condition of engagement.

High-risk use cases: government, financial services, healthcare, critical infrastructure

Certain sectors face acute HNDL exposure. Government and defence organisations handle classified data with decades-long sensitivity windows. Financial services firms transmit transaction data and authentication credentials that are high-value targets. Healthcare organisations hold patient records that are permanent and increasingly digitised. Critical national infrastructure (CNI) operators — energy, water, transport — rely on operational technology where cryptographic updates are infrequent and patch cycles are long. All four sectors should treat their highest-sensitivity systems as already in the critical migration tier.

Step 3 — Select a Migration Strategy

Hybrid cryptography: running classical and PQC algorithms in parallel

A hybrid approach combines a classical algorithm (e.g., ECDH) with a PQC algorithm (e.g., ML-KEM) in the same key exchange, deriving a session key from both. The logic is conservative: if either algorithm is secure, the combined key exchange is secure. This is particularly relevant during the transition period, when PQC algorithm implementations are newer and real-world deployment experience is still accumulating. Post-quantum TLS using hybrid key exchange is now supported in major implementations and is the approach recommended by NCSC for organisations beginning external-facing deployments in 2026.

Full replacement vs. hybrid approach: trade-offs and timing

Full replacement — removing classical algorithms entirely — is the eventual goal, but it introduces backwards compatibility risk and interoperability complexity when deployed prematurely. TLS 1.3 provides the cleanest path for full PQC key exchange once endpoints on both sides support it. For internal systems with controlled endpoints, full replacement may be achievable sooner. For external-facing services with heterogeneous client populations, hybrid deployment is the pragmatic choice until PQC support is sufficiently widespread.

Cryptographic agility as a design principle going forward

The NCSC’s cryptographic agility guidance frames the ability to swap algorithms rapidly — without redesigning systems — as an architectural requirement, not an optional feature. The PQC transition will not be the last algorithm transition organisations face. Designing systems that treat cryptographic primitives as configurable parameters, rather than hardcoded choices, reduces the cost of every future migration. This means abstracting cryptographic operations behind well-defined interfaces, avoiding hardcoded algorithm identifiers in application code, and ensuring key management infrastructure supports multiple concurrent algorithm families.

The NCSC and NIST Migration Timeline: 2026–2035

The following milestones synthesise NCSC’s March 2025 timeline publication, NIST’s PQC migration documentation, ENISA’s EU co-ordinated roadmap, and the NSA’s CNSA 2.0 suite requirements. UK organisations should treat the NCSC milestones as the primary compliance framework, with NIST and CNSA 2.0 as relevant references for organisations with US or NATO-facing obligations.

ENISA’s EU co-ordinated roadmap aligns closely with the 2030–2031 milestone for high-risk systems, making this the operative deadline for organisations with significant EU data processing activity. The 2035 full deprecation date assumes a steady-state migration; it is not a safe starting point for planning.

Practical Implementation: Where to Start in 2026

With FIPS 203, 204, and 205 finalised and in active deployment, 2026 is the year to move from planning to execution on at least a subset of systems. The following sequence reflects the approach recommended by NCSC and corroborated by implementation experience from cloud providers and government agencies.

Quick wins: deploying PQC on external-facing services first

External-facing web services — public APIs, customer portals, partner integrations — are the highest HNDL-exposure surface and the most straightforward to update because both endpoints (server and client) are accessible. Deploying hybrid key exchange (ECDH + ML-KEM) in TLS on these services is achievable with current library support in OpenSSL 3.x, BoringSSL, and AWS KMS. This delivers immediate reduction in HNDL exposure without requiring legacy system changes.

Updating certificate lifecycle management and PKI

PKI modernisation is a prerequisite for broad migration. Certificate authorities (CAs) within your environment need to support ML-DSA or SLH-DSA for certificate signing before PQC certificates can be issued. Certificate lifecycle management tooling must be updated to handle the larger key and signature sizes associated with PQC algorithms. This is also an opportunity to audit certificate expiry practices — shorter-lived certificates (90 days or less, already the direction of travel in the industry) reduce the window during which a compromised certificate can cause harm.

Vendor and supply chain readiness checks

Migration is only as complete as your weakest cryptographic link. Issue questionnaires to critical technology vendors requesting their PQC migration roadmaps, confirmation of FIPS-validated algorithm support, and timelines for hybrid TLS availability. For software supply chain risk, extend CBOM practices to include third-party libraries and open-source components — many applications inherit cryptographic vulnerabilities from dependencies rather than from first-party code. A rollback plan should be documented for each migration step, covering the procedure for reverting to classical algorithms if a PQC deployment causes compatibility or performance issues.

Testing and validation before full rollout

PQC algorithms carry larger key sizes and signature lengths than their classical equivalents — ML-KEM-768 public keys are approximately 1,184 bytes versus 65 bytes for P-256. These size differences can cause issues in systems with fixed-size fields, MTU constraints, or tight bandwidth envelopes. Load and performance testing in a staging environment is essential before production deployment. Interoperability testing against diverse client populations (particularly for public-facing TLS) should confirm that hybrid handshakes complete correctly across browsers, mobile clients, and API consumers.

Common Pitfalls and How to Avoid Them

‘Set and forget’ migration mistakes

The most common migration failure mode is treating PQC deployment as a one-time project that, once complete, requires no further attention. Cryptographic standards evolve: algorithm vulnerabilities are discovered, key sizes are revised, and implementation flaws emerge in production. Organisations that deploy ML-KEM today and consider the matter closed will face the same painful discovery exercise when the next migration requirement arises. PQC migration should be embedded in an ongoing cryptographic governance programme, with annual CBOM reviews and a defined process for responding to algorithm advisories.

Underestimating legacy system complexity

Legacy systems accumulate technical debt in cryptographic assumptions: hardcoded algorithm identifiers, fixed-length certificate fields, HSMs with firmware that cannot be updated to support PQC, and custom TLS stacks that predate modern library abstraction. Discovery frequently reveals that a system believed to use “standard TLS” in fact uses a vendor-specific implementation from 2012. Budget and timeline estimates that assume greenfield deployment will be wrong. Factor in extended discovery time for legacy environments, and plan for the possibility that some systems will require full replacement rather than cryptographic upgrade.

Confusing quantum-safe marketing claims with genuine PQC standards compliance

The PQC vendor landscape in 2026 includes a number of products marketed as “quantum-safe” or “quantum-resistant” that implement proprietary algorithms, use classical algorithms at unusually large key sizes, or conflate quantum key distribution with post-quantum cryptography. The only credible baseline for enterprise PQC is compliance with NIST FIPS 203, 204, and 205 (and, for government systems, NCSC-endorsed implementations). When evaluating vendors, require explicit confirmation of FIPS-validated implementations rather than accepting “quantum-ready” as a sufficient assurance. Where FIPS validation certificates are cited, verify them against the NIST Cryptographic Module Validation Program (CMVP) database directly.

Frequently Asked Questions About PQC Migration

When will quantum computers be able to break current encryption?

There is genuine expert disagreement on this timeline. Credible estimates range from approximately 2030 to well into the 2040s for a cryptographically relevant quantum computer (CRQC) capable of running Shor’s algorithm at scale against RSA-2048. NCSC and NIST do not commit to a single date, which is the intellectually honest position. The operative planning assumption should not be based on a CRQC arrival date but on HNDL exposure — data being transmitted today may be decrypted at whatever point a CRQC arrives.

What is the NCSC’s recommended timeline for PQC migration?

NCSC’s March 2025 guidance sets three milestones: cryptographic discovery and planning completed by 2028, high-priority systems migrated by 2031, and full deprecation of vulnerable algorithms by 2035. Organisations with HNDL-sensitive data should treat 2028 as the operative deadline for their most critical assets.

Which NIST PQC algorithms have been finalised and should organisations use them?

NIST finalised three standards in August 2024: ML-KEM (FIPS 203) for key encapsulation, ML-DSA (FIPS 204) for digital signatures, and SLH-DSA (FIPS 205) as a hash-based signature alternative. These are the algorithms organisations should be planning to deploy. Additional candidates are in the NIST pipeline, but FIPS 203/204/205 are the current implementation baseline.

Is AES-256 quantum-safe?

Yes, with a caveat. Grover’s algorithm halves the effective security of symmetric encryption, reducing AES-256 to approximately 128 bits of quantum security — which NIST and NCSC consider sufficient. AES-128, however, would be reduced to 64 bits, which is not. Organisations should confirm they are using AES-256 rather than AES-128 for sensitive data, but do not need to replace AES with a new algorithm.

What is a Cryptographic Bill of Materials (CBOM) and how do you build one?

A CBOM is a structured inventory of every cryptographic algorithm, key, certificate, and protocol in use across an organisation’s systems. Building one involves automated scanning (network analysis, code repository scanning, certificate store audits) combined with manual review of legacy and bespoke systems. The output is a catalogue that maps each cryptographic asset to the data or service it protects, enabling risk-based migration prioritisation.

Should organisations use hybrid cryptography or migrate fully to PQC?

For external-facing services in 2026, hybrid key exchange — combining a classical algorithm with ML-KEM — is the recommended starting point. It provides immediate HNDL protection while maintaining backwards compatibility. Full migration to PQC-only algorithms is the eventual goal and may be appropriate sooner for controlled internal environments. Cryptographic agility should be built into all new systems to make the transition to full PQC straightforward when the time comes.

What are the regulatory requirements for PQC migration in the UK and EU?

In the UK, NCSC guidance sets the de facto compliance standard; UK GDPR’s “appropriate technical measures” obligation will increasingly reference it. In the EU, NIS2 and DORA both impose technology risk management requirements that encompass cryptographic controls. UK organisations with EU operations or EU-facing services should monitor both NCSC and ENISA publications, as the timelines are broadly aligned but carry different jurisdictional weight.

How long does a PQC migration typically take?

For a mid-sized organisation with a reasonably modern technology estate, a full PQC migration — from initial CBOM through to deprecation of vulnerable algorithms — typically takes three to five years. Organisations with significant legacy systems, complex PKI environments, or large vendor ecosystems should plan for the upper end of that range. Starting in 2026 is consistent with meeting the NCSC’s 2031 high-priority milestone; starting in 2029 is not.