Quantum-Safe Migration: A Step-by-Step PQC Roadmap

Most organisations protect their systems with RSA and elliptic-curve cryptography. A sufficiently capable quantum computer running Shor's algorithm will break both. Quantum-safe migration is the programme of replacing those algorithms before that machine exists, without taking down the systems that depend on them.

It is a multi-year effort. It starts with visibility, proceeds through risk-based prioritisation, and ends not at a finish line but at a crypto-agile state that can absorb the next algorithm change with minimal disruption.

What Is Quantum-Safe Migration?

Quantum-safe migration is the structured process of moving an organisation's cryptographic estate from quantum-vulnerable algorithms such as RSA and elliptic-curve cryptography to quantum-resistant ones: ML-KEM for key exchange, ML-DSA or SLH-DSA for digital signatures. Symmetric algorithms such as AES-256 are not broken by known quantum attacks and generally stay.

The programme covers every place the vulnerable algorithms appear: certificates, TLS sessions, VPN tunnels, code signing, HSMs, PKI hierarchies, and application-level key exchange.

Why Migrate Now: The Quantum Threat and Deadlines

Harvest Now, Decrypt Later and Cryptographic Debt

The threat is not only from future quantum computers. In a harvest now, decrypt later attack, adversaries collect encrypted data today and store it to decrypt once the capability exists. For data that must stay confidential for a decade or more, the window of exposure is already open.

Mosca's inequality formalises this. If the time your data must remain confidential (x) plus the time to complete migration (y) exceeds the time until a CRQC exists (z), the organisation has a problem today. Most large organisations, with migration timelines of three to five years, fail this test for long-lived data.

Cryptographic debt compounds the problem. Organisations that have accumulated hard-coded algorithms, long-lived certificates and undocumented cryptographic dependencies will take longer to migrate than those that have kept their estates visible and documented.

Compliance Drivers and Timelines

Regulators are putting dates on the problem. NIST's draft IR 8547 proposes deprecating RSA and elliptic-curve algorithms at the 112-bit security level after 2030 and disallowing them after 2035. The US CNSA 2.0 suite requires quantum-resistant algorithms for national security systems, with NSM-10 targeting a fully quantum-resistant federal estate by 2035.

India's Department of Science and Technology has set 2029 for Critical Information Infrastructure and 2033 for broader enterprise adoption in its Quantum Safe Ecosystem in India report. The UK NCSC expects full migration by 2035. For an organisation with a three-year migration programme that has not started, 2029 is already close.

The Quantum-Safe Migration Roadmap: Key Phases

Phase 1: Build a Cryptographic Inventory

A Cryptographic Bill of Materials (CBOM) is the prerequisite for every step that follows. It maps every algorithm, key, certificate and protocol across the estate. Without it, migration is guesswork: you cannot prioritise what you cannot see, and regulators including the RBI's Q-SAFE committee are already requiring cryptographic inventories as the starting point for sector roadmaps.

The CBOM should cover endpoints, cloud services, on-premises applications, APIs, third-party integrations and devices. Scanning tools and QShield 2.0 automate discovery; manual review covers the gaps that automated tools miss, including hard-coded keys in application code and cryptography embedded in firmware.

Phase 2: Assess Risk and Prioritise

Once the inventory exists, apply Mosca's inequality to each class of data and system. Systems protecting long-lived sensitive data and those that are hardest to update should be migrated first. The assessment should produce a prioritised list of cryptographic assets ranked by exposure window and migration difficulty.

Systems that cannot be updated quickly, such as embedded devices, legacy applications and hardware-rooted trust anchors, need to be identified now so that replacements can be planned on their procurement cycles.

Phase 3: Deploy Hybrid and PQC Algorithms

Hybrid deployment combines a classical algorithm with a post-quantum one in the same key exchange. A session or certificate is secure even if one algorithm has an unexpected weakness, and the link stays compatible with systems that do not yet support PQC. Hybrid is the recommended transitional path before moving to post-quantum algorithms alone.

Target algorithms are ML-KEM (FIPS 203) for key exchange and ML-DSA (FIPS 204) or SLH-DSA (FIPS 205) for signatures. They run in software on existing hardware for most use cases. Hardware accelerators may be required for high-throughput or low-latency environments.

Phase 4: Test, Validate and Monitor

Pilot PQC and hybrid configurations in non-production environments before rollout. Test for performance impact, interoperability with vendor libraries and protocol compatibility across the estate. Once deployed, continuous monitoring tracks the estate against target algorithms, catches regressions and alerts when new assets appear with vulnerable configurations.

HQC was selected by NIST in March 2025 as a fifth algorithm for key encapsulation, with a draft standard expected in 2026, providing an additional code-based option once finalised.

Crypto-Agility: The End Goal

Migration to PQC is not the last algorithm change an organisation will make. Standards evolve, new attacks emerge, and regulatory requirements will update. The goal is a crypto-agile estate: one where algorithms can be changed again with minimal disruption because key management is centralised, cryptographic dependencies are documented, and the Quantum Key Management System handles the operational logic that previously sat in individual applications.

Defence-in-Depth: PQC, QKD, and Key Management

PQC secures the software estate. QKD secures the highest-value backbone links with security rooted in physics rather than computational assumptions. The Quantum Key Management System governs keys across both layers, with QRNG entropy as the root of trust. Together they provide defence-in-depth: if one layer has a weakness, the other still holds.

Building a Migration Strategy: Scope, Timeline, Budget

Three inputs determine the programme's shape. Scope comes from the CBOM: which systems are in scope and which can be excluded for now. Timeline is set by the combination of regulatory deadlines and Mosca's inequality applied to your most sensitive data. Budget follows from both: systems that must be migrated earliest and are hardest to change will drive the cost profile.

For most organisations, a quantum readiness assessment produces a scoped programme plan with a phased roadmap that fits procurement cycles and regulatory timelines. That assessment starts with the CBOM and ends with a sequenced list of migration projects ranked by urgency.