Post-Quantum Migration Guide for Crypto
What post-quantum migration means for crypto, who migrates what, and a checklist you can run against your own setup.
Start with a cryptographic inventory · Separate enterprise migration from on-chain authorization · Check which standards and policies apply.
Post-quantum migration is the move from today’s public-key cryptography, which a large enough quantum computer would break, to algorithms designed to resist that attack. For crypto, it splits cleanly by who you are: an individual holder, a firm or exchange, or a chain’s developers each migrate different things on different timelines. This guide covers why the clock is running, what the standards bodies have set, what needs to change, and a step-by-step checklist. For the underlying math, see the plain-English guide to post-quantum cryptography.
1. The one idea: inventory first, swap second
You can’t migrate what you haven’t found. NIST’s migration guidance emphasizes cryptographic discovery and inventory: mapping where cryptography is used, from TLS and VPNs to signing keys, HSMs, stored data, and APIs, and identifying dependencies before planning replacements. Only then do you prioritize and replace.
The second idea underneath it is crypto-agility, which refers to the ability to replace or adapt cryptographic algorithms as it preserves security and ongoing operations. Configurable algorithm choices help, though some transitions also need changes to protocols, hardware, or key management. Discovery and architecture are substantial parts of migration, alongside implementation and testing.
2. Why now, before any machine exists
No publicly demonstrated quantum computer can break this cryptography today, so the pressure isn’t an attack in progress. It is two slower forces.
The first is harvest now, decrypt later: an attacker can retain encrypted information today and attempt to decrypt it once a capable quantum computer exists. For a crypto business, this is relevant when long-lived confidential records or communications depend on quantum-vulnerable key establishment or encryption. Blockchain signatures create a different risk: an exposed public key could enable future private-key recovery and forged spends if that key still controls funds.
The second is lead time. Rolling out new cryptography across standards, wallets, services, and a consensus protocol takes years of its own, independent of when Q-Day arrives. So, the planning window is now.
3. The standards timeline
These are standards and compliance dates, not predictions of when an attack becomes possible.
| Milestone | When | What it means |
| NIST finalizes ML-KEM, ML-DSA, SLH-DSA (FIPS 203/204/205) | August 2024 | The first post-quantum standards are available to build on |
| NIST selects HQC as a backup KEM | March 2025 | A code-based alternative to ML-KEM; NIST plans to finalize the standard around 2027 |
| NIST IR 8547 draft: deprecation of listed 112-bit classical parameters | After 2030 | Proposed deprecation of parameters such as RSA-2048 and ECC P-224; continued use would require assessing the security risk |
| NIST IR 8547 draft: disallowance of listed quantum-vulnerable schemes | After 2035 | Proposed disallowance for covered uses, including stronger classical parameters such as ECC P-256 |
| CNSSP 15 requirements for commercial National Security Systems | From 2027; legacy phased out by 2030 | NSA says new commercial NSS must support quantum-resistant algorithms from 2027; legacy systems unable to support them are to be phased out by 2030 |
IR 8547 is a draft proposal, and it supports hybrid schemes (a classical and a post-quantum algorithm together) through the transition. Our NIST standards guide explains each algorithm.
4. What needs to migrate
The threat is uneven, so the work is too. Signatures and key exchange are the exposure; symmetric encryption and hashing largely survive.
| Component | Quantum-vulnerable examples | Replace with | Priority |
| Key establishment (TLS, VPNs) | RSA, ECDH, finite-field DH | ML-KEM, usually as a hybrid with a classical exchange | High: harvest-now-decrypt-later applies |
| Digital signatures | RSA, ECDSA, EdDSA, BLS | ML-DSA, or SLH-DSA where a conservative hash-based scheme is wanted | Medium to high, depending on key lifetime |
| Code and firmware signing | RSA, ECDSA | Hash-based schemes such as SLH-DSA, LMS, or XMSS | High: signing keys are long-lived |
| Data at rest | Depends on the cipher and how its keys are protected | Review encryption and key protection; migrate vulnerable dependencies and re-encrypt or rewrap affected archives where needed | High where long-lived confidential data depends on vulnerable key protection |
| Hashing | Depends on purpose and output length | SHA-256 or larger | Assess the required preimage and collision resistance; quantum effects depend on the hash’s use |
| On-chain transaction signatures | ECDSA, Schnorr | the chain’s eventual post-quantum scheme | Network-level; some chains allow account-level adoption earlier |
A correctly constructed hybrid can retain protection if one component stays secure. Hybrid key establishment combines the component secrets with an appropriate construction; hybrid signatures require both signatures to verify, because accepting either independently leaves a classical bypass. Hybrid key exchange is already widely deployed, whereas signature deployment and the applicable standards vary by application.
LMS and XMSS require reliable signing-state management to prevent one-time key reuse, including after failures or recovery. SLH-DSA avoids that state requirement, so the hash-based options aren’t interchangeable deployment choices.
5. Who migrates what
Individuals and self-custody: You don’t migrate the chain, and no wallet upgrade alone makes ordinary Bitcoin post-quantum safe. What you can do is reduce exposure where your chain allows it and follow its migration roadmap. On Bitcoin, fresh P2PKH or P2WPKH outputs keep public keys behind hashes, provided those keys haven’t been disclosed elsewhere. Avoid key reuse, and check whether your holdings depend on an exposed key. The full routine is in how to protect your crypto from quantum computers, and seed phrases vs PQC covers what a migration does to your backup.
Firms, exchanges, and custodians: This is where full enterprise migration applies, and it is the harder job. Inventory everything first: TLS endpoints, internal service traffic, HSMs, firmware-signing keys, KYC archives, backups, and third-party APIs. Prioritize long-lived confidential data (KYC that still identifies a person in 2035) and firmware-signing keys, deploy hybrid key exchange where you can, and re-encrypt or rewrap legacy backups whose key protection is vulnerable. Public-key exposure on customer balances is its own problem, covered in why exchange wallets are the weakest link.
Chains and protocols: Native transaction and consensus signatures require network-level migration. Where a chain already supports suitable smart-contract verification, individual accounts may adopt post-quantum authorization earlier, though their protection depends on every spending and privileged-control path enforcing it and still rests on the underlying network. Bitcoin’s path is debated through drafts like BIP-360 and BIP-361, whereas Ethereum’s post-quantum work spans execution, consensus, and data availability. The Ethereum Foundation’s post-quantum team assesses that L1 protocol upgrades could be completed by 2029, with full execution-layer migration taking additional years, which is a planning assessment rather than a guaranteed date. Other chains vary widely. Which cryptocurrencies are quantum-resistant assesses where each stands.
6. The post-quantum migration checklist
Run this against your own setup:
- Inventory: Map every place you use cryptography: TLS, VPNs, certificates, HSMs, signing keys, stored data, APIs, embedded devices.
- Prioritize: Rank by how long the data stays confidential, how long the system lives, and how hard it is to replace. Long-lived secrets and long-lived signing keys go first.
- Build crypto-agility: Identify what must change when an algorithm is replaced, and reduce unnecessary dependencies on fixed algorithms or key formats.
- Deploy supported hybrid key exchange: Check both endpoints and every relevant connection, including CDN-to-origin traffic. Upgrade unsupported software where needed, and verify that connections negotiate the intended post-quantum hybrid.
- Plan phased replacement for legacy and embedded systems, which can’t be patched as easily and need the most lead time.
- Track the deadlines that apply to you, from NIST and any sector rules down to your own chain’s migration roadmap, and re-inventory as you go.
- Test complete workflows before declaring migration done: Verify interoperability and which algorithms were negotiated. For account authorization, check that recovery and upgrade controls cannot bypass the post-quantum requirement, since hybrid TLS key exchange alone does not establish post-quantum authentication.
7. What migration cannot do
- Migration cannot erase an exposed public key: It can protect funds by moving them into suitable post-quantum authorization before compromise, so the old key no longer authorizes spending. Moving to a fresh classical key may reduce exposure, but does not provide post-quantum spending protection.
- A wallet upgrade alone does not migrate a chain: Native transaction and consensus protection require changes to the network’s rules. Where existing smart-contract capabilities support post-quantum authorization, an account can adopt it separately, provided every spending and privileged-control path enforces the requirement.
- Migration cannot secure encrypted copies an attacker already collected: Updating your systems protects later communications and the stored copies you control; it cannot replace vulnerable ciphertext retained elsewhere. For signing keys, the aim is to remove their spending authority before an attacker can exploit them.
Sources
- NIST Post-Quantum Cryptography project (FIPS 203/204/205, HQC): csrc.nist.gov
- NIST IR 8547 (draft), Transition to Post-Quantum Cryptography Standards: csrc.nist.gov
- NIST NCCoE, Migration to Post-Quantum Cryptography project: nccoe.nist.gov
- NSA, post-quantum cryptography measures announcement (October 1, 2026): nsa.gov
- Cloudflare, post-quantum cryptography documentation: developers.cloudflare.com
- Ethereum Foundation, post-quantum Ethereum: pq.ethereum.org
Keep going
New to the threat? Start with What Is Q-Day?
Continue the series:
- Post-Quantum Cryptography: A Plain-English Guide
- How to Protect Your Crypto From Quantum Computers
- Which Cryptocurrencies Are Quantum-Resistant?
Browse all post-quantum cryptography guides.
This article is educational and does not constitute security or investment advice.