How to Build a Post-Quantum Cryptography Migration Roadmap: A 12-Step Playbook

Post-quantum cryptography (PQC) migration is the process of replacing the public-key algorithms that secure today's systems, mainly RSA and elliptic-curve cryptography, with quantum-resistant standards before a quantum computer can break them. It reaches into nearly every system that authenticates a user, sets up a secure connection, or signs software and firmware.

The difficulty is not the algorithm swap. It is the scale of the estate, the coordination across teams and vendors, and the sequencing. The destination is already fixed: the first post-quantum standards are published, and national and sector migration timelines are set. The remaining work is inventory, planning, and execution.

This article explains what quantum computing does and does not threaten, which standards replace which algorithms, what has to change in practice, and a 12-step framework for reaching a costed, board-ready roadmap. The complete PQC Migration Playbook, with checklists and templates for every step, is linked at the end.

Key takeaways

• Quantum computers threaten public-key cryptography (RSA, ECC). Symmetric encryption such as AES-256 stays strong.
• The finalized replacements are ML-KEM for key establishment and ML-DSA for signatures, with SLH-DSA as a backup.
• Migration runs in hybrid mode, pairing a classical algorithm with a post-quantum one, before moving to full PQC.
• You cannot migrate what you have not mapped, so a cryptographic inventory (CBOM) comes first.
• Prioritize by data lifetime, system criticality, and exposure, then migrate in waves over a multi-year program.
• Build for crypto-agility so the next algorithm change is a configuration update, not a rebuild.

What is post-quantum cryptography migration?

PQC migration is the coordinated replacement of quantum-vulnerable public-key cryptography with quantum-resistant algorithms across an organization's entire estate. In practice it moves key establishment and digital signatures off RSA and elliptic-curve cryptography and onto the new standards, while keeping the parts of your cryptography that remain strong.

What changes and what stays:

• Being replaced: RSA, elliptic-curve cryptography (ECDSA, ECDH), Diffie-Hellman key exchange, and the classical digital signatures built on them.
• Continuing: symmetric encryption such as AES-256, and hash functions such as SHA-2 and SHA-3, used at appropriate sizes.

This is a targeted transition, not a rebuild of your security architecture. The work concentrates on the layer that establishes trust, exchanges keys, and authenticates identity.

Why quantum computers break some cryptography but not all

Modern systems use two kinds of cryptography for two different jobs. Symmetric cryptography, such as AES, uses one shared key to encrypt and decrypt, and it protects the bulk of stored and transmitted data. Public-key cryptography, such as RSA and elliptic-curve cryptography, uses a linked key pair to establish trust between parties that have never shared a secret, exchange keys, and sign data. Quantum computing affects these two families very differently.

Shor's algorithm, run on a large fault-tolerant quantum computer, efficiently solves the integer factorization and discrete logarithm problems. Those problems are the entire basis of RSA, Diffie-Hellman, and elliptic-curve cryptography, so a capable quantum computer would remove their security rather than weaken it.

Grover's algorithm attacks symmetric cryptography differently. It speeds up brute-force key search, but only quadratically, which is far weaker than Shor's exponential advantage. In effect it roughly halves the security level of a symmetric key: AES-128 falls to about 64-bit effective security, while AES-256 retains about 128-bit effective security, which is still strong. Hash functions such as SHA-256 and SHA-3 are affected in a comparable, manageable way at adequate output sizes.

The consequence is specific. Symmetric encryption and hashing largely hold. The exposed layer is public-key cryptography, and that is what migration targets. When people say quantum will "break encryption," what actually becomes vulnerable is the trust and key-exchange layer that sets up secure communication, not the cipher protecting the data.

The standards you migrate to

Migration moves the exposed public-key functions onto standardized quantum-resistant algorithms. Three are finalized:

• ML-KEM (FIPS 203) is a module-lattice key-encapsulation mechanism derived from CRYSTALS-Kyber. It is the primary replacement for RSA key transport and for Diffie-Hellman and elliptic-curve key exchange.
• ML-DSA (FIPS 204) is a module-lattice signature scheme derived from CRYSTALS-Dilithium. It is the primary replacement for RSA and ECDSA digital signatures.
• SLH-DSA (FIPS 205) is a stateless hash-based signature scheme derived from SPHINCS+. Its security rests only on hash functions, which makes it a conservative backup for cases where larger signatures and slower signing are acceptable.

