Post-Quantum Cryptography Migration Guide for UK Organisations (2026)

Why the 2026 PQC Deadlines Matter for UK Organisations

The conversation around post-quantum cryptography has shifted decisively from research to regulation. For UK organisations, the question is no longer whether to migrate to quantum-resistant cryptography, but whether your organisation has enough runway left to do so safely.

Two forces are converging. First, expert consensus now places the likely arrival of a cryptographically relevant quantum computer — commonly called Q-Day — somewhere in the 2030–2040 range, with some estimates clustering toward the earlier end of that window. Second, and more immediately, the NCSC’s published migration milestones mean that the first mandatory checkpoint is already closer than most IT roadmaps acknowledge.

What ‘Harvest Now, Decrypt Later’ Attacks Mean in Practice

The most urgent reason to act now — years before Q-Day — is the harvest now, decrypt later threat. Adversaries are already exfiltrating encrypted data today with the explicit intention of decrypting it once a capable quantum computer becomes available. Data encrypted under RSA-2048 or elliptic-curve algorithms and captured in 2026 may be readable in 2033 or sooner.

This has direct consequences for any UK organisation handling data with a long confidentiality requirement: healthcare records, financial transactions, legal communications, defence contracts, intellectual property, or anything subject to multi-year regulatory retention. If that data is sensitive today and will still be sensitive in ten years, it is already at risk.

Your security team should therefore treat the migration timeline not as “when do we need to be compliant?” but as “how long does our data need to remain secret?” For many organisations, that calculation points to an urgent start, not a deferred one.

The NCSC Three-Stage Migration Timeline at a Glance (2028 / 2031 / 2035)

The National Cyber Security Centre published its Timelines for migration to post-quantum cryptography guidance in March 2025, establishing three explicit milestones for UK organisations:

• By 2028: Organisations should have completed a full cryptographic discovery and inventory, prioritised assets by risk, and begun migration of the highest-risk systems.
• By 2031: The majority of cryptographic systems should be operating on quantum-resistant algorithms, with hybrid schemes in place where full replacement is not yet feasible.
• By 2035: All systems should be fully migrated to post-quantum cryptography, with classical-only algorithms retired from use.

The NCSC is unambiguous that the 2028 milestone is not advisory — it represents the point at which organisations operating critical national infrastructure or handling government-classified data will be expected to demonstrate meaningful progress. Leaving discovery and inventory until 2027 leaves almost no margin for the inevitable complications.

How UK Obligations Align with NIST, EU and BSI Requirements

NIST finalised its first set of post-quantum cryptography standards in August 2024, publishing FIPS 203 (ML-KEM), FIPS 204 (ML-DSA), and FIPS 205 (SLH-DSA). These are now the baseline reference standards globally, and NCSC guidance is explicitly aligned with them.

The EU’s NIS2 Directive, which came into force for member states in October 2024, does not yet mandate specific PQC algorithms but requires operators of essential services to maintain cryptographic hygiene and demonstrate active risk management — a standard that, in practice, requires PQC planning to be underway. Germany’s BSI goes further, mandating hybrid cryptography (classical plus post-quantum algorithms running in parallel) for certain applications, a position shared by France’s ANSSI.

UK organisations with supply chains, subsidiaries, or customers in EU member states should be aware that BSI and ANSSI requirements may impose more immediate obligations than NCSC guidance alone. According to comparative deadline analysis published by Encryption Consulting in April 2026, the UK’s 2028–2035 window is broadly consistent with US CNSS timelines but sits slightly behind the most demanding EU national agency requirements.

The practical implication: if your organisation is subject to EU regulation or trades with entities that are, the most conservative applicable standard — currently BSI’s hybrid mandate — should frame your migration strategy.

How Long Does PQC Migration Actually Take?

The honest answer is: longer than most organisations budget for, and longer than most initial scoping exercises suggest. This section provides realistic benchmarks rather than optimistic projections.

Why Most Organisations Underestimate the Migration Window

Cryptographic migration is not analogous to a software upgrade cycle. It touches every system that encrypts data, authenticates users, validates software, or protects communications — which, in a modern enterprise, is nearly everything. The challenge is compounded by legacy system dependencies: mainframes, OT devices, HSMs, and embedded systems may use cryptographic primitives baked into firmware that cannot simply be patched.

