PQC Migration Timeline: What to Do in 2025, 2026, 2027, and Beyond

The waiting period is over. NIST finalised FIPS 203, 204, and 205 on 13 August 2024, and FIPS 206 followed on 24 October. NIST IR 8547 set the deprecation calendar for RSA and elliptic curve cryptography in November 2024. The NCSC published its phased UK migration timeline in March 2025. There is no more "waiting for the standards" as justification for inaction. The standards exist. The dates are fixed. The question now is sequencing.

This article is written for the CISO or security architect who already accepts the case for migration and needs a concrete execution calendar. It works through what must happen in each phase from 2025 through 2033, identifies the dependencies that make sequencing non-trivial, and closes with a framework for deciding which systems to migrate first. For context on why post-quantum migration is necessary and how Shor's algorithm breaks RSA and ECDSA, see our article on what Shor's algorithm does to RSA and elliptic curve cryptography.

The Dates You Cannot Move Around

Five external anchors shape the migration calendar. None of them is negotiable.

NIST FIPS 203, 204, 205, 206, published August and October 2024. These are final published standards, not drafts. ML-KEM (FIPS 203), ML-DSA (FIPS 204), SLH-DSA (FIPS 205), and FN-DSA (FIPS 206) are the approved post-quantum algorithm suite. Submission names Kyber, Dilithium, SPHINCS+, and FALCON are still used informally, but the authoritative identifiers are the FIPS names.

NIST IR 8547, November 2024. This document formally designates RSA, ECDH, ECDSA, DSA, and finite-field Diffie-Hellman for deprecation. The stated transition timeline: RSA-2048 and comparable key sizes deprecated for new systems by 2030, with phased retirement of legacy systems pointing toward 2035. Any new system deployed after 2030 that uses RSA or ECDSA falls outside the NIST baseline. Systems containing data that must remain confidential beyond 2030 need to begin migration before 2030 arrives, not on the day it does.

NSA CNSA 2.0, September 2022 (clarified October 2023). US National Security Systems must use quantum-resistant algorithms exclusively by 2033. RSA and ECDH/ECDSA are fully retired from NSS by that date. This is the hardest public commitment to a specific end-of-life date from any government. For the commercial supply chain, it is a procurement signal: vendors who cannot demonstrate FIPS-203-compliant products will not compete for NSS contracts from 2027 onwards.

NCSC Phased Timeline, March 2025. The UK's National Cyber Security Centre published its first guidance with explicit calendar milestones: Phase 1 discovery and planning to 2028; Phase 2 high-priority system upgrades 2028 to 2031; Phase 3 complete migration 2031 to 2035. This applies to UK government bodies and critical national infrastructure. Commercial organisations in scope of NIS Regulations 2018 (UK) or EU NIS2 (in EU member states), or subject to FCA or PRA operational resilience obligations, should treat this timeline as the baseline planning expectation for their sector.

Q-Day central estimate: 2033 to 2035. The Global Risk Institute's 2024 Quantum Threat Timeline Report positions the median probability of a cryptographically relevant quantum computer (CRQC) within the 2033 to 2035 window. NSA's CNSA 2.0 mandate for 2033 retirement aligns with this. The NCSC's Phase 3 target of 2035 reflects the same range. None of these dates is certain, but the migration calendar is not built on certainty. It is built on the time required to complete a complex programme before that window opens.

2025: The Inventory Year

If your organisation has not yet begun its cryptographic inventory, 2025 is the year you are in. Not ahead of schedule. At the start of it.

No migration can proceed without a Cryptographic Bill of Materials (CBOM): a structured inventory mapping every cryptographic asset across your estate against the data it protects and the system that carries it. The CBOM records algorithm, key size, protocol, certificate, library version, and the system or data flow each instance protects. It also records the confidentiality lifetime of the data and the migration complexity of the system. Those two dimensions drive the migration sequencing in every subsequent phase.

In practice, the inventory phase alone runs six to twelve months for a complex enterprise. The NIST NCCoE SP 1800-38 migration guidance, and the US Presidential directive NSM-10 (which directed federal agency inventories to be completed by 2023), both treat the CBOM as the prerequisite to any further migration work. Discovery tooling from vendors including Keyfactor, Venafi, and IBM Guardium can automate asset identification across TLS endpoints, code-signing infrastructure, and PKI hierarchies. Automated tooling reduces the discovery time substantially; it does not make the inventory trivial.

Priority ordering for the inventory is not arbitrary. Identify long-lifetime data first: government communications, healthcare records, financial audit trails, intellectual property with decades-long commercial value. Then identify hardest-to-migrate systems: operational technology and IoT devices with multi-year refresh cycles, PKI root hierarchies, HSMs whose firmware may not support ML-KEM or ML-DSA. These are the systems that will determine whether your Phase 2 target dates are achievable. Finding them at the start of Phase 1 is the point. For a structured approach to inventorying and scoring your cryptographic assets, the QSECDEF Cryptographic Inventory guide covers the methodology in detail.