ML-KEM and ML-DSA are both lattice-based. To guard against a future weakness in lattice mathematics, a code-based key-encapsulation algorithm, HQC, has been selected as a backup with its standard in development, and a further compact lattice signature standard, FN-DSA (derived from Falcon), is in progress. On the symmetric side, AES-256, SHA-2, and SHA-3 carry over into the post-quantum era.

Why start PQC migration now?

A quantum computer capable of breaking today's public-key cryptography does not exist yet, and the arrival date is uncertain. That is the reason the arrival date is the wrong thing to plan around. Three practical points make the case for starting now.

The first is long-lived data. Financial contracts, medical records, intellectual property, and government archives have to stay confidential for years or decades. That data is protected today by key exchange that needs to hold for the full life of the information. If it cannot be trusted for that period, the protection already falls short of what the data requires.

The second is long refresh cycles. Hardware, firmware, and infrastructure bought now often stay in service for a decade or more. Anything with a long service life is worth specifying as quantum-ready at purchase, because building it in costs a fraction of retrofitting it later.

The third is the length of the migration itself. Replacing public-key cryptography across a real organization is a multi-year program. When that duration is set against the migration deadlines governments and standards bodies have already published for the end of this decade, organizations that begin planning now are working inside the lead time the task requires.

Migration runs in hybrid mode, not a single switch

For most systems the transition is not a clean cutover from old to new. During migration, systems run classical and post-quantum algorithms together. A hybrid key exchange combines a classical method with ML-KEM so the connection stays secure unless both are broken, which protects against today's threats and against any early weakness found in a new algorithm. This dual-stack approach is already in production: major browsers and services negotiate hybrid TLS handshakes that pair ML-KEM with an established elliptic-curve exchange such as X25519.

Planning for hybrid operation is part of the work. Systems, certificates, and protocols need to support two algorithms in parallel and fall back cleanly, and your cryptographic policy should define when a system moves from hybrid to full post-quantum operation.

What has to change, and why cryptographic discovery comes first

Cryptography is not confined to one system, which is why migration is a program rather than a patch. Most environments have been built over decades and contain undocumented certificates, embedded libraries, and third-party dependencies that no single team can see in full. Before anything can be planned, you have to know where cryptography lives. The public-key layer appears across:

• PKI and certificates: certificate authorities, machine identities, and the full certificate lifecycle, including hybrid certificate profiles.
• Secure channels: TLS, VPN, SSH, and IPsec endpoints that negotiate keys on every connection.
• Signing systems: code signing, firmware signing, and document signing, where a forged signature undermines trust.
• Key management: HSMs and key management systems that generate, store, and rotate keys, some of which need firmware or product updates to support new algorithms.
• Embedded, OT, and IoT: devices with fixed, sometimes non-upgradeable cryptographic libraries and long service lives, often the hardest and slowest to migrate.
• Third parties and supply chain: vendor products, cloud services, and partner integrations whose readiness sets part of your timeline.

Each of these belongs in a Cryptographic Bill of Materials (CBOM), an inventory that records the algorithm, key length, protocol, certificate profile, owner, update path, and dependencies for every cryptographic asset. Without it you cannot assess exposure, prioritize, estimate effort, or build a credible roadmap.

The PQC migration framework: 12 steps across five phases

The playbook organizes the work into twelve steps grouped into five phases: Foundation, Discover, Plan and Validate, Build, and Sustain. Each step produces a defined output that feeds the next, so the program builds on itself.

The twelve steps at a glance, grouped into five operational phases.

The full sequence:

