Join Waitlist
← Back to Blog
20 min read

The UK NCSC's Three-Phase Post-Quantum Migration Roadmap: What 2028, 2031, and 2035 Actually Mean for Your Organization

Published by: QubitChain Research
URL: qubitchain.io/blog/uk-ncsc-post-quantum-cryptography-migration-timeline-2028-2031-2035
Category: Regulatory Compliance, Post-Quantum Cryptography
Reading Time: Approximately 20 minutes
Last Updated: August 2026

Introduction: The UK NCSC's Three-Phase Post-Quantum Migration Roadmap

URL: qubitchain.io/blog/uk-ncsc-post-quantum-cryptography-migration-timeline-2028-2031-2035 Published: August 2026 Author: QubitChain Research

In March 2025, the United Kingdom's National Cyber Security Centre (NCSC), which operates as part of GCHQ, published guidance that is the clearest and most actionable regulatory timeline for enterprise quantum migration issued by any national government. It did not frame migration as something to consider. It framed it as something inevitable, structuring its guidance around three firm milestone dates: 2028, 2031, and 2035. The title of the document is unambiguous: Timelines for Migration to Post-Quantum Cryptography.

NCSC Chief Technical Officer Ollie Whitehouse put it in plain language at the launch: "Migration to PQC is an ecosystem-wide activity. Migration will happen, globally. It will not be possible to avoid PQC migration."

This article explains what each milestone actually means in operational terms, how the NCSC timeline compares to the equivalent frameworks from the NSA and the European Union, what organizations in the UK and beyond need to do right now in 2026 to hit the 2028 target, and what this means specifically for blockchain and digital asset infrastructure. If you are a CISO, a CTO, a security architect, or a developer responsible for cryptographic infrastructure, this is the most important compliance deadline in your current planning horizon. Read our PQC compliance overview for a wider look at global regulations.

Why the NCSC Published This in 2025: The Timing Was Not Arbitrary

The March 2025 publication date matters. NIST had published FIPS 203, FIPS 204, and FIPS 205 in August 2024. The NSA had published CNSA 2.0 in September 2022. The NIST PQC standards existed. What was missing was an operationally specific roadmap that organizations could translate into project plans, budget requests, and vendor contracts.

The NCSC filled this gap. It is notable that the NCSC is the first major national cyber security agency to publish a target-dated migration roadmap after the NIST standards were finalized. Germany's BSI, ENISA, and CISA had all published guidance and algorithm recommendations, but none with the specificity of three labeled milestone years backed by phase descriptions.

The timing reflects two convergent developments. First, the NIST standards gave organizations a stable technical target to migrate toward. Before August 2024, any migration effort would have faced moving-goalposts uncertainty about which algorithms would be finalized. Second, the quantum hardware progress reports throughout 2024 and into 2025, particularly Google's Willow chip results demonstrating below-threshold quantum error correction in December 2024, made it difficult for any responsible national cyber security authority to continue describing the threat as distant.

Phase One: By 2028 (Discovery and Planning)

The 2028 milestone is about knowing what you have. The NCSC's first phase requirements:

Define migration goals. Organizations should articulate what "post-quantum security" means for their specific context. This is not a generic statement about wanting quantum-safe encryption. It means specific decisions: which signature schemes will replace ECDSA, which key encapsulation will replace ECDH, which hash algorithms need upgrading, and what hybrid deployment periods are acceptable.

Conduct a full cryptographic discovery. This is the hardest part of Phase One, and it is consistently underestimated. A full discovery means identifying every system, service, and data store that relies on cryptography that needs to be upgraded. This includes TLS certificates (where are your ECDSA certificates issued, when do they expire, which CAs support ML-DSA hybrid certs), SSH keys (what type are your bastion host keys, your deployment pipeline keys, your developer keys), code signing certificates, VPN tunnels, hardware security modules, encrypted databases, blockchain wallet keys, smart contract signing keys, API authentication systems, and any application that calls a cryptographic library.

