Direct answer: NIST's post-quantum migration plan was finalised in October 2026 (NIST IR 8547; the CSRC document history dates it 27 October 2026). NIST will deprecate quantum-vulnerable public-key cryptography after 2030 and disallow it in NIST standards and guidelines after 2035. US federal high-value and high-impact systems face earlier dates: key establishment by 31 December 2030 and digital signatures by 31 December 2031; federal agencies must also support TLS 1.3 by 2 January 2030. The EU expects Member States to start by the end of 2026 and to transition high-risk use cases no later than the end of 2030. The UK NCSC's milestones are 2028 for goals, discovery and an initial plan; 2031 for early highest-priority migration; 2035 for completion. For enterprises, the work to start now is: cryptographic inventory (CBOM) → prioritise key establishment for harvest-now-decrypt-later risk → sequence signatures by coordination effort → lock in HSM/TPM/PKI lead times → use hybrid modes as the bridge.
This guide is for enterprise architects, security, operations and procurement teams making technology-selection, budget and migration-schedule decisions, especially Chinese manufacturers that sell into or buy from the US, EU and UK markets. Data cut-off: 7 November 2026; sources are NIST IR 8547 (final) and the NIST PQC project page, the European Commission PQC policy page and the UK NCSC PQC migration timelines (accessed 7 November 2026). Official facts, editorial judgement and items to confirm are kept separate.
(1) 2030/2035 are NIST deprecation/disallowance dates, not the day a quantum computer arrives, and not a date to start work. (2) Migrate key establishment first (harvest-now-decrypt-later), then signatures (longer coordination); authentication can follow, but PKI, tokens and hardware lead times cannot be improvised. (3) Hybrid mode is a bridge, not the destination; HSM/TPM and PKI replacement cycles decide the real pace.
Three timelines: the same years mean different things
The final NIST IR 8547 sets the main line: NIST will deprecate quantum-vulnerable public-key cryptography after 2030 and disallow it in NIST standards and guidelines after 2035, with the 2030-2035 window left for lower-risk systems and legacy constraints. US federal policy pulls the most sensitive systems forward through EO 14412 and OMB M-26-15: high-value assets and high-impact systems must adopt PQC for key establishment by 31 December 2030 and for digital signatures by 31 December 2031, and support TLS 1.3 by 2 January 2030. The EU runs on a different rhythm: the Coordinated Implementation Roadmap adopted in June 2025 asks all Member States to start transitioning by the end of 2026 and high-risk use cases to transition no later than the end of 2030. The UK NCSC gives an indicative schedule: by 2028 define goals, complete discovery and build an initial plan; by 2031 carry out early highest-priority migration and refine a full roadmap; by 2035 complete migration.
| Jurisdiction | Official document | Key dates | Scope |
|---|---|---|---|
| US NIST | FIPS 203/204/205 (13 Aug 2024); NIST IR 8547 (final, Oct 2026) | Deprecate quantum-vulnerable public-key crypto after 2030; disallow in NIST standards and guidelines after 2035 | US federal agencies; NIST presents it as a blueprint for critical infrastructure and other organisations |
| US federal policy | EO 14412, OMB M-26-15, EO 14306 | Mitigate as much quantum risk as feasible by 31 Dec 2030; HVA/HIS key establishment by 31 Dec 2030, signatures by 31 Dec 2031; TLS 1.3 by 2 Jan 2030 | Federal high-value assets, high-impact systems and high-sensitivity data systems |
| European Union | Commission Recommendation (Apr 2024); Coordinated Implementation Roadmap (Jun 2025) | All Member States start by end-2026; high-risk use cases no later than end-2030 | Member States; public sector and private entities serving public utilities |
| United Kingdom | NCSC, Timelines for migration to PQC | 2028 goals/discovery/initial plan; 2031 highest-priority migration + full roadmap; 2035 completion | UK industry, government and regulators; focused on large organisations and critical national infrastructure |
Sources: NIST IR 8547 (October 2026), NIST PQC project page, European Commission Post-Quantum Cryptography policy page (last updated 20 October 2026), UK NCSC PQC migration timelines (accessed 7 November 2026). The scopes differ: the EU "start" is not "completion", and NIST's 2035 is not the only deadline for every system; specific obligations follow the original documents and applicable law.
Why start now: not because a quantum computer exists
NIST identifies "harvest now, decrypt later" (HNDL) as the source of urgency: adversaries collect encrypted traffic today and decrypt it once quantum technology matures; sensitive data often must stay confidential for years, so waiting for a quantum computer is too late. IR 8547 also cites Mosca's theorem: if data must stay secure for X years, migration takes Y years, and a cryptanalytically relevant quantum computer is expected in Z years, migration must start before X + Y exceeds Z. NIST notes that past cryptographic transitions took 10 to 20 years, and this broader migration will likely take at least that long; the federal 2030/2031 deadlines leave "little margin".
Another commonly missed distinction is that encryption, signatures and authentication carry different risk. Encryption and key establishment are directly exposed to HNDL and should move first. Signatures are not exposed to HNDL, but signature ecosystems involve certificates, code signing, documents, devices and many parties, so the migration takes longer and must also start early. Authentication only needs to be secure at the moment it happens, so it can theoretically wait longer - but the PKI, smart cards, tokens and endpoints it depends on also have multi-year replacement cycles. Scheduling all three as one bucket usually produces "we did the easiest part and missed the critical one".
What replaces what: RSA/ECC out, ML-KEM/ML-DSA in
The mapping is clear. The quantum-vulnerable algorithms are RSA, ECDSA, EdDSA, finite-field DH/MQV and elliptic-curve DH/MQV. The replacements are ML-KEM (FIPS 203, key establishment), ML-DSA (FIPS 204, signatures), SLH-DSA (FIPS 205, stateless hash-based signatures), and the stateful hash-based schemes LMS/HSS and XMSS/XMSSMT in SP 800-208, which suit use cases such as software and firmware signing. Symmetric cryptography largely stays: NIST considers symmetric primitives of at least 128 bits to meet at least Category 1; the work is SHA-1 and a few 112-bit symmetric standards that are disallowed after 2030.
| Algorithm in use | Quantum threat | NIST migration target | Key dates/notes |
|---|---|---|---|
| RSA (signatures, key transport) | Shor's algorithm | ML-DSA or SLH-DSA for signatures; ML-KEM for key establishment | 112-bit signatures deprecated after 2030, disallowed after 2035 |
| ECDSA | Shor's algorithm | ML-DSA or SLH-DSA | 112-bit; deprecated after 2030, disallowed after 2035 |
| EdDSA | Shor's algorithm | ML-DSA or SLH-DSA | 128-bit; deprecated after 2030, disallowed after 2035 |
| (EC)DH, MQV | Shor's algorithm | ML-KEM; can be combined with classical algorithms | 112-bit; deprecated after 2030, disallowed after 2035 |
| AES, SHA-2, SHA-3 | Minimal impact | Keep using | At least 128-bit is treated as at least Category 1 |
| SHA-1, a few 112-bit symmetric standards | Classical attacks | SHA-2/3, AES-128 and above | SHA-1 disallowed in FIPS modules after 2030; 112-bit symmetric disallowed in 2030 |
Sources: NIST IR 8547 Tables 2-8 (October 2026). On parameter sets: ML-KEM-512/768/1024 map to Categories 1/3/5, and NIST explicitly recommends ML-KEM-768 as the default; ML-DSA-44/65/87 map to Categories 2/3/5, with ML-DSA-44 dropping to Category 1 if an approved random bit generator with less than 192 bits of security is used. This table is an editorial summary; parameters and conditions follow FIPS 203/204/205.
What to migrate: more than swapping an algorithm
PQC migration is not a switch but a chain: protocols must negotiate the new algorithms, cryptographic libraries must implement them, HSMs/TPMs must execute them, PKI must issue and revoke new certificates, applications must change code and configuration, and code-signing/firmware update chains must be verifiable by devices. NIST specifically warns that if a device cannot update the code that verifies signatures after manufacture, it must be designed to verify post-quantum signatures from the start - otherwise those devices cannot be fixed by an upgrade once quantum computers arrive. Hardware (HSMs, TPMs, smart cards, tokens) has the longest lead time and should start earliest.
| Layer | Typical objects | Key actions |
|---|---|---|
| Protocols | TLS, SSH, IPsec/IKE, CMS | Upgrade to versions supporting PQC/hybrid key exchange; TLS 1.3 is the near-term path |
| Cryptographic libraries | OpenSSL, BoringSSL, Libsodium and similar | Upgrade to versions with ML-KEM/ML-DSA; test performance and side channels |
| Hardware | HSMs, TPMs, smart cards, authentication tokens | Firmware/hardware upgrade or replacement; secure lead times early |
| PKI | CA/RA, certificates, OCSP/CRL, directory services | Issue/validate/revoke PQC and hybrid certificates; assess larger certificate chains |
| Applications and services | Web, databases, cloud services, enterprise software | Change code and configuration; test interoperability, rollback and monitoring |
| Code signing/firmware | Release chain, device verifiers | Devices must verify PQC before shipping; otherwise replace or decommission |
| Email and documents | S/MIME, OpenPGP, PDF signatures | End-to-end encryption is exposed to HNDL; signatures need multi-party coordination |
Sources: NIST IR 8547 Sections 2.2 and 3.1 (October 2026). This is an editorial migration-object list, not an official checklist; whether a component supports PQC depends on vendor documentation and testing.
Priority: save what is long-lived and what cannot be upgraded
A workable ordering principle is: how long must the data stay confidential, can the system be upgraded, and how many parties must coordinate. Long-lived confidential data (medical, government, R&D, financial records) is exposed to HNDL first, so key establishment should move to ML-KEM or a hybrid mode first. Devices that cannot be updated remotely, with verifiers frozen in firmware, must be addressed at procurement and design time or replaced/decommissioned. High-value/high-impact systems and PKI/identity infrastructure follow federal or sector dates. General signatures and low-risk short-lived systems can follow vendor cadence, but 2035 is not a nine-year grace period. NIST and OMB M-26-15 both say systems that cannot support PQC should be identified and prioritised for replacement or decommissioning.
| Priority | Trigger | Do first |
|---|---|---|
| P0 long-lived confidential data | Data must stay confidential beyond 2030, or has a lifecycle over 5-10 years | Move key establishment to ML-KEM/hybrid first; assess HNDL exposure |
| P0 devices that cannot be upgraded | Firmware/verifiers cannot be updated remotely | Require PQC verification at design time; otherwise replace or decommission |
| P1 high-value/high-impact systems | Federal HVA/HIS or equivalent | Key establishment by 31 Dec 2030; signatures by 31 Dec 2031 |
| P1 PKI and identity | CA, certificates, smart cards, tokens, directories | Upgrade CA/tokens early; pilot hybrid certificates |
| P2 general signatures | Code, document and email signing | Schedule 2031-2035; solve interoperability and verification chains first |
| P3 low-risk short-lived | Short data lifetime, replaceable systems | Follow vendor cadence; complete before 2035 |
Sources: NIST IR 8547 Sections 3-4, EO 14412, OMB M-26-15 (accessed 7 November 2026). The priority order is an editorial method, not an official classification; organisations should adjust it to their data classification, threat model and regulatory requirements.
Hybrid mode: how to build the bridge
NIST allows hybrid "PQC + classical" schemes during the transition. For key establishment, the generic composite technique in SP 800-56C combines shared secrets Z and T and then derives keys; SP 800-227 provides guidance on key combiners. For signatures, dual signatures place ML-DSA and ECDSA/RSA signatures on the same message. As long as at least one component is NIST-approved, the combination can still be FIPS 140-validated. But NIST also says hybrids add implementation and architectural complexity, can introduce new security risk and cost, and are typically expected to be temporary, followed by a second transition to pure PQC. Protocols must fix the order of shared secrets so both ends interpret the combination the same way.
| Mode | How it works | Where it fits | Watch out for |
|---|---|---|---|
| Hybrid key establishment | ML-KEM + ECDH, combined per SP 800-56C, combiner per SP 800-227 | TLS, IPsec and VPN during transition | Secure if at least one component is secure; more bandwidth/CPU; fix ordering at protocol level |
| Dual signatures | ML-DSA + ECDSA/RSA signing the same message | Code signing, certificates, document signing | Verifiers must support both; signatures and certificates grow |
| Pure PQC | ML-KEM/ML-DSA/SLH-DSA only | New systems, closed environments | Ecosystem and interoperability maturity must be tested |
Sources: NIST IR 8547 Section 3.2 (October 2026). NIST does not require enterprises to use hybrid mode; the choice depends on the application, vendor support, performance and security review.
Estimating cost: no official price list, only cost drivers
NIST, the European Commission and the UK NCSC do not publish a unified PQC migration cost. The NCSC explicitly warns that the total financial cost could be significant and that budgets must cover preparatory work as well as the migration itself. The practical approach is not to look for a "price per system" but to estimate by cost driver: discovery and inventory, products and licences, hardware replacement, PKI changes, performance headroom, testing and dual-running, people and compliance. Hardware and PKI often cannot be bought into place instantly; lead times and certificate-chain compatibility are the hard scheduling constraints. Folding PQC into normal refresh cycles is usually more controllable than a one-off "big bang" programme.
| Cost bucket | Driver | Budgeting approach |
|---|---|---|
| Discovery and inventory | Number of systems, protocols, libraries, certificates and devices | Sample first, then go exhaustive; estimate effort by applications x interfaces |
| Products and licences | PQC-capable libraries, gateways and security products | Book against vendor refresh cycles; avoid concentrated purchasing |
| Hardware | HSMs, TPMs, smart cards, tokens, endpoints | Schedule by lead time and replacement batches; track as separate capex |
| PKI | CA/RA, certificate chains, revocation, directories | Assess bandwidth, storage and logging costs of larger certificates |
| Performance | Handshake CPU, packet size, MTU/fragmentation | Benchmark at peak QPS and keep headroom |
| Testing and dual-running | Interoperability matrix, hybrid modes, rollback | Estimate by environments x vendors |
| People and compliance | Cryptography/security architecture, audit, training | Fund by project phase within the security budget |
Sources: editorial synthesis; cost drivers draw on NIST IR 8547 Sections 2.2 and 3.2 and the UK NCSC timelines (accessed 7 November 2026). The table contains no prices or unit rates and is not a budget commitment; actual cost depends on asset scale, vendor quotes and project scope.
90-day action list
If there is no PQC programme yet, spend the first 90 days turning invisible cryptographic assets into a schedulable inventory instead of rushing a full replacement. The order is: define scope, build a CBOM, tag risk, run two pilots, question vendors, set budget and policy, then rehearse rollback.
- Scope (weeks 1-2): list systems, protocols, certificates, devices and supply-chain interfaces that depend on public-key cryptography, externally and internally.
- Build a CBOM (weeks 3-5): record algorithms, libraries and versions, certificates, key lengths, issuers, expiry, owning system and owner.
- Tag (weeks 5-6): mark HNDL exposure, system lifecycle, remote-upgrade capability and vendor PQC support.
- Pilot (weeks 6-9): pick one TLS entry point and one code-signing chain; test interoperability and performance with hybrid ML-KEM + ECDH.
- Ask vendors (weeks 6-10): request PQC roadmaps, FIPS 140 validation plans, HSM/TPM lead times, certificate-chain and revocation support.
- Budget (weeks 9-11): fund discovery, pilot, scale migration and decommissioning as four phases; keep hardware and PKI separate.
- Policy (weeks 10-12): set cryptographic-agility requirements, disallowance dates for quantum-vulnerable algorithms, exception approval and supplier contract clauses.
- Rehearse (week 12): test rollback, performance, monitoring and certificate rotation; feed the results into the next phase.
FAQ
Is NIST IR 8547 a mandatory standard?
No. IR 8547 is a NIST internal report describing NIST's migration approach and schedule; the actual algorithm standards are FIPS 203/204/205. It binds US federal agencies through policies such as EO 14412 and OMB M-26-15, but it is not a direct legal obligation for private companies; it reaches them through procurement, contracts, supply chains and sector regulation.
Is 2030 or 2035 the deadline?
Both, with different meanings: NIST deprecates quantum-vulnerable public-key cryptography after 2030 and disallows it in NIST standards and guidelines after 2035. US federal high-value/high-impact systems have earlier dates: key establishment by 31 December 2030 and signatures by 31 December 2031. If you supply those customers, the effective deadline is often set by contract rather than by NIST.
Does a quantum computer that breaks RSA exist now?
No known cryptanalytically relevant quantum computer exists. The urgency comes from harvest-now-decrypt-later and migration time: long-lived sensitive data collected today could be decrypted once quantum computers mature, and NIST notes past cryptographic transitions took 10-20 years, with this one broader in scope.
Should we migrate encryption or signatures first?
Migrate key establishment/encryption first because it is directly exposed to harvest-now-decrypt-later. But signatures should also start early because certificates, code signing, devices and multi-party coordination take longer. Authentication itself can follow, but the PKI, tokens and endpoints it relies on must be scheduled early.
Does NIST accept hybrid mode?
Yes. NIST allows PQC and classical algorithms to be combined: key establishment can use the generic composite technique in SP 800-56C, and signatures can use dual signatures. As long as at least one component is NIST-approved, the combination can still be FIPS 140-validated. NIST treats hybrids as transitional, however; they add complexity and cost, and a move to pure PQC is still expected.
Which ML-KEM parameter set should we use?
NIST recommends ML-KEM-768 as the default because it offers a good balance of security margin and performance. ML-KEM-512 maps to Category 1 and ML-KEM-1024 to Category 5; choose another set if performance is constrained or a higher security level is required, and validate it in your own environment.
Do symmetric algorithms need to change?
Largely no. NIST considers symmetric primitives of at least 128 bits to meet at least Category 1; AES, SHA-2 and SHA-3 remain usable. The work is SHA-1 (disallowed in FIPS modules after 2030) and a few 112-bit symmetric standards (disallowed in 2030).
With a limited budget, what comes first?
Start with discovery and a CBOM, then a small hybrid pilot; at the same time, flag long-lived devices that cannot be upgraded as replacement or decommissioning candidates. Folding PQC into normal refresh cycles is more controllable than a one-off full replacement; do not wait until 2034.
Research method and limitations
This article separates "official facts" from "editorial judgement": the FIPS 203/204/205 publication date, the 2030/2035 dates in NIST IR 8547, the 2030/2031 and TLS 1.3 dates from EO 14412 and OMB M-26-15, the EU's end-2026 start and end-2030 high-risk dates, and the UK 2028/2031/2035 milestones come from NIST, the European Commission and the UK NCSC official pages and PDF (accessed 7 November 2026). The priority matrix, 90-day list and cost buckets are editorial implementation advice, not official templates.
Eight limitations: (1) the documents have different addressees (US federal agencies, EU Member States, UK organisations) and are not interchangeable; (2) NIST IR 8547 is a US federal perspective, and enterprise obligations also depend on contracts, sector regulation and customer requirements; (3) the EU roadmap is a high-level document addressed to Member States, with national roadmaps deciding implementation; (4) the UK NCSC timeline is indicative, not a legal deadline; (5) the official documents do not provide a unified migration cost, so this article lists drivers only; (6) algorithms and standards are still evolving (the HQC FIPS, the Falcon FIPS and additional signature schemes), so recheck after publication; (7) sector-specific requirements (finance, healthcare, energy) are not covered; (8) performance and interoperability must be tested in your own environment, and this article makes no general performance claim. This is not legal or compliance advice.
Sources and basis
- NIST, Transition to Post-Quantum Cryptography Standards, NIST IR 8547 (October 2026): csrc.nist.gov/pubs/ir/8547/final; PDF: nvlpubs.nist.gov/nistpubs/ir/2026/NIST.IR.8547.pdf. Deprecation after 2030, disallowance after 2035; EO 14412/OMB M-26-15 2030/2031 dates; TLS 1.3 by 2 January 2030; algorithm Tables 2-8; hybrid modes and HNDL. Accessed 7 November 2026.
- NIST CSRC, Post-Quantum Cryptography project page: csrc.nist.gov/projects/post-quantum-cryptography. FIPS 203/204/205 published 13 August 2024; HQC selected for standardisation as an alternative KEM on 11 March 2025; NIST will remove quantum-vulnerable algorithms from its standards by 2035. Accessed 7 November 2026.
- European Commission, Post-Quantum Cryptography policy page: digital-strategy.ec.europa.eu/en/policies/post-quantum-cryptography. April 2024 Recommendation; June 2025 Coordinated Implementation Roadmap; Member States start by end-2026 and high-risk use cases by end-2030; 2025 survey and FAQ. Last updated 20 October 2026; accessed 7 November 2026.
- UK National Cyber Security Centre, Timelines for migration to post-quantum cryptography: ncsc.gov.uk/guidance/pqc-migration-timelines. 2028 goals/discovery/initial plan; 2031 highest-priority migration and full roadmap; 2035 completion; total cost could be significant and budgets should cover preparation and migration. Accessed 7 November 2026.
Data cut-off 7 November 2026; based on official pages and PDF; not legal or compliance advice; specific obligations depend on applicable law, contracts and regulatory requirements.