PKI renewal cycles add further friction. An organisation with thousands of TLS certificates, SSH keys, code-signing certificates, and device identity credentials cannot rotate all of them simultaneously. Certificate lifecycle management at scale requires tooling, automation, and coordination with certificate authorities — none of which can be procured and deployed overnight.

Finally, most organisations significantly underestimate the scope of their cryptographic footprint. Shadow cryptography — cryptographic implementations embedded in third-party libraries, commercial off-the-shelf products, and SaaS dependencies — is invisible until a formal discovery exercise surfaces it.

Typical Duration by Organisation Size and Sector

Based on published migration case studies and NCSC guidance framing, realistic timelines break down broadly as follows:

A large UK bank or telecoms provider beginning its cryptographic discovery in early 2026 is working with a tight margin to meet the NCSC’s 2031 milestone for majority migration — and no margin at all if discovery is deferred to 2027.

The Compressed Window: Mapping Migration Effort Against Q-Day Estimates

Q-Day is not a fixed date, and any source presenting it as one should be treated with scepticism. Current expert consensus — including assessments cited by NCSC and analysis from organisations including the Global Risk Institute — places the probability-weighted range at 2030–2040, with material probability of an earlier occurrence as investment in quantum hardware accelerates.

A large enterprise that needs 5–7 years for full migration must therefore have started, or be starting now, to have any confidence of completion before the lower end of that range. Cryptographic agility — the ability to swap algorithms without wholesale infrastructure replacement — is the risk mitigation for the uncertainty in Q-Day timing, but it requires deliberate architectural investment that cannot be retrofitted at pace.

The phased transition approach endorsed by NCSC acknowledges this reality: beginning with the highest-risk, longest-longevity data assets allows organisations to deliver meaningful risk reduction early, even before full migration is complete. Resource planning should front-load discovery and the migration of Tier 1 assets rather than attempting a uniform, organisation-wide migration that typically stalls under its own complexity.

Step 1 — Cryptographic Discovery and Inventory

You cannot migrate what you cannot see. Cryptographic asset discovery is the non-negotiable foundation of any PQC migration programme, and it is consistently the phase that organisations complete most slowly — because the results are invariably more complex than anticipated.

The NCSC’s own guidance identifies this as the first required action, and the 2028 milestone is, in practical terms, a deadline by which this phase should be complete for all critical systems.

What to inventory. A comprehensive cryptographic discovery exercise should surface every instance of:

• TLS certificates and their associated key types, key lengths, and expiry dates
• SSH keys, including host keys and user authentication keys across all managed and unmanaged endpoints
• Code-signing certificates and their associated private keys
• VPN and IPsec configurations, including IKE key exchange parameters
• Cryptographic libraries embedded in application code (OpenSSL, BouncyCastle, NSS, and equivalents)
• Hardware Security Modules (HSMs) and their firmware-level algorithm support
• Database encryption configurations
• Cloud provider key management services and their current algorithm support status
• Email encryption (S/MIME, PGP) and document signing infrastructure

Shadow cryptography deserves particular attention. This refers to cryptographic implementations embedded in third-party software, firmware, or SaaS platforms that your organisation uses but does not directly control. A payroll system, a building management system, a medical device, or a cloud storage integration may all be performing encryption using classical algorithms — and none of them will appear in a network scan of your own infrastructure.

Building a Cryptographic Bill of Materials (CBOM). The CBOM — analogous to a software bill of materials (SBOM) but focused on cryptographic assets — is the output artefact of the discovery phase. A well-structured CBOM records, for each cryptographic asset: the algorithm in use, the key length, the certificate or key expiry date, the system or application it serves, the data classification of what it protects, and whether the system is internet-facing.

This document becomes the input to risk prioritisation in Step 2, the baseline against which migration progress is measured, and the audit evidence for regulatory compliance. ETSI’s quantum-safe cryptography working group has published guidance on CBOM structure that UK organisations can use as a reference framework.

Tooling. Automated discovery tooling exists for certificate inventory (certificate management platforms with network scanning capability), SSH key discovery, and application dependency scanning. No single tool covers all asset types — expect to combine network-level scanning, static code analysis, agent-based endpoint discovery, and vendor-supplied inventory APIs for cloud and SaaS assets. Your security team should plan the discovery effort as a project in its own right, not as a weekend exercise.