• Establish PQC governance and a Centre of Excellence. Set leadership, roles, and decision-making so the program is coordinated rather than fragmented.
• Develop a cryptographic policy. Define approved algorithms, hybrid approaches, key management rules, protocol baselines, and crypto-agility expectations.
• Inventory cryptographic assets (CBOM). Build the inventory across every environment, including cloud, OT, IoT, and third-party services.
• Conduct a quantum risk assessment. Map inventory to business impact, data sensitivity, and exposure to find where risk actually sits.
• Prioritize systems and data for transition. Turn the risk view into tiers so the most critical, sensitive, and exposed systems move first.
• Conduct architectural reviews and complexity analysis. Establish how difficult each migration will be, and flag systems needing early or specialized work.
• Test PQC algorithms and migration patterns in a sandbox. Validate performance, hybrid modes, and compatibility before touching production.
• Develop the PQC migration plan. Sequence the work, define transitional measures, and set system-level actions and dependencies.
• Implement crypto-agility and future-proofing. Design systems so algorithms can change through configuration rather than redesign.
• Engage stakeholders, vendors, and supply chain partners. Align internal teams and external suppliers whose readiness affects your timeline.
• Plan contingencies and fallback strategies. Define triggers and responses for accelerated timelines, vendor slips, or newly discovered weaknesses.
• Continuously review, evaluate, and update. Keep the inventory, risk view, and roadmap current as standards, vendors, and threats evolve.

Phase 1: Foundation (steps 0 to 1)

Migration touches identity, networks, cloud, applications, OT, and firmware, so no single team can own it. Foundation work puts governance, executive sponsorship, and a clear cryptographic policy in place before technical work begins. This prevents teams from buying incompatible products or making conflicting cryptographic decisions later.

Phase 2: Discover (steps 2 to 5)

Discovery grounds the program in reality. You build the CBOM, assess quantum risk against real business impact, and prioritize. A practical way to prioritize is to plot each system by business impact and exposure, then act on the highest-risk quadrant first.

Prioritize by business impact and exposure. Mission-critical systems with long-lived data and external exposure move to the front of the roadmap.

Phase 3: Plan and Validate (steps 6 to 7)

Here you review each prioritized system for architectural constraints, such as hard-coded algorithms, protocol limits, and performance sensitivities, then validate your choices in a sandbox before committing. The output is a sequenced, multi-year plan in which foundational trust services migrate early, because much else depends on them.

A phased timeline. Foundation work runs first, tiered migrations follow in waves, and continuous programs run throughout.

Phase 4: Build (steps 8 to 9)

Building is where migration and crypto-agility come together. The goal is not only to swap RSA for ML-KEM once. It is to design systems so the choice of algorithm is a policy setting rather than an assumption baked into application code, which makes the next change routine. In practice this means abstraction layers, configuration-driven algorithm selection, and updateable cryptographic libraries.

Crypto-agility in layers. Applications never call cryptographic primitives directly, so algorithms can be changed through configuration.

Phase 5: Sustain (steps 10 to 11)

Standards mature, vendors ship, and threats shift, so the work does not end at go-live. Contingency planning defines what to do if a timeline accelerates or an algorithm weakens, and a continuous review cycle keeps the inventory, risk view, and roadmap current. Together they turn a one-time project into a lasting capability.

The continuous review cycle keeps the CBOM, risk view, and roadmap current as standards, vendors, and threats evolve.

Four misconceptions that slow PQC migration down

• "We'll act once quantum computers exist." By then the migration runway is gone. The work takes years, and long-lived data is already exposed to a future it cannot yet defend against.
• "Our symmetric encryption is safe, so this doesn't affect us." AES-256 does remain strong. But the public-key cryptography that authenticates parties and exchanges those keys does not, so the system as a whole is still exposed.
• "Our cloud provider will handle it." Providers will migrate their own layers, but your certificates, applications, identity systems, and third-party integrations remain your responsibility.
• "PQC is only for national security organizations." Any organization holding data that must stay confidential for years, or running infrastructure with long refresh cycles, has a stake in this.

Where to start

Start with discovery. An accurate, continuously updated cryptographic inventory is the foundation for everything that follows, and it earns its keep before any quantum threat arrives through better certificate management and continuous audit readiness. Once you can see where cryptography lives, prioritization, planning, and sequencing become tractable rather than guesswork.

Get the complete PQC Migration Playbook

This article summarizes a framework covered in full in The PQC Migration Playbook, a step-by-step handbook with governance templates, a CBOM field guide, a quantum risk matrix, prioritization tiers, a sample migration timeline, a trigger-and-response register, and summary checklists for all twelve steps.

Download the PQC Migration Playbook and start building your roadmap.

