What is technically happening to our systems?
Two separate things, running on 2 separate clocks, and conflating them produces a migration plan aimed at the wrong half of the estate.
The confidentiality problem is live today. Anything crossing a network under today’s key exchange can be recorded now and read once a capable machine exists. The damage is retroactive, and the clock started whenever the recording started.
The forgery problem waits for the machine. Certificates, tokens, and signing keys become forgeable the day a quantum computer can recover a private key from its published public key. Nothing can be staged in advance, because the raw material is already public. When it lands, it lands all at once.
The first one prioritizes by how long your data has to stay confidential. The second prioritizes by how long a signature has to remain trustworthy. Those produce different lists.
The short version:
- One kind of cryptography fails, and it’s the public-key kind. RSA, Diffie-Hellman, and elliptic curve are the exposure.
- The symmetric kind survives with larger keys, which is why the same authorities retiring public-key algorithms keep AES-256.
- Confidentiality fails backward, and trust fails forward. Recorded traffic opens retroactively; forged signatures start the day the machine exists.
- Most of the estate is a configuration change. A minority is a hardware purchase, and that minority is most of the budget.
- The replacement messages are bigger, which breaks older equipment in the path and is the most common technical surprise in testing.
- A 2026 analysis of published Nginx configurations found 28.9% specifying a key exchange with no forward secrecy at all, with qualifiers that matter.
What exactly is failing, and what stays standing?
Public-key cryptography rests on 2 problems being slow to solve: factoring a large number into its primes, and the discrete logarithm. Shor’s algorithm, published in 1994, lets a quantum computer solve both efficiently, which recovers the private key directly from the public one.
Source: Peter W. Shor, “Polynomial-Time Algorithms for Prime Factorization and Discrete Logarithms on a Quantum Computer,” SIAM Journal on Computing 26(5), 1997, arXiv:quant-ph/9508027.
Symmetric encryption and hashing have no such structure inside them. The only quantum attack is Grover’s search speedup, which roughly halves effective strength. NIST’s position is that this “does not render cryptographic technologies obsolete,” and that “doubling the key size will be sufficient to preserve security.”
Source: NIST, “Report on Post-Quantum Cryptography,” NISTIR 8105, April 2016, csrc.nist.gov.
Source: CISA, NSA and NIST joint advisory (21 August 2023); NIST IR 8105.
Those 2 directions have different planning consequences, and conflating them is what produces migration plans sequenced in the wrong order. Anything whose confidentiality has to survive is already accruing exposure. Anything whose authenticity has to survive is not yet, and can be sequenced against the machine’s arrival rather than against today.
One planning consequence runs against intuition. Elliptic-curve cryptography falls to a smaller quantum computer than RSA at comparable classical strength, because it needs fewer error-corrected qubits to attack. Migrating from RSA to elliptic curve to buy time runs in the wrong direction.
Source: Martin Roetteler, Michael Naehrig, Krysta M. Svore, Kristin Lauter, “Quantum Resource Estimates for Computing Elliptic Curve Discrete Logarithms,” ASIACRYPT 2017, arXiv:1706.06752.
Where does the vulnerable cryptography actually sit in our estate?
In 5 layers, and 4 of them are invisible to a standard asset inventory.
| Layer | Where it runs | Which threat | What migration means |
|---|---|---|---|
| In transit | Web traffic, VPN tunnels, remote access, API calls between services, encrypted email, file transfers, database connections | Confidentiality, live now | Configuration and library updates on systems you control; a vendor release for everything else |
| At rest | Database and disk encryption, backups, archives, document stores | Confidentiality, through the key-protection chain | The stored data is scrambled with surviving encryption; the keys wrapping it often are not |
| Identity and trust | Server certificates, the internal certificate authority, single sign-on tokens, client certificates, mutual authentication between services | Forgery, on the machine’s clock | Reissuing an entire certificate hierarchy, which is a program rather than a task |
| Code and firmware | Software update signing, firmware signing, container image signing, document signing | Forgery, with the longest tail | Signing keys whose signatures must verify for 15 years are already living on the clock |
| Vendor products | Payment processing, cloud key services, managed network equipment, embedded devices | Both | Waiting on a supplier release, or replacing the product |
The at-rest row is the one most often filed as safe and shouldn’t be. Stored data is normally scrambled with symmetric encryption, which survives. The keys that unlock it are typically wrapped by other keys, and a public-key operation usually appears somewhere in that chain, especially where keys cross a boundary between systems. A copy of encrypted storage that includes the key-protection layer carries the same exposure as recorded traffic.
The code-signing row carries the longest tail in most estates. A firmware image signed today and verified by a device for the next 15 years depends on that signature remaining unforgeable for 15 years, which is a decision being made now with an outcome landing later.
How much of this is a configuration change versus a purchase?
Three tiers, and the cost concentrates in the third.
- Configuration and library updates. Modern software you control, where the migration is updating a cryptographic library, changing settings, and testing. Labor-intensive across a large estate, and technically routine.
- Reissuance and re-encryption. Certificate hierarchies that have to be rebuilt, and stored data whose key-protection chain has to be replaced. Re-encrypting a large archive is a project with its own performance, downtime, and rollback planning.
- Replacement. Equipment with cryptography fixed in hardware or firmware that the manufacturer will never update. Industrial controllers, network appliances, embedded devices, and hardware security modules in this category get replaced rather than migrated, and industrial equipment routinely stays in service for 15 to 20 years.
The U.S. government’s own report names legacy systems with cryptography embedded in hardware or firmware as the most difficult and expensive to migrate, for exactly this reason.
Source: Office of Management and Budget, “Report on Post-Quantum Cryptography,” July 2024, OMB PQC Report.
What breaks during the migration itself?
Size, and it surprises nearly every team in testing.
The replacement algorithms produce substantially larger keys, ciphertexts, and signatures than what they replace. That has 3 practical effects an estate feels immediately:
- Older equipment in the path chokes. Network middleboxes, load balancers, and inspection appliances that assumed a certain handshake size drop connections rather than passing them through. The failure appears as an intermittent connectivity problem rather than an encryption error, which makes it slow to diagnose.
- Constrained links and devices struggle. Low-bandwidth industrial links and small embedded devices have real limits on message size and memory.
- Storage and certificate handling grow. Larger signatures on every certificate in a large hierarchy add up.
The standard interim approach is hybrid, running the old and new algorithms together so the connection is at least as strong as the old one alone and protected against a quantum attack. France and Germany treat hybrid as a standing requirement rather than a transitional step. It also doubles down on the size problem, since both handshakes travel together.
The starting position looks worse than most teams assume, though the evidence needs its qualifiers. A 2026 analysis of Nginx TLS configurations published to public GitHub repositories found 28.9% specifying an RSA key exchange with no forward secrecy at all, which means any recorded session can be reopened later once that server’s long-term key is recovered. The corpus is 8,443 configuration files rather than a scan of live servers, the paper doesn’t state which subset the 28.9% is drawn from, and the authors include a commercial post-quantum vendor and the bank that funded the study.
Source: Balaji et al., “Operationalising Post-Quantum TLS,” arXiv:2605.17955, 2026, arXiv:2605.17955.
Why is the certificate layer the one with the widest consequences?
Because a single broken key at the top of a trust hierarchy compromises everything that ever trusted it.
Certificates work by chaining: your systems trust a small number of root authorities, those roots sign intermediates, and intermediates sign the certificates your services present. Recovering the private key of an authority lets an attacker mint certificates that verify as genuine, for any name they choose, with no defect anybody can detect by inspection.
This has already happened once with no quantum computer involved. In 2011 the Dutch certificate authority DigiNotar was breached, and the attacker minted at least 531 fraudulent certificates, using 1 of them to intercept the email of roughly 300,000 people in Iran. The certificates were mathematically valid, and every browser that saw them displayed a padlock.
Source: Fox-IT, “Black Tulip: Report of the investigation into the DigiNotar Certificate Authority breach,” 2012, Fox-IT Black Tulip report, hosted by ENISA.
The internal version of this in a company is the private certificate authority that authenticates service-to-service traffic, the identity provider that signs single sign-on tokens, and the code-signing key that your fleet accepts updates from. Those 3 are where a forgery capability does the most damage, which is why they tend to lead a sequencing plan even when they hold no sensitive data themselves.
What does this mean for how we sequence the work?
The 2 threats sort the estate differently, and running both sorts is what produces a defensible order.
| Sort by | Question that ranks it | What rises to the top |
|---|---|---|
| Confidentiality lifetime | How many years must this data stay secret? | Long-lived records crossing networks today: intellectual property, communications archives, regulated customer data |
| Trust lifetime | How long must this signature remain unforgeable? | Root and intermediate certificate authorities, identity-provider signing keys, firmware-signing keys |
| Replacement lead time | How long does changing this take? | Hardware with fixed cryptography, and anything on a vendor’s release schedule |
The third sort is the one that decides what starts first in practice, because a 3-year vendor lead time on an item due in 2030 has a start date in 2027 regardless of how it ranks on the other 2.
Questions people ask
Is our data at rest actually at risk? The scrambling survives. The key-protection chain around it frequently contains a public-key operation, and a copy of the storage that includes that layer carries the exposure. This is worth checking rather than assuming either way.
Do we have to replace AES? AES-256 stays in place. AES-128 drops to roughly 64 bits of effective strength under Grover’s algorithm and is worth retiring on its own schedule.
Can we just wait and swap everything at once? The confidentiality half doesn’t allow it, because data crossing the network in the meantime is exposed retroactively. The trust half technically does, and the lead times on certificate hierarchies and hardware make a single coordinated cutover impractical at scale.
What’s crypto-agility, and is it worth funding? It’s the ability to change algorithms through configuration rather than re-architecture. It costs money up front and reduces the cost of every future transition, including ones nobody has anticipated yet.
Does hybrid mean doing the work twice? It means running both algorithms in the same handshake for a period. The migration to the new algorithm happens once, and hybrid is how it’s deployed while the new algorithms accumulate operational track record.
How do we find all of this? A cryptographic inventory at the algorithm level, which is the first step every published mandate names. Standard asset inventories record what software is installed rather than which algorithms it uses. See What should I ask my security team.
Which of these is a quantum computer needed for? All of the breaking. None of the recording, which is why the confidentiality half is described as live today.
Where to go next
- What of our company data is at risk applies the confidentiality sort to your data.
- What can I not fix myself covers the vendor layer.
- What does this cost covers what each tier does to the budget.
- What is technically happening to your data is the individual-scale version of the same mechanism.
- For Business Leaders MOC is the full executive route.
Go deeper into the technical detail
The technical layer: Shor’s Algorithm, Harvest Now, Decrypt Later (HNDL), Forge-Later Attack, PKI Collapse, Crypto-Agility, and PQC Performance and Size Overhead.
These open the Post-Quantum Field Guide, a separate site written for security professionals.
Last verified 2026-07-30 · Maintained by Addie LaMarr, LaMarr Labs.