Step 2 — Risk Prioritisation and Migration Strategy Selection

With a CBOM in hand, the next task is to decide what to migrate first, and what migration approach each asset category requires. Not everything needs to move simultaneously, and attempting to do so is one of the most common causes of stalled PQC programmes.

Tiering Assets by Data Sensitivity and Longevity

Risk tiering should combine two variables: data sensitivity (how harmful would disclosure be?) and data longevity (how long must it remain confidential?). The intersection of high sensitivity and long longevity defines Tier 1 — the assets most vulnerable to harvest now, decrypt later attacks and therefore the priority for early migration.

Practical examples of Tier 1 assets in a UK context include: patient health records encrypted in long-term storage, financial transaction logs subject to multi-year regulatory retention, communications between critical national infrastructure operators and government, and software signing keys whose compromise would enable supply chain attacks.

Tier 2 covers assets with either high sensitivity or long longevity but not both — active TLS sessions, for instance, have high sensitivity but low longevity (the risk expires when the session ends). These can be migrated in the second phase. Tier 3 covers low-sensitivity, short-lived assets that can be addressed last.

Hybrid Cryptography vs. Full Algorithm Replacement

For most organisations, the transition period will involve hybrid cryptography: running a classical algorithm (such as ECDH or RSA) in parallel with a post-quantum algorithm, with the security guarantee derived from whichever algorithm remains unbroken. If the quantum computer arrives earlier than expected, the PQC component provides protection. If a flaw is found in the new PQC algorithm, the classical component remains as a fallback.

BSI and ANSSI both mandate hybrid schemes for high-assurance applications, and NCSC endorses the approach for the transition period. The honest trade-off is that hybrid cryptography adds overhead — larger key sizes, increased handshake latency, and additional complexity in key management. These performance impacts are addressed in Step 3, but they should be factored into your strategy selection.

Full algorithm replacement — removing classical cryptography entirely — is the end state for 2035, but it is appropriate sooner for systems where the overhead of running both algorithms is prohibitive and where the risk profile supports it.

Choosing Between NIST-Standardised Algorithms: ML-KEM, ML-DSA, SLH-DSA

NIST finalised three post-quantum cryptography standards in August 2024. Understanding which to use where is fundamental to migration planning:

• ML-KEM (FIPS 203) — formerly known as CRYSTALS-Kyber in pre-standardisation literature — is a key encapsulation mechanism (KEM) based on lattice-based cryptography. It is the primary recommendation for key exchange and key establishment. It should be the default choice for replacing classical key exchange in TLS, VPNs, and secure messaging protocols. ML-KEM offers strong performance characteristics and relatively compact key and ciphertext sizes.
• ML-DSA (FIPS 204) — formerly CRYSTALS-Dilithium — is a digital signature algorithm, also lattice-based. It replaces RSA and ECDSA for authentication and signing purposes: certificate signing, code signing, document signing, and authentication tokens. It is faster than SLH-DSA but produces larger signatures.
• SLH-DSA (FIPS 205) — formerly SPHINCS+ — is a hash-based signature scheme that provides a security guarantee derived from the well-understood properties of hash functions rather than lattice problems. It is the more conservative choice for signing where long-term trust anchors are required (root CAs, firmware signing), because its security assumptions are independent of those underlying ML-DSA. The trade-off is larger signature sizes and slower performance.

Your security architects should note that NIST has also standardised a fourth algorithm, FALCON (now ML-DSA is the primary, with HQC selected as a backup KEM in 2024 standardisation processes — confirm current NIST publication status before finalising your selection). For most UK organisations, the practical guidance is: use ML-KEM for key exchange, ML-DSA for general signing, and SLH-DSA for trust anchors and long-lived signing keys. Both algorithm agility and FIPS compliance should be requirements in any new procurement.

Step 3 — Planning, Validation and Pilot Deployment

Strategy without validation is planning fiction. Before committing to organisation-wide migration, your security team should run structured pilots that surface the real-world complications — performance, compatibility, and vendor readiness — before they become project-blocking issues at scale.

Defining Measurable Migration Milestones Aligned to NCSC Stages

