The short version
A sufficiently large quantum computer running Shor’s algorithm breaks RSA, Diffie-Hellman, and every elliptic-curve scheme in use today. Nobody has built one. But the replacements are standardized, the deprecation dates for the old algorithms are published, and the first half of the migration is already happening in your browser without you noticing.
The migration is really two migrations with very different urgency:
| Key exchange and encryption | Digital signatures and PKI | |
|---|---|---|
| Threat | Harvest now, decrypt later. Traffic recorded today is readable the day a quantum computer exists. | Forgery, but only once a quantum computer exists. Nothing recorded today becomes forgeable later. |
| Urgency | Now, for anything whose confidentiality must outlast the next decade. | Driven by deadlines and lead time, not by an active threat. |
| Difficulty | Low. Hybrid key exchange is a configuration change in modern TLS. | High. Touches roots, HSM firmware, every relying party, hardware tokens, and protocols with no room for bigger keys. |
| Status | Default in major browsers, Cloudflare, OpenSSL 3.5, iMessage, Signal. | Standards finished; ecosystem deployment at the pilot stage. |
If you take one thing from this guide: turn on hybrid post-quantum key exchange wherever your software already supports it, and start the signature migration with an inventory, because the inventory is the step that takes years.
What is standardized
NIST published the first three post-quantum standards on August 13, 2024. They are final, they are what every vendor is implementing, and they are what FIPS 140-3 validations now cover.
| Standard | Algorithm | Role | Replaces | Public key | Signature or ciphertext |
|---|---|---|---|---|---|
| FIPS 203 | ML-KEM (Kyber) | Key encapsulation | ECDH, RSA key transport | 1,184 bytes at level 3 | 1,088 bytes |
| FIPS 204 | ML-DSA (Dilithium) | General-purpose signatures | ECDSA, RSA signatures | 1,952 bytes at level 3 | 3,309 bytes |
| FIPS 205 | SLH-DSA (SPHINCS+) | Conservative signatures, hash-based | Same, where you want a different mathematical basis | 32 bytes | 7,856 bytes at level 3, small variant |
| SP 800-208 | LMS and XMSS | Stateful hash-based signatures for firmware and code signing | RSA, ECDSA in long-lived devices | Small | 1 to 5 kilobytes |
For comparison, an ECDSA P-256 public key is 64 bytes and a signature is 64 bytes. The post-quantum equivalents are twenty to fifty times larger. That one fact drives most of what breaks later in this guide.
Two more are coming: FN-DSA (Falcon), a compact signature scheme with a difficult implementation, and HQC, selected in 2025 as a backup key encapsulation mechanism built on different mathematics than ML-KEM. Plan on ML-KEM and ML-DSA. Treat the others as options for specific constraints.
The deadlines
Two documents set the schedule for anyone operating in or selling to the United States, and most of the world follows them.
NIST IR 8547 lays out the transition for federal systems and, in practice, for everyone who follows FIPS: RSA and elliptic-curve algorithms at the 112-bit security level, which means RSA-2048 and P-256, are deprecated after 2030 and disallowed after 2035. Quantum-vulnerable algorithms of every strength are disallowed after 2035.
CNSA 2.0, the NSA’s suite for national security systems, is more aggressive and names specific algorithms: ML-KEM-1024, ML-DSA-87, LMS and XMSS for firmware, AES-256, and SHA-384 or SHA-512. Its milestones:
| System type | Support and prefer PQ by | Exclusively PQ by |
|---|---|---|
| Software and firmware signing | 2025 | 2030 |
| Web browsers, servers, cloud services | 2025 | 2033 |
| Traditional networking equipment | 2026 | 2030 |
| Operating systems | 2027 | 2033 |
| Niche equipment | 2030 | 2033 |
| Custom applications and legacy equipment | Updated or replaced by 2033 |
If you sell to the US government or its suppliers, these dates are already in procurement language. If you do not, they are still the best available signal of when your vendors will ship and when auditors will start asking.
Where it is already happening
The key exchange half of the migration moved faster than almost anyone predicted, because TLS 1.3 made it cheap.
- Chrome, Firefox, Edge, and Safari all negotiate a hybrid of X25519 and ML-KEM-768 by default. A large share of the encrypted web traffic in the world is already post-quantum protected on the wire.
- Cloudflare, and therefore this website, terminates TLS with hybrid post-quantum key exchange by default. If you are reading this in a current browser, this page was delivered under a key agreement a quantum computer cannot break.
- OpenSSL 3.5, released April 2025 as a long-term-support version, includes ML-KEM, ML-DSA, and SLH-DSA and enables hybrid key exchange groups by default. Anything that links against it inherits the capability when upgraded.
- OpenSSH defaults to a hybrid post-quantum key exchange and has for some time.
- Apple’s iMessage and Signal both re-keyed their messaging protocols with ML-KEM in 2024 and 2023 respectively.
The lesson is that the hybrid approach works. A hybrid combines a classical algorithm with a post-quantum one so the connection is safe unless both are broken. It costs a few extra kilobytes per handshake and removes the argument for waiting.
Why PKI is the hard part
Signatures are where the sizes bite and where the dependencies pile up.
Certificate chains get big. A TLS handshake today carries two or three certificates and a handful of signatures, perhaps four kilobytes in total. With ML-DSA throughout, the same chain is twenty to thirty kilobytes. Every handshake, every connection. For most servers that is tolerable. For constrained devices, satellite links, and anything that fits in a single packet today, it is not. The browser vendors are experimenting with alternatives, including Merkle Tree Certificates, precisely because of this.
Middleboxes break. Firewalls, load balancers, and inspection appliances that assume a ClientHello fits in one packet, or that a certificate is smaller than some buffer, fail in surprising ways. This is already observable with hybrid key exchange, where the larger ClientHello has broken some devices. It will be worse with signatures.
Hardware security modules need new firmware and new validations. The major HSM vendors shipped firmware with ML-KEM and ML-DSA in 2025. Whether the specific firmware in your rack is FIPS-validated for those algorithms, and whether your HSM generation can run it, is a question only your vendor can answer. Roots and issuing CA keys live in these devices, so this is on the critical path.
Hardware tokens and smart cards. Smart cards, YubiKeys, TPMs, and secure elements have fixed cryptographic capabilities. A post-quantum signature is larger than the message buffer on many of them. Expect a hardware refresh, and expect it to take years for a large fleet.
Roots of trust in long-lived devices. A device shipping today with a ten-year service life and an RSA root of trust burned into it will still be verifying RSA signatures in 2036. This is why CNSA 2.0 puts firmware signing first, and why stateful hash-based schemes exist: they are the conservative choice for a root you can never change.
Stateful signatures need state. LMS and XMSS are secure only if a private key never signs twice with the same internal state. That is a straightforward requirement in an HSM with proper controls and a disaster in a backup-and-restore workflow that was designed for RSA. If you adopt them for firmware signing, the operational controls are the hard part, not the math.
Protocols with no room. S/MIME, document signing, DNSSEC, and some industrial protocols either have fixed-size fields or performance budgets that post-quantum signatures blow through. Each has a working group. None is finished.
The Web PKI itself. No public certificate authority issues post-quantum certificates for public TLS yet, and browsers do not trust any. That will change, but the shape of it, pure ML-DSA, composite certificates, or a new structure entirely, is still being decided. Private PKI does not have to wait.
What to do about it
Seven phases. The first two are where organizations fall behind, because they are unglamorous and nobody owns them.
1. Build a cryptographic inventory
You need to know every place your organization uses cryptography, what algorithm and key size, what protects it, and who owns it. Certificates are the visible tip. The rest is in code, configuration, libraries, protocols, VPN profiles, backup encryption, database encryption, signed firmware, API tokens, and vendor products.
Use a structured format. CycloneDX 1.6 added a Cryptography Bill of Materials, and scanners that produce one exist. Certificate lifecycle platforms give you the certificate layer with discovery across networks and clouds. Application security tools can find algorithm use in source. The combination is your starting point, and it will be incomplete. That is fine. Start.
2. Classify data by how long it must stay secret
The harvest-now-decrypt-later threat has a simple test. For each system that encrypts data in transit or at rest, ask how many years the data must remain confidential. Add the number of years it will take you to migrate that system. If the total exceeds your estimate of when a cryptographically relevant quantum computer arrives, and a decade is a defensible planning number, that system is already late. Health records, financial records, intellectual property, government data, and anything with a legal retention period will land at the top of the list.
3. Turn on hybrid key exchange everywhere it is available
This is the cheapest risk reduction in the program. Upgrade TLS termination points to software with hybrid groups enabled by default. Move public-facing TLS behind an edge or CDN that already negotiates it. Enable it on VPN gateways as vendors ship support. Test the middleboxes in the path first, because that is where it fails.
4. Get roadmaps in writing from vendors
For every HSM, hardware token, CA product, lifecycle platform, VPN, load balancer, and inspection appliance, ask three questions: which post-quantum algorithms are supported today, when the FIPS validation for them is expected, and whether the hardware you own will run that firmware. Put the answers in the inventory. Products without a credible answer go on a replacement list.
5. Design the post-quantum PKI before you need it
Decide now how your private PKI will migrate, because the design choices determine what you buy.
- A parallel hierarchy with a post-quantum root and issuing CAs, run alongside the classical one, lets relying parties move at their own pace. This is the approach most organizations will take.
- Composite certificates carry both a classical and a post-quantum key and signature, so a single certificate works for both old and new verifiers. They are larger still, and the standards are newer.
- Algorithm choice: ML-DSA-65 for general use, ML-DSA-87 where CNSA 2.0 applies, and LMS or XMSS for firmware roots that must never change.
- Where the keys live: post-quantum-capable HSM firmware with the validation you need, and a key ceremony procedure updated for larger keys and, if applicable, stateful signature controls.
Stand up a test CA now. EJBCA has issued ML-DSA certificates since 2024. Microsoft has added the algorithms to its cryptographic libraries and Windows, with AD CS support arriving in stages. Issue certificates, push them at your applications, and find out what cannot parse them. The failures are the plan.
6. Pilot with the systems you control end to end
Internal mutual TLS between services you own, where you control both ends and the network between them, is the ideal first production use of post-quantum certificates. Code signing for internal tooling is a good second. Both exercise your HSMs, your issuance pipeline, and your verifiers without a browser or customer in the loop.
7. Build for agility, because this will happen again
The algorithms being deployed today are young. One of the NIST finalists was broken on a laptop during the competition. Assume a parameter change or an algorithm swap within the lifetime of what you build now. That means no hard-coded algorithm identifiers, no fixed buffer sizes, certificate lifetimes short enough to roll the fleet in weeks, and an inventory that stays current rather than one you rebuilt once for this project. The 47-day certificate change and the post-quantum migration are the same lesson from two directions.
Timeline for a typical enterprise
| When | What should be true |
|---|---|
| Now | Hybrid key exchange on all public TLS. Inventory underway. Data classified by confidentiality lifetime. Vendor roadmaps requested. |
| By end of 2027 | Inventory complete and maintained. HSM firmware and validation path confirmed. Test CA issuing ML-DSA certificates. Hardware token refresh planned. |
| By end of 2029 | Post-quantum private PKI in production for internal mutual TLS and code signing. Firmware signing on LMS or XMSS for long-lived products. Replacement of products with no roadmap underway. |
| By 2030 | RSA-2048 and P-256 retired from new deployments. Remaining classical use documented with an end date. |
| By 2033 to 2035 | Classical public-key cryptography gone from systems you control. |
Questions we get
Should we wait for the Web PKI to settle before touching our private PKI? No. Your private PKI is the part you control, and it is where your longest-lived trust anchors live. The Web PKI will arrive with its own answer and your browsers will handle it. Your firmware signing root will not.
Is hybrid key exchange a permanent answer or a stopgap? A stopgap, deliberately. It protects you if either algorithm is broken, at the cost of a slightly larger handshake. Expect pure post-quantum key exchange to become the default once ML-KEM has a longer track record. Plan for agility rather than for either end state.
Do bigger RSA keys buy time? Not against a quantum computer. Shor’s algorithm scales polynomially, so RSA-4096 falls shortly after RSA-2048. Bigger keys only help against classical attacks, and they make the eventual migration no easier.
What about symmetric encryption and hashing? Grover’s algorithm halves the effective strength of symmetric keys, so AES-128 behaves like a 64-bit key against a quantum adversary. Move to AES-256 and SHA-384 or SHA-512, which is what CNSA 2.0 requires. No algorithm change is needed, only parameter choices.
Our HSMs are three years old. Are they obsolete? Possibly not. Ask the vendor whether your model can run the post-quantum firmware and what the FIPS validation status is. Many current-generation modules can. Older ones cannot, and the lead time on replacements is long enough that you want to know now.
Where we can help
A post-quantum readiness engagement starts with the cryptographic inventory and data classification, confirms your HSM and token path, and produces a sequenced migration plan with a private PKI design you can stand up as a pilot. It is the kind of work that benefits from someone who has run key ceremonies and watched a certificate chain fail in production, because that is where this migration will be won.