The CISO's guide to migrating to post-quantum cryptography by 2030

The NCSC's Post Quantum Cryptography (PQC) migration timeline gives UK organizations three reference dates:

1. By 2028: Identify cryptographic services that need upgrading and build a migration plan
2. By 2031: Complete high-priority migration work
3. By 2035: Stick a fork in it… It needs to be done.

Ten years sounds generous… but it isn't. For example, for data that needs to remain confidential beyond 2035, the deadline has effectively already passed.

As with all major IT and security projects, PQC migration is likely to take longer, involve more challenges, and uncover more technical debt than most stakeholders expect. In this article, we’ll explain what PQC is all about and how to approach your migration.

What is post-quantum cryptography?

Most of the encryption currently protecting the world's data relies on one premise: certain mathematical problems are so hard to solve that even supercomputers can’t crack them by brute force alone on this side of the heat death of the universe.

(Actually, that “fact” is a bit misleading, but it makes the point well enough. Brute forcing strong asymmetric encryption is functionally not a thing. Or at least, it wasn’t.)

That mathematical difficulty is the foundation on which RSA, elliptic-curve cryptography, and much of the internet's security infrastructure is built.

However, quantum computers change the premise. They process certain classes of problems in fundamentally different ways. An algorithm called Shor's algorithm, running on a sufficiently powerful quantum computer, could solve the maths underpinning RSA and elliptic-curve encryption in hours or minutes rather than millennia. Naturally, that would render the encryption protecting network communications, authentication systems, and sensitive data… insufficient.

Post-quantum cryptography (PQC) is about implementing encryption technologies that remain secure even against Cryptographically Relevant Quantum Computers (CRQCs). This can be done in several ways:

1. Post-Quantum Algorithms (PQAs). These are new public-key encryption standards that are resistant to quantum attacks.
2. Quantum Key Distribution (QKD). This is a hardware-based method that uses the laws of quantum physics to securely share encryption keys between parties.
3. Symmetric Key Agreement (SKA). This is a cryptographic process in which two or more parties establish a shared key that should be frequently rotated.

In August 2024, after nearly a decade of evaluation, NIST finalized the first three post-quantum standards: ML-KEM for key encapsulation, ML-DSA for digital signatures, and SLH-DSA as an additional signature scheme. A fourth standard, HQC, followed in early 2025.

Migrating to an appropriate PQC solution (or combination of solutions) has become rather urgent, for two reasons:

1. Harvest Now, Decrypt Later (HNDL). Bad actors are already collecting encrypted data and storing it in preparation for when quantum capabilities make decryption feasible. Consequently, data that needs to remain confidential for a long period is already at risk.
2. CRQCs are on the way. There is no exact timeline for CRQCs to become available, but estimates begin at around 2030. Given how long it takes to complete major projects like PQC migration, regulators and organizations in critical industries are wasting no time.

2035 is closer than it looks

Enterprise cryptographic migrations have a poor track record. The shift from TLS 1.0 to TLS 1.2 took many large organizations the better part of a decade, and that was a comparatively simple upgrade with broad vendor support.

Post-quantum migration is harder. It touches more systems, the standards are still evolving, and frankly, IT environments are just way more complicated than they used to be. As a consequence, it’s reasonable to expect PQC migration to happen over years, and there’s little (if any) time to waste.

And that’s for regular organization. Any sensitive data being transmitted today with quantum-vulnerable cryptography is already, in effect, exposed. Adversaries don't need a CRQC to start stockpiling stolen data for HNDL attacks. So if your organization is in an industry where data must remain private for a long time, you don’t have until 2035.

For context, Google's Willow chip, China's Zuchongzhi-3, and IBM's error-correction work have all suggested that the operational timeline for CRQCs may be shorter than the "decade or more" assumption many migration plans are based on.

A five-stage framework for PQC migration

All that being said, what should a PQC migration roadmap look like? Obviously, timescales and effort will vary, but there are five key stages that every organization will need to cover:

Stage 1: Discover. You can’t migrate without knowing your starting point. A cryptographic inventory across all of your applications and infrastructure is the foundation of any migration plan. Most organizations significantly underestimate the scope. Cryptographic dependencies tend to sit in places nobody documented, such as embedded in firmware, libraries, and vendor products acquired through M&A.

Stage 2: Assess and prioritize. Risk-rank cryptographic exposure by data sensitivity, longevity, and attack surface. Anything carrying data with confidentiality requirements that extend beyond 2035 belongs in the first wave, for example, intellectual property, regulated personal data, classified communications, and financial infrastructure.

Stage 3: Design for crypto-agility. We’ll discuss this more in a moment, but PQC won’t be a case of “set and forget”. At this point, nobody knows which PQC standards will last and which will need to be rethought. As a consequence, the ability to readily switch standards when necessary will be essential. Abstracting cryptographic operations behind interfaces and avoiding hard-coded algorithms means a bit more effort now, but far less hassle down the road.

Stage 4: Pilot and validate. Start with high-value, low-disruption links and closely monitor performance impact. Depending on your preferred route to PQC, you may have to accept some performance degradation. However, it’s worth noting that joint testing by Arqit, Intel, and Equus Compute Solutions of an extremely secure nested tunnel architecture designed to provide quantum-safe encryption for military applications showed throughput penalties under ten percent without specialized tuning. The single-tunnel implementation saw only a 3.5% decrease relative to the unencrypted baseline.

Stage 5: Scale and govern. Think of migration as an ongoing program rather than a one-off project. Ultimately, PQC will become the norm, but in the short term, it should be monitored closely. Continuous monitoring catches new systems and new third-party dependencies before they become exceptions.

“Set and forget” is a losing strategy

Notice that even NIST added HQC as a backup in March 2025. This is because no new standard has decades of cryptanalysis behind it as AES does.

The joint position of UK, EU, and US security agencies (as well as the German BSI, French ANSSI, and others) is that a hybrid approach is best. Backing several horses and laying the groundwork for them should ensure that you can adapt to any bumps along the road.

In short, crypto-agility will be essential, so you might as well build it in from the start.

Take the first step

Again, visibility is the starting point.

You must know your starting point: what cryptography is running across your network today, which standards are in use, and where you’re most likely to be exposed.

It’s a truism in cybersecurity that you should take “a risk-based approach.” But as usual, it’s also a fact.

Encryption Intelligence gives organizations complete visibility into their use of cryptography. It identifies vulnerabilities, measures risk, and provides clear guidance to reduce exposure, helping to prioritize migration activities.

To find out how Encryption Intelligence can support your PQC migration roadmap, visit our website.