What is PQC migration?
Post-quantum cryptography (PQC) is a family of public-key algorithms designed to resist attacks from both classical and quantum computers. A sufficiently large quantum computer running Shor's algorithm would break the public-key algorithms that protect almost all of today's traffic and signatures: RSA, finite-field Diffie-Hellman, ECDH and ECDSA/EdDSA.
A PQC migration is the organisational programme that moves those dependencies to quantum-resistant alternatives. It is much broader than a library upgrade. It touches TLS endpoints, VPNs, SSH, code signing, PKI and certificate authorities, HSMs, databases, identity providers, firmware, payment systems, and all the SaaS and software vendors that process your data. Symmetric cryptography (AES-256, SHA-2/SHA-3) is far less affected and generally needs only adequate key sizes.
Why start a PQC migration now
- Harvest now, decrypt later. Encrypted data captured today can be decrypted later. If your data has to stay confidential for ten years or more, such as health, financial, identity or state-sensitive records, it is exposed today.
- Migrations are slow. Past cryptographic transitions such as SHA-1 to SHA-2 and TLS 1.0 to 1.2 took most organisations years. Inventory alone often takes months in a complex environment.
- Customers and auditors are already asking. Security questionnaires, procurement requirements and regulators increasingly ask for a cryptographic inventory and a post-quantum roadmap.
- The standards are final. NIST published FIPS 203, 204 and 205 in August 2024, so "waiting for the standards" is no longer a reason to delay.
PQC migration deadlines and regulation
There is no single global deadline, but the major roadmaps converge on the same window: start now, protect high-risk systems by around 2030 and finish by 2035. NIST IR 8547 proposes deprecating quantum-vulnerable public-key algorithms at the 112-bit security level after 2030 and disallowing them after 2035, and the UK NCSC migration timelines set 2028, 2031 and 2035 milestones.
| Framework | Applies to | Key dates and requirements |
|---|---|---|
| NIST IR 8547 | US federal systems, widely used as the global reference | Quantum-vulnerable public-key algorithms deprecated after 2030 and disallowed after 2035 |
| NSA CNSA 2.0 | US National Security Systems and their suppliers | Exclusive use of quantum-resistant algorithms for software signing and networking equipment by 2030, browsers, servers, cloud services and operating systems by 2033, everything by 2035 |
| QCCPA and OMB M-23-02 | US federal agencies | Annual inventory of cryptographic systems and funded migration plans, in force now |
| UK NCSC | UK organisations, critical national infrastructure first | Discovery and planning by 2028, high-priority migrations by 2031, full migration by 2035 |
| EU coordinated PQC roadmap | EU Member States and critical sectors | Transition starts by the end of 2026, high-risk use cases protected by 2030, as much as feasible by 2035 |
| DORA | EU financial entities | Applies since January 2025: cryptographic controls must be managed and updated as cryptanalysis advances |
| PCI DSS v4.0 | Organisations that store, process or transmit card data | Requirement 12.3.3: inventory of cipher suites and protocols in use, reviewed at least annually, mandatory since March 2025 |
In practice, if you work in a regulated sector you should expect to show a quantum readiness plan well before 2030.
A 6-phase PQC migration plan
1. Establish governance and ownership
Appoint an accountable owner, often under the CISO, and a cross-functional team from security, infrastructure, application engineering, PKI, procurement and risk. Agree the scope, the risk appetite and how progress will be reported to the board and regulators.
2. Build a cryptographic inventory
Discover every place cryptography is used: certificates and keys, TLS configurations, protocols, libraries in source code and binaries, cloud KMS and HSM usage, and the cryptography your SaaS and software vendors use on your behalf. Record the algorithm, key length, protocol, owner, data classification and business process for each. Many teams export this as a Cryptography Bill of Materials (CBOM) in the CycloneDX format.
3. Assess and prioritise risk
Not everything can move at once. Rank assets by data shelf-life (how long the data must stay secret), exposure (whether it is internet-facing or crosses untrusted networks), business criticality and migration difficulty. Long-lived sensitive data on public channels goes first, because it is exposed to harvest-now-decrypt-later attacks.
4. Plan remediation and build crypto-agility
For each priority group, choose a path: upgrade the library or configuration, enable hybrid key exchange, replace the vendor, or accept and document the risk. Remove hard-coded algorithms where you can so that future changes are configuration changes. This is what crypto-agility means in practice.
5. Migrate, starting with key establishment
Protect confidentiality first by deploying hybrid ML-KEM key exchange on TLS, VPN and SSH. Then move signatures, PKI and code signing to ML-DSA or SLH-DSA as your CAs, HSMs and clients support them. Test for performance and interoperability, because post-quantum keys and signatures are larger and can break middleboxes and size-constrained protocols.
6. Monitor, prove and repeat
A migration is not finished when the last certificate is replaced. New services, vendors and dependencies keep reintroducing vulnerable cryptography. Track remediation continuously and produce evidence for auditors. This ongoing discipline is crypto posture management.
Which post-quantum algorithms to migrate to
- ML-KEM (FIPS 203), formerly CRYSTALS-Kyber, is the primary key-encapsulation mechanism for key exchange and encryption. ML-KEM-768 is the common default.
- ML-DSA (FIPS 204), formerly CRYSTALS-Dilithium, is the primary general-purpose digital signature.
- SLH-DSA (FIPS 205), formerly SPHINCS+, is a hash-based signature scheme with conservative security assumptions and larger signatures. It suits firmware and long-term signing.
- FN-DSA (Falcon) offers compact signatures and is being standardised as FIPS 206. HQC was selected in 2025 as a backup KEM based on different mathematics.
- LMS and XMSS are stateful hash-based signatures already approved for firmware and software signing (NIST SP 800-208).
Why key and signature sizes break things
The biggest practical difference in a PQC migration is size. Post-quantum public keys, ciphertexts and signatures are many times larger than the RSA and elliptic-curve values they replace, and that is where most interoperability problems come from.
| Algorithm | Type | Public key (bytes) | Ciphertext or signature (bytes) |
|---|---|---|---|
| RSA-2048 | Classical encryption and signatures | 256 | 256 |
| X25519 / Ed25519 | Classical elliptic-curve | 32 | 32 (key share) / 64 (signature) |
| ML-KEM-768 (FIPS 203) | Post-quantum key encapsulation | 1,184 | 1,088 (ciphertext) |
| ML-DSA-65 (FIPS 204) | Post-quantum signature | 1,952 | 3,309 |
| SLH-DSA-SHA2-128s (FIPS 205) | Post-quantum hash-based signature | 32 | 7,856 |
| FN-DSA-512 (Falcon) | Post-quantum compact signature | 897 | about 666 |
What that means in practice:
- TLS handshakes grow. A hybrid X25519 plus ML-KEM-768 key share adds more than 1 KB in each direction, which can split the ClientHello across packets and trip middleboxes, load balancers and firewalls that assume it fits in one.
- Certificate chains get much heavier. An ML-DSA chain with several signatures and public keys can add 10 KB or more to every full handshake, which matters for mobile, IoT and high-volume APIs.
- Fixed-size fields overflow. Database columns, HSM slots, smart cards, protocol headers and firmware partitions sized for RSA or ECC values need to be checked before migration, not after.
This is why testing belongs in every phase of the plan above and why inventories should record where cryptographic values are stored, not only which algorithms are used.
Common PQC migration mistakes
- Treating it as a one-off scan. A point-in-time spreadsheet is out of date within weeks.
- Ignoring third parties. A large share of your cryptographic exposure sits with SaaS and software vendors you do not control.
- Prioritising by count instead of risk. Fixing 500 low-impact internal certificates before one internet-facing system that carries long-lived customer data is the wrong order.
- Skipping crypto-agility. Hard-coding ML-KEM just repeats the same problem the next time an algorithm has to change.
- No evidence trail. If you cannot prove progress to auditors and customers, the work does not count commercially.
Running your PQC migration with PQCLayer
PQCLayer is the cryptographic control plane for regulated organisations. It supports each phase of a PQC migration from one system:
- Inventory: a unified, continuously updated view of cryptographic assets across cloud environments, enterprise systems and software vendors.
- Decision: risk scoring and impact analysis that turn raw findings into a prioritised migration queue.
- Control: remediation tracking, policy enforcement and audit reports that show progress over time.
Start with a free cryptography scan of your AWS account or assess your quantum readiness in a few minutes.
Frequently asked questions
What is PQC migration?
PQC migration is the process of replacing quantum-vulnerable public-key cryptography (RSA, Diffie-Hellman, and elliptic-curve algorithms such as ECDH and ECDSA) with post-quantum cryptography standardised by NIST, primarily ML-KEM (FIPS 203) for key establishment and ML-DSA (FIPS 204) or SLH-DSA (FIPS 205) for digital signatures, across every system, protocol, certificate and vendor that uses them.
How long does a PQC migration take?
For a large regulated organisation, a full post-quantum migration is a multi-year programme. Government roadmaps reflect this: the UK NCSC asks organisations to complete discovery by 2028, migrate high-priority systems by 2031 and finish by 2035, and NIST IR 8547 proposes deprecating quantum-vulnerable algorithms from 2030 and disallowing them by 2035.
What is the first step in a PQC migration?
The first step is a cryptographic inventory: finding where cryptography is used across applications, infrastructure, cloud services, certificates, keys and third-party vendors, and which algorithms, key sizes and protocols each one relies on. Without an inventory you cannot size, prioritise or prove the migration.
Should we use hybrid post-quantum cryptography?
Hybrid key exchange, which combines a classical algorithm such as X25519 with ML-KEM, is the common transitional approach for TLS and other protocols because it stays secure as long as either algorithm holds. Many browsers, CDNs and TLS libraries already support hybrid ML-KEM key exchange, so it is usually the lowest-risk way to start protecting data in transit.
Why migrate now if quantum computers cannot yet break RSA?
Because of harvest-now-decrypt-later (HNDL) attacks: adversaries can record encrypted traffic today and decrypt it once a cryptographically relevant quantum computer exists. Any data that must stay confidential for longer than the time remaining until then is already at risk, and migrations take years.
What is a PQC migration roadmap?
A PQC migration roadmap is the dated plan that turns the cryptographic inventory into work: which systems move in which order, which algorithms and hybrid modes they move to, who owns each step, what it costs and how progress is evidenced. Regulators and enterprise customers increasingly ask to see one, and national timelines such as the UK NCSC's 2028, 2031 and 2035 milestones give it its outer dates.
What is the difference between PQC and quantum key distribution (QKD)?
Post-quantum cryptography is new mathematics that runs as software on existing hardware and networks. Quantum key distribution uses quantum physics to share keys and needs dedicated hardware and point-to-point links. Security agencies including the NSA and the UK NCSC recommend PQC rather than QKD for almost all organisations, which is why PQC migration is the mainstream path.
How does PQCLayer help with PQC migration?
PQCLayer is a cryptographic control plane: it builds a unified inventory of cryptographic assets across cloud, on-prem systems and SaaS vendors, scores each finding by business impact and exposure, and tracks remediation over time with audit-ready reporting, so the migration can be planned, prioritised and proven.
Sources and further reading
- NIST FIPS 203: Module-Lattice-Based Key-Encapsulation Mechanism (ML-KEM)
- NIST FIPS 204: Module-Lattice-Based Digital Signature (ML-DSA)
- NIST FIPS 205: Stateless Hash-Based Digital Signature (SLH-DSA)
- NIST IR 8547: Transition to Post-Quantum Cryptography Standards
- NIST SP 800-208: Stateful Hash-Based Signature Schemes (LMS, XMSS)
- NIST selects HQC as a fifth post-quantum algorithm (March 2025)
- NIST NCCoE: Migration to Post-Quantum Cryptography project
- UK NCSC: Timelines for migration to post-quantum cryptography
- European Commission: Coordinated implementation roadmap for the transition to PQC
- OMB M-23-02: Migrating to Post-Quantum Cryptography
- CycloneDX: Cryptography Bill of Materials (CBOM)