2026: Algorithm Selection and First Hybrid Deployments

By 2026, the algorithm selection question is settled. There is no residual ambiguity about which standards to adopt: ML-KEM (FIPS 203) for key encapsulation replaces RSA and ECDH key exchange; ML-DSA (FIPS 204) for digital signatures replaces ECDSA and RSA signatures in the general case; SLH-DSA (FIPS 205) provides a stateless hash-based fallback for high-assurance long-lived signing contexts; FN-DSA (FIPS 206) addresses constrained environments requiring compact signatures. Algorithm uncertainty was a reasonable reason for caution before August 2024. It is not a reason now.

The deployment path for online protocols is hybrid key exchange: combining a classical algorithm (X25519 or P-384) with ML-KEM in a single handshake. The mechanism is specified in IETF RFC 9496, the X-Wing Hybrid KEM, and in the IETF TLS working group's draft on hybrid design. The operational argument for hybrid deployment is structural: a hybrid scheme requires an adversary to break both components simultaneously. For harvest-now-decrypt-later (HNDL) exposure, where an adversary has collected ciphertext today for future decryption, hybrid TLS provides immediate protection for traffic generated from the point of deployment onwards. Data already collected and stored remains at risk.

The transition is already happening at scale. Google Chrome and Cloudflare deployed X25519 plus ML-KEM-768 hybrid key exchange in production TLS from 2023 to 2024. Non-PQC endpoints are not excluded: hybrid handshakes fall back gracefully. The engineering is validated. By 2026, there is no longer a technical risk argument for deferring hybrid deployment on internet-facing infrastructure. The organisational and procurement arguments may still apply. Resolve them in 2026.

2027: Hybrid on All High-Risk Flows, Certificate Migration Underway

The Mosca inequality establishes the arithmetic. If a CRQC arrives in year T, and your migration takes M years, you need to start your migration no later than T minus M. For a 2033 central estimate and a migration duration of four to six years for a complex enterprise, the start date that produces a margin falls in 2025 to 2027. Deferring hybrid deployment past 2027 extends the HNDL-vulnerable window for your highest-sensitivity data flows by one year for every year of delay. Each year of delay is not a cost pushed into the future. It is additional data collected and stored by adversaries, permanently.

By end-2027, any data flow carrying material whose confidentiality must extend past 2032 should be protected by hybrid key exchange. This is the threshold that the QSECDEF HNDL Risk Calculator operationalises. If your confidentiality requirement ends in 2028, the risk calculus is different to an organisation with thirty-year legal hold obligations on financial records.

Certificate migration demands early planning for a specific operational reason. The CA/Browser Forum Baseline Requirements cap X.509 certificate validity at two years. A certificate migration programme that targets 2027 completion for leaf certificates must be planned by 2025 at the latest, because the planning cycle, root CA replacement programme, and intermediate CA hierarchy rebuild each take twelve to eighteen months before leaf certificates can be issued. The root CA is the longest-lead item. Organisations that start certificate migration with the leaf certificates and work backwards will arrive at the root hierarchy problem when they have no runway left.

Code signing and firmware signing are high-priority 2027 targets for a reason that compound: signed binaries and firmware images have longevity well beyond their issuance date. Industrial control system firmware may run unmodified for fifteen years. Automotive ECUs carry signatures that must be verifiable for the vehicle's operational life. SLH-DSA (FIPS 205) and ML-DSA (FIPS 204) are the signing algorithms for these use cases. Images signed with RSA or ECDSA before the signing infrastructure is migrated will carry quantum-vulnerable signatures for their entire deployment life unless re-signed, which is operationally complex for embedded systems already in the field.

2028 to 2030: Deprecation Begins, Compliance Exposure Rises

NIST IR 8547 (November 2024) sets 2030 as the formal deprecation date for RSA and elliptic curve cryptography in new systems. A new deployment after 2030 that uses RSA-2048 for key exchange operates outside the NIST-recommended baseline. Compliance frameworks that reference NIST cryptographic guidance will treat it accordingly.