Frequently asked questions

What is post-quantum cryptography migration?

It is the coordinated replacement of quantum-vulnerable public-key cryptography, such as RSA and elliptic-curve cryptography, with quantum-resistant standards like ML-KEM and ML-DSA across an organization's systems, while keeping strong symmetric algorithms in place.

What is the difference between symmetric and public-key cryptography?

Symmetric cryptography uses one shared key to encrypt and decrypt data, and handles bulk encryption. Public-key cryptography uses a linked key pair to establish trust, exchange keys, and sign data. Quantum computing threatens the public-key family, while symmetric algorithms such as AES-256 remain strong.

What replaces RSA and ECC?

ML-KEM (FIPS 203) replaces RSA key transport and Diffie-Hellman and elliptic-curve key exchange. ML-DSA (FIPS 204) replaces RSA and ECDSA digital signatures. SLH-DSA (FIPS 205) is a hash-based backup signature scheme.

What are ML-KEM, ML-DSA, and SLH-DSA?

They are the finalized post-quantum standards. ML-KEM handles key establishment. ML-DSA is the primary digital signature scheme. SLH-DSA is a conservative, hash-based signature backup. ML-KEM and ML-DSA are lattice-based; SLH-DSA relies only on hash functions.

What is the difference between ML-DSA and SLH-DSA?

Both produce digital signatures. ML-DSA is lattice-based, compact, and fast, and is the primary choice for most uses. SLH-DSA is hash-based with larger, slower signatures, used where a more conservative security assumption is preferred.

Is AES quantum-safe?

AES-256 remains strong. Grover's algorithm roughly halves the effective security of a symmetric key, so AES-256 keeps about 128-bit effective security, which is why it continues to be recommended. The migration targets public-key cryptography, not AES.

Is post-quantum cryptography the same as quantum cryptography or QKD?

No. Post-quantum cryptography uses new mathematical algorithms that run on today's computers and resist quantum attack. Quantum cryptography, such as quantum key distribution (QKD), uses quantum physics and specialized hardware. PQC is the practical, software-based path most organizations are taking.

What is hybrid or dual-stack PQC?

Hybrid mode runs a classical algorithm and a post-quantum algorithm together, so a connection stays secure unless both are broken. It is the standard way to transition safely and is already used in hybrid TLS handshakes that combine ML-KEM with an elliptic-curve exchange.

Why protect data now if quantum computers can't break it yet?

Some information must stay confidential for years or decades. It is protected today by key exchange that has to hold for the full life of the data. If that protection cannot be trusted for the whole period, long-lived data is effectively at risk now, which is why it is prioritized first.

When will quantum computers be able to break RSA and ECC?

The timeline is uncertain, which is why it is the wrong thing to plan around. Because migration itself takes years and some data must stay protected for a long time, organizations plan against their own migration duration and data lifetimes rather than a predicted arrival date.

Which industries need PQC migration?

Any organization with data that must stay confidential for years, or infrastructure with long service lives, has a stake. Finance, government, healthcare, telecommunications, critical infrastructure, and defense are typically first because of data sensitivity and regulatory exposure.

Does PQC migration affect TLS and certificates?

Yes. TLS relies on public-key key exchange and certificates, both of which are affected. Migration introduces post-quantum and hybrid key exchange and, over time, hybrid and post-quantum certificate profiles across your PKI.

What is a CBOM?

A Cryptographic Bill of Materials is a complete inventory of where and how cryptography is used across an organization: algorithms, key types, certificates, protocols, dependencies, and ownership. It is the foundation for risk assessment and planning.

What is a quantum risk assessment?

It is the step that maps your cryptographic inventory to business impact, data sensitivity, system criticality, and exposure. The output ranks systems by risk so migration can start where it matters most.

What is crypto-agility?

Crypto-agility is designing systems so cryptographic algorithms can be changed quickly through configuration rather than code changes or redesign. It reduces the cost of the current migration and every future one.

How long does PQC migration take, and where should we start?

It is a multi-year program, sequenced in waves after foundational planning and pilots. Start with cryptographic discovery to build an inventory, because you cannot prioritize or plan a migration for systems you have not mapped, and discovery delivers operational value on its own.