Planning the transition to post-quantum cryptography

Most organisations already know, in general terms, that post-quantum cryptography (PQC) is coming. Far fewer have translated that into a plan with dates, owners, and a starting point. That gap is where risk actually sits: not in the algorithms themselves, but in treating PQC as something to figure out later, when the systems involved take years to change and the deadlines are no longer far off.

The previous blog looks at why PKI is the hardest dependency in the move to PQC. Certificates, trust anchors, and validation logic are embedded everywhere, and none of them can be replaced in one step. That conclusion applies more broadly. PQC migration is not product deployment. It is a multi-year programme that must be planned, sequenced, and resourced like one.

This blog looks at what that programme actually involves: why the timelines run into the next decade, what an inventory needs to cover, how testing and staged rollout fit together, and why starting early is the only way to keep the transition manageable.

Why migration takes years, not months

Cryptography is rarely visible as a standalone system. It is embedded in TLS libraries, VPN clients, firmware, HSMs, identity platforms, code-signing pipelines, and applications that were built and deployed years ago, often by teams and vendors no longer directly involved. Changing the algorithms underneath means touching all of it, without breaking what currently works.

That is compounded by three structural constraints:

• Certificate lifetimes: Certificates issued today can remain valid for one to several years, and replacing them ahead of schedule across an entire estate is itself a project.
• Vendor and platform dependency: Many organisations cannot upgrade their own cryptography faster than the libraries, appliances, and cloud services they depend on. PQC support has to arrive in the stack before it can be turned on.
• Long-lived and embedded systems: Industrial control systems, medical devices, and other embedded platforms often stay in service for a decade or more, with limited ability to be patched at all.

None of this is unusual for a cryptographic transition. It mirrors earlier moves, such as SHA-1 to SHA-256. What is different is scale: PQC affects almost every system that relies on public-key cryptography, not a single algorithm family in a specific protocol.

The timelines organisations are planning against

Governments and standard bodies have converted this urgency into concrete dates, and those dates are shaping enterprise roadmaps even outside the public sector.

In the United States, NIST's draft IR 8547 sets out a transition schedule for traditional public-key algorithms: 112-bit security levels, including RSA-2048 and ECDSA P-256, are proposed for deprecation after 2030 and disallowed after 2035. The NSA's Commercial National Security Algorithm Suite 2.0 (CNSA 2.0) applies a more aggressive schedule to National Security Systems, requiring CNSA 2.0 compliance for new acquisitions from 2027 and targeting most transitions by 2033.

Europe has moved in step. In June 2025, the NIS Cooperation Group published a Coordinated Implementation Roadmap for the Transition to Post-Quantum Cryptography on behalf of EU Member States. It asks Member States to have national PQC transition strategies in place by the end of 2026, and to migrate high-risk use cases, meaning critical infrastructure and systems processing long-lived sensitive data, by the end of 2030.

The dates differ slightly by jurisdiction and system type, but the pattern is consistent: inventory and planning now, high-risk systems by 2030, broad completion by the mid-2030s. For organisations without a regulatory deadline, these timelines are still useful as a planning reference, since vendors, CAs, and platform providers are building their own roadmaps around them.

Start with an inventory, not an algorithm

The most common mistake in early PQC planning is jumping straight to algorithm selection. Before AML-KEM or ML-DSA can be deployed anywhere, an organisation needs to know where RSA, ECDSA, and Diffie-Hellman are actually used. That is harder than it sounds. Cryptography shows up in:

• TLS termination points, load balancers, and API gateways
• VPN and remote access infrastructure
• Certificates: public-facing, internal PKI, device identity, code signing
• Key management systems and HSMs
• Applications and libraries with hardcoded or indirect cryptographic dependencies
• Firmware and embedded devices

A useful reference point here is the Cryptographic Bill of Materials (CBOM), a structured way to catalogue algorithms, key types, and certificates across an environment, similar in spirit to a software bill of materials. Without this inventory, an organisation cannot measure progress, prioritise what to migrate first, or demonstrate compliance against any of the timelines above.

Inventory work does not need to wait for the rest of the programme. It can and should start in parallel with early testing and vendor engagement, since it typically takes longer than expected to complete across a large estate.

Testing before deployment

Once an inventory exists, the next step is validating PQC algorithms in controlled environments before they touch production traffic or issued certificates. This stage typically covers:

• Interoperability testing: confirming that hybrid key exchange and hybrid certificates behave correctly across the libraries, browsers, and intermediaries an organisation actually uses.
• Performance testing: PQC algorithms change message sizes and CPU profiles. Larger handshakes and keys can affect network behaviour, especially through firewalls, TLS inspection, and legacy proxies that make assumptions about packet sizes.
• Failure mode testing: understanding what happens when a client or intermediary does not support the new algorithms, and whether negotiation falls back safely or breaks the connection.

This is also where hybrid approaches earn their place. Combining a classical algorithm with a post-quantum one in the same handshake or certificate protects against the risk that either individual algorithm turns out to have a weakness, while keeping compatibility with systems that are not PQC-aware yet.

Throughout this sequence, cryptographic agility matters as much as the algorithms themselves. Systems that can swap algorithms through configuration, rather than requiring code changes or hardware replacement, will move through future transitions far more easily than this one.

What organisations should be doing now

Regardless of sector or regulatory exposure, the practical starting point is the same:

• Build and maintain a cryptographic inventory, and treat it as a living asset rather than a one-time exercise.
• Engage vendors and CAs on their PQC roadmaps, since most organisations cannot move faster than their supply chain.
• Identify data with long confidentiality requirements and prioritise it independently of general system complexity.
• Pilot hybrid TLS and hybrid certificates in a controlled environment before committing to a production rollout.
• Track the applicable timelines, whether that is NIST IR 8547, CNSA 2.0, the EU roadmap, or sector-specific guidance, and use them to anchor internal milestones.

None of this requires waiting for a finished set of standards or a fully quantum-safe ecosystem. The organisations furthest along treat PQC migration the way they treat any other infrastructure lifecycle: planned, phased, and running in parallel with normal operations, not as a separate emergency programme.

Do you want to start on your transition to post-quantum cryptography? Get in touch with one of our PQC experts.