NCSC’s three-stage timeline provides external reference points, but internal milestones need to be more granular. Effective migration programmes define measurable outcomes at each phase: percentage of Tier 1 assets migrated, number of CBOM entries with confirmed quantum-resistant status, and vendor confirmation percentages for supply chain dependencies.

Milestones should be tied to the NCSC’s 2028 checkpoint with a backward-planned schedule. For a large financial services organisation beginning in 2026, a realistic milestone structure might look like: CBOM complete and risk-tiered by Q3 2026; Tier 1 pilot deployments complete by Q1 2027; Tier 1 full migration complete by Q4 2027; Tier 2 migration underway by early 2028. This is an aggressive but achievable schedule that meets the 2028 milestone with margin for slippage.

Certificate lifecycle management must be built into the milestone plan from the start. Migrating to post-quantum certificates while maintaining operational continuity requires careful coordination with certificate authorities, internal PKI teams, and load balancers or reverse proxies that terminate TLS — all of which need to be PQC-capable before certificate rollout begins.

Performance Testing: Latency, Throughput and Device Compatibility

Post-quantum algorithms carry performance implications that are well-documented but frequently underestimated in planning. ML-KEM has a larger public key size than ECDH (800–1,568 bytes depending on security level versus 32–65 bytes for X25519), which increases TLS handshake size. In high-throughput environments — API gateways, load balancers, payment processing systems — this can produce measurable latency impact.

In testing conducted across various TLS 1.3 post-quantum implementations, handshake overhead with ML-KEM is typically in the range of 5–15% additional latency for first connections, with negligible impact on resumed sessions. For most web applications, this is acceptable. For latency-sensitive financial trading systems or real-time communications platforms, it requires careful benchmarking before production deployment.

Device compatibility is a more significant constraint in IoT and OT environments (addressed in the pitfalls section below). For IT infrastructure, your pilot should test PQC algorithm support across: your TLS termination points, VPN endpoints, HSMs (many current models require firmware updates for PQC support — some older models cannot be upgraded), email gateways, and any custom application code that implements its own cryptography.

Throughput testing under load is particularly important for HSMs. Hardware accelerators for classical algorithms (RSA, ECDSA) are common in HSMs; hardware acceleration for lattice-based algorithms is still emerging, which means ML-KEM and ML-DSA operations may run significantly slower on current HSM hardware than their classical equivalents. This is a known constraint that vendors are actively addressing, but it should be tested — not assumed — in your environment.

Vendor and Supply Chain Readiness Checks

Supply chain PQC readiness is one of the most consequential and least-addressed aspects of migration planning. Your security team’s migration plan is only as strong as the cryptographic readiness of your vendors, managed service providers, cloud platforms, and software suppliers.

Your vendor readiness assessment should ask, at minimum: which NIST-standardised algorithms does the product support, and from which version? Is hybrid mode supported? What is the vendor’s published PQC roadmap and committed timeline? Has the product been tested against draft or final FIPS 203/204/205? Who is responsible for certificate rotation in your managed service agreement?

Major cloud providers — including AWS, Microsoft Azure, and Google Cloud — have published PQC roadmaps and begun implementing post-quantum TLS in their services. AWS KMS, for example, has begun offering ML-KEM support in hybrid TLS configurations. However, coverage varies by service, and your security team should not assume that because a cloud provider has announced PQC support, every service you use is covered. A service-level inventory of cloud cryptographic dependencies should be part of your CBOM.

Step 4 — Full Migration, Monitoring and Cryptographic Agility

Full migration is not the end of the programme. The post-migration phase — maintaining cryptographic agility, retiring classical algorithms on a defined schedule, and building monitoring capability for quantum-era threats — is where many organisations underinvest, only to find themselves repeating large portions of the migration effort when the next algorithm update arrives.

Retiring Classical-Only Algorithms on Schedule

Algorithm deprecation is a governance and operational challenge as much as a technical one. The NCSC’s 2035 milestone requires that classical-only algorithm support be retired across all systems. In practice, deprecation schedules must be communicated to application teams, vendors, and partners well in advance — typically 12–24 months of notice for internal systems, and longer for supply chain dependencies.

PKI governance processes should be updated to reflect the deprecation schedule: new certificate requests should require PQC algorithm support from the 2028 milestone onwards; classical-only certificate issuance should be formally prohibited by policy from 2031. Certificate automation platforms (ACME protocol implementations, for example) should be configured to issue post-quantum or hybrid certificates by default.

