Build a PQC migration roadmap: inventory and CBOM, risk ranking with Mosca, hybrid ML-KEM first, PKI next, and the 2027-2035 deadlines.
A PQC migration roadmap is a dated plan for moving an organization's public-key cryptography (RSA, elliptic-curve and Diffie-Hellman) to the post-quantum algorithms standardized by NIST: ML-KEM for key establishment, ML-DSA and SLH-DSA for signatures. It sets the order, owners and deadlines for discovery, prioritization, hybrid deployment, PKI change and decommissioning, aligned with regulatory timelines that converge on 2030 to 2035.
The regulatory clock is already running. NIST's draft transition plan, IR 8547, proposes deprecating RSA-2048 and 256-bit elliptic-curve cryptography after 2030 and disallowing quantum-vulnerable public-key algorithms after 2035. NSA's CNSA 2.0 expects new national security systems to be compliant from 2027. And adversaries are already harvesting encrypted data today to decrypt it later.
Most security teams know a migration is coming. Few know where they actually stand. This guide shows how to build a post-quantum migration roadmap, the deadlines it has to meet, and why the first step matters more than any other.
Post-quantum cryptography (PQC) is public-key cryptography designed to resist attacks by a large quantum computer while running on today's classical hardware. NIST published the first three standards in August 2024: FIPS 203 (ML-KEM), FIPS 204 (ML-DSA) and FIPS 205 (SLH-DSA). It is different from quantum key distribution, which needs dedicated hardware.
Post-quantum migration is the work of replacing quantum-vulnerable algorithms everywhere they are used: TLS and VPN key exchange, certificates and PKI, code and document signing, key wrapping in KMS and HSMs, SSH, and the libraries and devices that implement them. Symmetric cryptography (AES) and hash functions mostly stay; AES-256 and SHA-384 or larger are considered sufficient.
The migration is long because public-key cryptography is embedded in protocols, hardware, partner integrations and long-lived devices, not in one system you can patch.
Your roadmap has to land before the deadlines that apply to you. The main ones:
| Jurisdiction | Source | Milestones |
|---|---|---|
| United States (federal) | NIST IR 8547 (initial public draft) | Quantum-vulnerable algorithms at 112-bit security deprecated after 2030; all disallowed after 2035 |
| United States (national security systems) | NSA CNSA 2.0 | New NSS acquisitions compliant from 1 January 2027; equipment that cannot support CNSA 2.0 phased out by 31 December 2030; CNSA 2.0 mandated by 31 December 2031 (CNSSP 15), ahead of the 2035 NSM-10 goal |
| United States (federal) | Executive Order 14412 (June 2026) | PQC key establishment for high-value assets and high-impact systems by 31 December 2030; PQC signatures by 31 December 2031 |
| European Union | Coordinated Implementation Roadmap (June 2025) | Member States start transitions and inventories by end of 2026; high-risk systems by end of 2030; full transition by end of 2035 |
| United Kingdom | NCSC migration timelines | Discovery and initial plan by 2028; highest-priority migration by 2031; full migration by 2035 |
| Switzerland (financial sector) | FINMA Guidance 05/2026 | Board-approved PQC roadmap by mid-2027 |
Country details are in our guides for the United States, the United Kingdom, Germany, Switzerland and the FINMA roadmap for Swiss banks.
| Phase | Goal | Main outputs | Indicative timing |
|---|---|---|---|
| 0. Governance | Make the migration a funded programme | Executive owner, budget, scope, policy that new systems must be crypto-agile | Month 0 to 3 |
| 1. Discovery | Know what cryptography you run | CBOM per application, cryptographic inventory, baseline readiness score | Month 0 to 6, then continuous |
| 2. Prioritization | Rank assets by risk | Data shelf life, system lifetime, regulatory deadline and exposure per asset | Month 3 to 9 |
| 3. Key establishment | Stop "harvest now, decrypt later" | Hybrid ML-KEM on TLS, VPN and key wrapping; vendor commitments | Month 6 to 18 |
| 4. Signatures and PKI | Move trust anchors and certificates | ML-DSA or SLH-DSA CAs, hybrid certificates where needed, code-signing migration | Month 12 to 36 |
| 5. Decommission and agility | Remove classical-only algorithms and keep the ability to change | Policy-driven algorithms, continuous monitoring, retirement of RSA and ECC keys | Ongoing |
The timings are indicative. A bank with a 2027 regulatory milestone compresses phases 0 to 2; a manufacturer with devices that stay in the field for 15 years starts phase 4 for those devices first.
The last major cryptographic transition (RSA to ECC) took the industry over a decade and many organisations never completed it. PQC migration is more complex: larger key sizes, multiple new algorithm families, hybrid deployment phases and stricter regulatory deadlines. Unlike the ECC transition, organisations cannot afford a decade-long drift.
The companies that will navigate this cleanly share one thing in common: they started with a clear picture of their current exposure. The ones that will struggle are already behind, because without visibility, there is no roadmap, just guesswork.
Before you can prioritise anything, you need to know what cryptographic assets you have and how vulnerable they are to quantum threats. This means understanding:
Manual audits at this scale are impractical. Most enterprise environments have hundreds of endpoints, certificates issued and rotated constantly and cryptographic dependencies embedded across cloud workloads, SaaS integrations and internal systems.
For applications and hosts, the standard output is a CBOM (cryptographic bill of materials) in CycloneDX format, aggregated into an organization-wide cryptographic inventory. For your public perimeter, a first baseline can come from outside.
This is exactly what DuoKey's Quantum Risk Score (QRS) automates. It evaluates your domain's observable cryptographic posture against four signals (algorithm resilience, crypto-agility, harvest exposure and migration posture) and produces a composite index from 0 to 100. Critically, the assessment operates entirely on publicly observable signals. No access to internal systems is required.
The output gives you the baseline every migration roadmap depends on.
Not all systems face the same quantum threat profile. Once you have visibility, classify assets by:
Data longevity: Data that must stay confidential for a decade or more is already at risk from harvest-now-decrypt-later (HNDL) attacks. Adversaries are capturing encrypted traffic today. A simple test is Mosca's inequality: if the number of years your data must stay secret (X) plus the years your migration will take (Y) is greater than the years until a cryptographically relevant quantum computer exists (Z), that data is already exposed. X + Y > Z means start now.
System lifespan: Automotive ECUs, industrial controllers and medical devices are difficult or impossible to update post-deployment. If a device will still be in the field in 2030, it needs a quantum-resistant cryptographic foundation now.
Regulatory alignment: Map your assets against NIST IR 8547, CNSA 2.0, ANSSI, NCSC and BSI timelines. The QRS report delivers this gap analysis per jurisdiction, so you can sequence your migration against real deadlines rather than abstract urgency.
The QRS Priority Migration Matrix does this work for you: it ranks your quantum-vulnerable assets by migration urgency, using a CVSS-style approach adapted for cryptographic obsolescence.
There is no single right migration strategy. Most organisations will combine approaches:
Encrypt-first: Address key establishment protocols before digital signatures, with hybrid ML-KEM (see our ML-KEM key management guide). PQC key exchange is less disruptive than signature migration. PKI changes are architecturally heavier and deferring them buys time to prepare infrastructure properly. The upside: you protect confidentiality against HNDL attacks with relatively lower operational disruption.
Hybrid cryptography: Running classical and PQC algorithms in parallel hedges against the (real) possibility that a PQC algorithm gets broken. The SIKE algorithm reached the final round of NIST standardisation before a classical attack destroyed it. Hybrid is a transitional posture, not a destination. For high-stakes environments, it's the right intermediate step.
Crypto-agility as the foundation: Regardless of which path you choose, your architecture needs to support algorithm swaps without service disruption. Policy-driven key management, where cryptographic algorithms are configuration rather than code, is what turns a one-time migration project into a sustainable security programme.
The QRS 36-month migration sequence delivered with each assessment maps these phases concretely against your specific posture, not a generic template.
Migrating to Post-Quantum Cryptography
PKI is typically the most time-consuming piece of any PQC migration (see the ML-DSA certificates and post-quantum PKI guide). NIST PQC signature algorithms (ML-DSA, SLH-DSA) produce significantly larger signatures than their classical counterparts. Certificate chains compound this: multiple signatures per chain means size increases stack up fast, potentially breaking network buffers, HSM throughput limits and application assumptions that have been stable for years.
Practical preparation steps:
None of this is quick. Starting PKI preparation now is the single best thing most enterprise teams can do to avoid crunch in 2028-2029.
PQC migration is not a project with an end date. NIST has standardised five algorithms so far, with more in the pipeline. BSI, ANSSI and other national bodies maintain their own suites and organisations operating globally may need to support multiple algorithm families simultaneously. And as SIKE demonstrated, even well-vetted algorithms can fail.
The right response is not paralysis. It's crypto-agility: the operational capability to update cryptographic algorithms across your infrastructure without redesigning systems or rewriting code. Build that capability now and every future algorithm change becomes a policy update, not an emergency.
Every step of a PQC migration roadmap depends on a reliable baseline. Without knowing where you stand, you cannot prioritise what to migrate, justify investment to leadership, or satisfy auditors asking for documented cryptographic exposure.
That baseline is what the Quantum Risk Score provides:
The assessment is free to start and requires no internal access. It operates exclusively on publicly observable signals, making it fast to deploy and straightforward to scope for even the most complex enterprise environments.
Request your Quantum Risk Assessment →
Organisations that understand their cryptographic exposure today will migrate on their own terms. Those that wait will face compressed timelines, constrained options and regulators asking uncomfortable questions.
The roadmap is five steps: know your exposure, prioritise by risk, choose your migration path, prepare your infrastructure and build for ongoing change. The first step is the one that unlocks all the others.
Start with visibility. The QRS gives you that in days, not months.
Q: What is a PQC migration roadmap?
A dated plan for replacing quantum-vulnerable public-key cryptography (RSA, ECC, Diffie-Hellman) with NIST post-quantum algorithms. It covers discovery, risk ranking, hybrid key exchange, PKI and signature migration, and decommissioning, with owners and deadlines aligned to regulation.
Q: How long does a post-quantum migration take?
Several years for most enterprises. The UK NCSC plans for discovery by 2028, priority migrations by 2031 and completion by 2035, which is a reasonable reference. Earlier cryptographic transitions, such as moving away from SHA-1, took a decade in many organizations.
Q: Where should a post-quantum migration start?
With discovery: a cryptographic inventory, ideally as CBOMs per application, plus a baseline readiness measurement. The first migration work is usually hybrid ML-KEM key exchange on externally exposed TLS and VPN endpoints, because it protects against harvest now, decrypt later without changing certificates.
Q: Hybrid or pure post-quantum cryptography?
Most roadmaps use hybrid key exchange (for example X25519MLKEM768 in TLS 1.3) during the transition, so a session stays secure if either algorithm holds. Some national authorities, including BSI and ANSSI, recommend hybrid for now; CNSA 2.0 targets pure ML-KEM-1024 and ML-DSA-87 for national security systems. Make the choice a policy setting rather than code.
Q: Do we need to replace AES and SHA-2?
Generally no. Quantum attacks weaken symmetric algorithms far less than public-key ones. AES-256 and SHA-384 or larger are considered adequate; CNSA 2.0 requires AES-256 and SHA-384.
Q: What is the deadline for post-quantum migration?
It depends on your sector and jurisdiction. NIST's draft IR 8547 proposes deprecation of quantum-vulnerable algorithms after 2030 and disallowance after 2035; the EU targets 2030 for high-risk systems and the UK 2031 for priority migrations, both 2035 for completion; FINMA expects Swiss financial institutions to have a board-approved roadmap by mid-2027. See the timeline table.
Geschrieben von
DuoKey Team
Related Resources
Sagen Sie uns, wo Kontrolle heute schwierig ist. Wir helfen Ihnen, den nächsten praktischen Schritt zu finden.
