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:
- NIST IR 8547 (US): proposes deprecating quantum-vulnerable public-key algorithms at the 112-bit security level after 2030 and disallowing them after 2035.
- NSA CNSA 2.0 (US National Security Systems): phased adoption of quantum-resistant algorithms, with full transition by 2035 and earlier dates for software signing and networking equipment.
- US federal agencies: the Quantum Computing Cybersecurity Preparedness Act and OMB M-23-02 require agencies to inventory their cryptographic systems and plan the migration.
- UK NCSC: discovery and planning by 2028, high-priority migrations by 2031, full migration by 2035.
- European Union: the coordinated EU PQC roadmap asks Member States to begin the transition by the end of 2026, protect high-risk use cases by 2030 and complete as much as feasible by 2035. DORA already requires financial entities to manage cryptographic controls and update them as cryptanalysis advances.
- PCI DSS v4.0: requirement 12.3.3 requires an annually reviewed inventory of the cryptographic cipher suites and protocols in use.
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).
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 scan of your SaaS vendor exposure 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.
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.