Your security team should maintain a live CBOM — not a point-in-time snapshot — that is updated as new systems are deployed and old ones are decommissioned. Without ongoing CBOM maintenance, the deprecation phase risks leaving classical-only stragglers that are only discovered during a compliance audit.

Maintaining Cryptographic Agility for Future Algorithm Updates

Cryptographic agility — the architectural property that allows algorithms to be replaced without fundamental redesign of the systems they protect — is the key investment that distinguishes organisations that will handle the 2035 milestone gracefully from those that will face another emergency migration programme.

Cryptographic agility means: abstracting cryptographic operations behind configurable interfaces rather than hard-coding algorithm choices; centralising key and certificate management so that rotation can be orchestrated rather than manual; and ensuring that PKI and key management infrastructure supports multi-algorithm operation so that future algorithm updates (NIST has indicated that additional algorithms will be standardised over time) can be adopted without infrastructure replacement.

This is not a theoretical concern. The history of cryptographic standards is one of algorithms being weakened or broken over time — MD5, SHA-1, DES, and 3DES all required forced migrations that organisations with agile cryptographic architectures handled far more smoothly than those without. Post-quantum migration is the opportunity to build agility in while the broader transformation is underway.

Ongoing Monitoring and Incident Response for Quantum-Era Threats

Post-migration monitoring should extend your existing cryptographic health monitoring to include: detection of classical-only algorithm use in network traffic (indicating a legacy system that escaped migration or a newly deployed system that bypassed controls); certificate expiry alerting for post-quantum certificates (which may have shorter recommended lifetimes as the field matures); and anomaly detection for key management operations that could indicate a compromise of your post-quantum key material.

Quantum-era incident response adds a new scenario to your security operations playbook: the discovery that a classical-encrypted archive has been exfiltrated, and the consequent need to assess the sensitivity of that data against the anticipated quantum timeline. Your incident response team should have a documented procedure for this scenario before it arises. NCSC’s 2031 milestone implicitly requires that your incident response capability has been updated to reflect the post-quantum threat model — not just your preventive controls.

UK Regulatory and Compliance Landscape in 2026

UK-specific compliance obligations for PQC migration are defined primarily by NCSC guidance, with sector-specific overlays from financial regulators, telecoms regulators, and CNI frameworks. Understanding what is mandatory versus recommended — and where the UK framework diverges from EU and US requirements — is essential for accurate compliance planning.

NCSC Guidance: What Is Mandatory vs. Recommended

The NCSC’s March 2025 guidance document (Timelines for migration to post-quantum cryptography) establishes the 2028/2031/2035 milestones as requirements for organisations in scope — broadly, operators of critical national infrastructure, central government departments, and organisations handling classified or government-sensitive data. For organisations outside formal CNI designation, the milestones represent authoritative recommended practice backed by the UK Cyber Security Strategy.

It is important to distinguish these categories carefully. A medium-sized UK manufacturer with no CNI designation faces a different compliance obligation than a licensed telecoms operator or a regulated financial institution. The NCSC’s guidance is mandatory in a regulatory sense only for certain in-scope organisations; for others, it represents the standard of care that a reasonable organisation in that sector should demonstrate.

What is mandatory for all organisations subject to UK law is compliance with any sector-specific guidance from their primary regulator — and an increasing number of UK regulators are issuing or planning to issue PQC-specific guidance aligned with the NCSC framework.

How UK Obligations Differ from EU NIS2 and US CNSS Requirements

Post-Brexit, UK organisations are not subject to EU NIS2 directly, but the NIS2-implementing regulations of EU member states may affect UK organisations providing services to EU-based clients or operating EU-incorporated subsidiaries. NIS2 requires operators of essential services to implement appropriate technical measures including cryptographic controls — in practice, this is driving PQC planning requirements through supply chains into UK organisations that supply EU essential service operators.

The US CNSS (Committee on National Security Systems) has issued requirements that are binding only on US national security systems. They are not directly applicable to UK organisations, but they represent the most prescriptive published framework and are useful as a reference for organisations seeking the most conservative applicable standard. According to Encryption Consulting’s April 2026 global deadline comparison, the US NSM-10 memorandum aligns broadly with NCSC timelines, with some agencies facing earlier internal deadlines.