The NCSC's own guidance acknowledges that for large organizations, this discovery process can itself take years. The 2028 target is not the moment to start discovery. It is the moment by which discovery should be complete.

Build an initial migration plan. Based on the discovery, organizations should produce a plan that identifies the highest-priority migration activities, maps supplier dependencies (if your PKI vendor does not support ML-KEM yet, that is a blocker you need to know about in 2026 not 2031), identifies hardware infrastructure that needs physical replacement (HSMs that do not support NIST PQC algorithms cannot be updated through software), and estimates investment requirements.

Communicate with suppliers. The NCSC specifically calls this out. An organization that has completed discovery but whose critical suppliers have not started PQC planning is in a difficult position. The 2028 target includes communicating your PQC needs to your supply chain.

What does this mean for organizations in 2026, right now? It means that if your organization has not started a cryptographic inventory, you are already behind for a 2028 target. A serious discovery process for a medium-to-large enterprise takes 12 to 24 months. Starting in mid-2026 puts you at late 2027 or early 2028 for completion, which is the deadline, not a comfortable buffer.

Phase Two: 2028 to 2031 (High Priority Migration)

The 2031 milestone is about completing the most critical migration work. What the NCSC calls "highest priority migration activities" has a specific meaning:

Systems and data with the highest sensitivity and longest confidentiality requirements come first. In practice this means: classified government communications, financial settlement infrastructure, healthcare records, critical national infrastructure control systems, and any data that needs to remain confidential for more than five to ten years and is therefore already at HNDL risk from nation-state adversaries.

Deploy hybrid cryptography at scale. The NCSC's guidance supports hybrid approaches where both classical and post-quantum algorithms are used simultaneously during the transition. A hybrid TLS handshake using both ECDH and ML-KEM provides security against both classical and quantum adversaries while the ecosystem transitions. The 2028-2031 phase is when hybrid deployment moves from pilot to production at scale.

Refine the migration plan. The NCSC explicitly acknowledges that PQC standards will continue to evolve during this period. FN-DSA (FIPS 206) is expected to be finalized in late 2026 or early 2027. HQC is in ongoing NIST standardization. Organizations should not wait for all standards to be final before migrating but should design their systems with cryptographic agility so that algorithm transitions do not require full rebuilds.

Infrastructure readiness. By 2031, organizations should have the technical infrastructure in place to support full PQC deployment. This means HSMs that support NIST PQC algorithms, certificate issuance pipelines that can issue ML-DSA hybrid certificates, application frameworks that support post-quantum libraries, and monitoring systems that can detect and flag any remaining classical-only cryptographic operations.

The 2028-2031 window is where the heaviest engineering work happens. Organizations that have completed discovery by 2028 will find Phase Two manageable. Organizations that were still doing discovery in 2030 will find Phase Two impossible within the timeline.

Phase Three: 2031 to 2035 (Complete Migration)

The 2035 milestone is the hard deadline. By 2035, NIST's own transition guidance (NIST IR 8547) and NSA CNSA 2.0 both call for complete deprecation of classical public-key cryptography across federal systems. The NCSC's 2035 target aligns with this global regulatory consensus.

Complete migration by 2035 means: no production systems using RSA or ECDSA for any security purpose. No TLS connections using classical ECDH. No code signing using classical ECDSA. No VPN tunnels using classical Diffie-Hellman. No blockchain transactions using ECDSA.

The NCSC acknowledges that a small set of more rarely used technologies may face difficulty meeting the 2035 deadline. Legacy industrial control systems, medical devices with decade-long deployment cycles, and satellite infrastructure with long replacement timelines are examples of categories where 2035 may be a target rather than a guarantee. The guidance is clear that all organizations should work toward 2035 even where specific edge-case systems may require exceptions.

How the NCSC Timeline Compares to NSA CNSA 2.0

The most common question organizations with US government relationships ask is whether the NCSC and NSA timelines are compatible. They are closely aligned but with different emphasis.