The downstream compliance exposure covers several frameworks simultaneously. FedRAMP, which governs cloud services to US federal agencies, will align its algorithm requirements to NIST IR 8547. CMMC 2.0 Level 2 and Level 3, applicable to defence contractors handling Controlled Unclassified Information, maps directly to NIST SP 800-171; specific extensions to PQC requirements for DFARS-covered systems are expected via CMMC and DFARS amendments. This applies to US defence contractors operating under DFARS-covered contracts and is not an obligation for UK or EU suppliers unless they have direct US contractual exposure. GDPR Article 32's "appropriate technical measures" requirement will similarly be read against the NIST IR 8547 baseline. NIS2 (in EU member states) and the UK NIS Regulations 2018 (in the UK) impose risk management obligations on operators of essential services and digital service providers; both frameworks will, over time, be read against the NIST IR 8547 baseline by supervisors and auditors.

Re-encryption of long-duration stored data is a 2028-to-2030 workstream for organisations that have not addressed it earlier. Insurance liability data, legal records, and healthcare files collected between 2018 and 2025 may carry confidentiality requirements stretching to the 2040s. Re-encrypting stored data at petabyte scale requires parallel key management infrastructure and extended operational planning. This is not a task that compresses into six months. Organisations that begin the inventory and prioritisation work in 2025 can execute re-encryption in the 2028-to-2030 window in manageable phases. Organisations that begin planning in 2028 will find the window too short for their data estate.

2033: The NSA Hard Date and What It Means for Vendors

NSA CNSA 2.0 mandates the full retirement of RSA and ECDH/ECDSA from US National Security Systems by 2033. That is the hardest public commitment to a specific cryptographic end-of-life date by any government. It carries a supply chain consequence: HSM vendors, CA software providers, and network security appliance manufacturers supplying NSS programmes must have FIPS-203-validated products in production before 2033. The procurement signal is earlier, in 2027, when NSS acquisition requirements begin specifying CNSA 2.0 capability.

Commercial organisations without a direct NSS contractual obligation have no equivalent hard legal deadline. The risk calculus is driven by Q-Day probability, not regulatory deadline. At the Global Risk Institute's 2024 median estimate of roughly fifty percent probability of a CRQC by 2034 to 2035 (verify against current source before relying on this figure), any organisation still running RSA-2048 key exchange in 2033 is taking a material probabilistic position. That is a board-level decision, not purely a technical one. Security architects who want to frame the 2033 exposure for executive audiences can use the GRI probability framing directly: at a coin-flip probability of Q-Day arriving in 2034 or 2035, the risk is not speculative.

A Decision Framework for Sequencing Your Migration

Not every system migrates at the same time. The sequencing follows from three criteria applied in order.

Confidentiality lifetime. Does the data or communication need to remain confidential past 2032? If yes, that system is a 2025 to 2026 priority regardless of migration complexity. HNDL exposure is present-tense for long-lived data. The migration calendar for those flows does not start at a future regulatory deadline. It started when adversaries began collecting the traffic.

Migration complexity. Is the cryptographic endpoint in a long-lifecycle embedded system, a legacy mainframe, or a proprietary protocol stack? These have the longest lead times. They must be identified first because they will define your Phase 2 and Phase 3 timeline, regardless of when the work is scheduled. A PKI root CA replacement programme runs twelve to eighteen months minimum. An OT device refresh cycle may run three to five years. Starting these inventories late makes all subsequent targets unachievable.

Dependency position. Does the system act as a root of trust for others? PKI certificate authorities, HSMs, and code-signing infrastructure are blocking dependencies: nothing downstream of them can be migrated until they are. Root-of-trust systems go first in all sequencing models. An organisation that migrates leaf certificates before its intermediate CA hierarchy, and its intermediate hierarchy before the root CA, will complete the migration in the wrong order and have to redo it.

Crypto agility is the architectural principle that makes iterative migration feasible across this sequence. Crypto agility means decoupling algorithm selection from application logic, so that cryptographic primitives can be swapped at the library or protocol layer without requiring application rewrites. NIST CSWP 04282021 documents the approach. Without it, each algorithm replacement requires a full application-layer change. With it, TLS algorithm negotiation, PKCS#11 mechanism selection, and JCE/JCA provider configuration are configurable at the cryptographic layer. The applications that depend on them do not need to be rewritten. The QSECDEF Crypto Agility guide covers implementation patterns. The PQC Migration Decision Tree translates the sequencing framework above into a step-by-step prioritisation tool.

The last distinction worth making is between a migration programme and a migration project. A project has a single deadline. A programme has phases, each with dependencies on prior phases. The most urgent phase, hybrid deployment on high-confidentiality flows, has no dependency on any later phase. It should begin immediately, before the inventory is complete and before the certificate migration is planned. Starting it does not require finishing everything else first. That is the structural difference between an organisation that completes its migration before 2033 and one that does not. The former starts its most urgent phase now. The latter waits for a complete plan.

Compliance obligations under CMMC, FedRAMP, and DFARS apply to specific US contractual and regulatory contexts. Verify applicable requirements with qualified legal or compliance counsel before acting.