BSI’s requirements for hybrid cryptography — specifically, the requirement that key exchange use both a classical and a post-quantum algorithm simultaneously — are currently more demanding than NCSC’s default position, which permits a risk-based approach to hybrid versus full replacement. UK organisations with German regulatory exposure should apply the BSI standard to any systems within that scope.

Sector-Specific Pressures: Financial Services, Telecoms, Critical National Infrastructure

Financial services. UK financial institutions are subject to FCA and PRA operational resilience requirements that implicitly require cryptographic resilience. While neither the FCA nor PRA has issued standalone PQC guidance as of mid-2026, their existing requirements for technology risk management and third-party dependency management create a framework within which PQC migration planning is clearly expected. Large UK banks with US operations also face OCC and FFIEC guidance that references the NIST PQC standards explicitly. Financial services PQC migration is further complicated by the volume of inter-institution cryptographic dependencies (SWIFT messaging, payment network HSMs, digital certificates in trading infrastructure) that require coordinated rather than unilateral migration.

Telecoms. UK telecoms operators designated under the Telecommunications Security Act 2021 face specific security requirements administered by Ofcom, with NCSC oversight. The TSA framework explicitly requires that security measures keep pace with the threat environment — a standard that the quantum threat will increasingly test. ETSI’s quantum-safe cryptography working group, which is actively shaping standards for telecoms quantum security, provides the technical baseline that UK telecoms operators should monitor for emerging mandatory requirements.

Critical national infrastructure. CNI sectors — energy, water, transport, health, and government — face the most direct NCSC mandatory requirements and the greatest complexity, owing to the prevalence of operational technology environments. The intersection of OT security and PQC migration is addressed in the pitfalls section below.

Common Pitfalls and How to Avoid Them

Most PQC migration programmes that fall behind schedule or fail to deliver their objectives do so for predictable reasons. The following pitfalls appear consistently across organisations that have begun migration programmes, and addressing them early is far less costly than encountering them mid-programme.

Treating PQC Migration as a One-Time IT Project

The single most damaging framing for a PQC migration programme is to scope it as a finite project with a defined end date after which cryptographic security can be returned to normal maintenance mode. Cryptographic migration is a continuous operational capability, not a project. NIST has explicitly indicated that additional post-quantum algorithms will be standardised over time — HQC was selected as a backup KEM in 2024 and will be standardised — and the history of cryptography strongly suggests that algorithm lifetimes will require active management indefinitely.

Migration debt accumulates when organisations treat PQC as a one-time effort: new systems are deployed without quantum-resistant cryptography because the project has ended, cryptographic agility investments are not made because the project budget is exhausted, and the CBOM is not maintained because there is no ongoing programme to own it. By 2031, these organisations face a second migration effort at least as large as the first.

The correct framing is: PQC migration is the catalyst for building a permanent cryptographic risk management function, with ongoing CBOM maintenance, algorithm deprecation governance, and vendor readiness monitoring as standing activities.

Underestimating Certificate and Key Management at Scale

Certificate sprawl is one of the most commonly underestimated obstacles in PQC migration. Organisations that lack a current, accurate certificate inventory — and most do — will find the migration effort substantially larger than initial scoping suggested. A global enterprise may hold tens or hundreds of thousands of certificates across public and private PKI hierarchies, including certificates issued by internal CAs, third-party CAs, and cloud provider certificate services.

Key lifecycle management at scale requires investment in automation that many organisations have deferred. Manual certificate management, even with spreadsheet-based tracking, cannot reliably handle the rotation of a large post-quantum certificate estate while maintaining operational continuity. Your security team should treat certificate automation as a prerequisite investment — not an optional efficiency improvement — before attempting large-scale PQC certificate rollout.

Project scope creep is particularly likely in this area: what begins as a TLS certificate migration frequently surfaces previously unknown internal CA hierarchies, legacy protocol usage (TLS 1.0/1.1, SSLv3 in some older systems), and non-standard certificate issuance processes in business units that have not been coordinating with the central security function.

Neglecting Operational Technology (OT) and IoT Environments

OT security and IoT cryptographic constraints represent the most technically challenging aspect of PQC migration, and they are consistently under-addressed in migration planning. The reasons are structural: OT devices in energy, utilities