NSA CNSA 2.0 specifies: all new national security systems must use ML-KEM and ML-DSA by January 2027. Full application migration from classical public-key cryptography by 2030. Complete infrastructure migration by 2035.

NCSC specifies: discovery and planning complete by 2028. High-priority migration complete by 2031. Full migration by 2035.

The 2027 NSA deadline for new systems has no direct NCSC equivalent (the NCSC's 2028 target is for completing the planning phase, not deploying new systems). For US federal contractors and organizations with classified US government relationships, the NSA's January 2027 new-system deadline is the binding constraint. For UK organizations without those relationships, the NCSC's 2028 planning deadline is the operative target.

The 2035 full migration deadline is consistent across both frameworks.

What This Means for Blockchain and Digital Asset Infrastructure

The NCSC guidance has a specific implication for blockchain operators, digital asset custodians, and financial technology companies using blockchain infrastructure that the standard regulatory analysis misses. See how we compare to legacy chains.

Normal regulatory compliance frameworks assume that you can migrate your cryptographic infrastructure forward: replace the certificate authority, update the HSM firmware, redeploy the TLS configuration. The existing data remains encrypted and the keys remain valid through the transition.

Blockchain does not work this way.

Every transaction on Bitcoin, Ethereum, and any other public ECDSA-based blockchain is permanently and publicly recorded on-chain. The public keys associated with those transactions are already archived. No regulatory migration timeline changes the fact that if a CRQC exists after 2031, every historical transaction on those networks is at risk.

More specifically: any blockchain wallet whose public key has been exposed on-chain (which includes every address that has ever sent a transaction on Ethereum, and the large fraction of Bitcoin supply in P2PK outputs) cannot be made retroactively secure by migrating to ML-DSA in 2031. The historical data is already harvested.

This is the Harvest Now, Decrypt Later problem, deeply related to Q-Day. The NCSC guidance's 2028 discovery phase, when applied to blockchain infrastructure, should include an explicit assessment of how much of the organization's digital asset holdings sit in exposed-key addresses, and a migration plan for moving those holdings to genuinely quantum-safe infrastructure before Q-Day rather than by 2031.

For financial institutions, digital asset managers, and any regulated entity holding cryptocurrency as part of their balance sheet: the NCSC's 2028 planning milestone should include not just inventory of classical cryptographic systems but explicit assessment of blockchain holdings in quantum-vulnerable addresses.

The Cryptographic Agility Requirement Hidden in the Timeline

Reading the NCSC guidance carefully reveals a requirement that many organizations will underestimate: the instruction to "refine your plan so that you have a thorough roadmap for completing migration" by 2031 implicitly requires that your systems be architecturally capable of algorithm changes without full rebuilds.

If your PKI infrastructure requires a 12-month project to change the signature algorithm used by your certificate authority, and NIST publishes a new standard or issues a deprecation warning during the 2028-2031 period, you will not be able to respond within your migration timeline.

Cryptographic agility, the ability to swap cryptographic algorithms at the infrastructure level without requiring full system rebuilds, is a design requirement for any system that needs to satisfy the NCSC's 2035 full-migration target while also being able to respond to the cryptographic standards evolution that will occur between now and 2035.

For blockchain infrastructure specifically, cryptographic agility is not merely a software architecture requirement. It is a protocol-level governance question. A blockchain network that cannot change its signature algorithm without a contested community hard fork does not have cryptographic agility in any meaningful sense. QubitChain.io builds cryptographic agility into the protocol itself through a modular cryptographic engine and governance-controlled algorithm registry. Algorithm transitions happen through governance parameter updates, not hard forks. When new NIST standards like HQC are ready for activation, they are incorporated without network disruption. Full technical details are in the whitepaper at qubitchain.io/whitepaper.

A Practical Checklist for the 2026 to 2028 Phase

For security architects and compliance officers using the NCSC timeline as a planning framework, here is what the 2026-2028 period looks like operationally.

2026 Actions:

Start cryptographic discovery tooling deployment. Tools like Cryptosense Analyzer, PQC Scanner from Palo Alto, or open-source tools from the Open Quantum Safe project can automate discovery of classical cryptographic usage across network traffic, certificate inventories, and application code.

Assess your PKI vendor's PQC roadmap. Major certificate authorities including DigiCert, Entrust, GlobalSign, and Sectigo have published PQC timelines. Verify that your CA will support ML-DSA hybrid certificates by 2028 at the latest.

Audit hardware security module compatibility. Not all HSMs can be upgraded to support NIST PQC algorithms through firmware. Some will require hardware replacement. Identifying this now avoids discovering a multi-million-pound hardware procurement requirement in 2029.

Begin training security engineering teams on ML-DSA and ML-KEM. The implementation patterns for post-quantum algorithms differ meaningfully from RSA and ECDSA. Teams that begin learning now will be ready to implement by 2028.

2027 Actions:

Complete cryptographic discovery across all systems. Produce a prioritized migration inventory.

Begin hybrid deployment pilots in non-critical systems. TLS 1.3 with ML-KEM hybrid key exchange is deployable today with current versions of OpenSSL, BoringSSL, and nginx. Running pilots now builds operational experience before production migration.

Publish supplier requirements. Communicate PQC requirements to your critical technology suppliers and request their migration timelines.

2028 Target:

Complete discovery and planning documentation. Have a board-approved migration plan with budget, timeline, and supplier commitments. Communicate PQC needs to all critical suppliers.

Be ready for the future of digital assets and learn more. Join the waitlist to stay updated on our launch.

References

Frequently Asked Questions

See more at qubitchain.io/faq.

Q: What are the UK NCSC's post-quantum cryptography migration deadlines?

A: The UK NCSC published three milestone dates in March 2025: by 2028, organizations should complete cryptographic discovery and build an initial migration plan. By 2031, high-priority migration activities should be complete, including hybrid cryptography deployment at scale. By 2035, full migration from classical public-key cryptography should be complete across all systems. These align with the NSA CNSA 2.0 and NIST IR 8547 timelines.

Q: What does the NCSC 2028 deadline require?

A: By 2028, organizations must complete a full cryptographic discovery identifying every system that relies on cryptography needing upgrade, including TLS certificates, SSH keys, VPN tunnels, HSMs, code signing, and blockchain wallet keys. They must also define migration goals, build an initial migration plan, and communicate PQC needs to their supply chain. The NCSC notes that for large organizations, discovery alone can take years.

Q: How does the NCSC timeline compare to NSA CNSA 2.0?

A: The timelines are closely aligned but with different emphasis. NSA CNSA 2.0 requires all new national security systems to use ML-KEM and ML-DSA by January 2027, with full migration by 2035. The NCSC requires discovery and planning complete by 2028, high-priority migration by 2031, and full migration by 2035. The 2035 full-migration deadline is consistent across both frameworks.

Q: What does the NCSC 2035 deadline mean for blockchain?

A: By 2035, no production systems should use RSA or ECDSA for any security purpose, including blockchain transactions. For blockchain infrastructure, this is particularly challenging because historical on-chain data with exposed public keys cannot be made retroactively quantum-safe. The NCSC's 2028 discovery phase should include assessment of blockchain holdings in quantum-vulnerable addresses and planning for migration to quantum-safe infrastructure.

Q: What is cryptographic agility and why does the NCSC require it?

A: Cryptographic agility is the ability to swap cryptographic algorithms at the infrastructure level without requiring full system rebuilds. The NCSC guidance implicitly requires this because organizations must be able to respond to standards evolution between now and 2035. For blockchain, this means a network must be able to change its signature algorithm without a contested hard fork. QubitChain.io implements this through a modular cryptographic engine and governance-controlled algorithm registry.

UK NCSCPQC Migration2028-2031-2035