Post-Quantum Cryptography Is a Migration Project, Not an Algorithm Swap
Table of Contents
- What Actually Breaks
- Harvest Now, Decrypt Later
- The Standardised Replacements
- Larger Keys Break Assumptions
- Hybrid Schemes Hedge the Risk
- Discovery Is the Hardest Step
- Signatures Are Harder Than Encryption
- Cryptographic Agility as the Real Goal
- Common Misconceptions
- Conclusion
- Frequently Asked Questions
Key takeaway: Selecting an algorithm is the easy part. The difficulty is inventorying every use of public-key cryptography across your systems, protocols, hardware, and vendors — much of which is undocumented and some of which cannot be changed.
What Actually Breaks
Precision matters here, because the threat is frequently overstated in both directions.
Broken by a sufficiently capable quantum computer: RSA, Diffie-Hellman, elliptic curve Diffie-Hellman, and elliptic curve signature schemes. All rely on the difficulty of factoring or computing discrete logarithms, and Shor’s algorithm solves both efficiently. This means public-key encryption, key exchange, and digital signatures as currently deployed.
Weakened but manageable: symmetric encryption and hash functions. Grover’s algorithm provides a quadratic speedup for brute-force search, which effectively halves the security level. A 256-bit symmetric key retains adequate strength; a 128-bit key becomes marginal. Doubling key lengths addresses this, and it is a much smaller problem.
Unaffected: the structure of most protocols, symmetric algorithm designs themselves, and the majority of cryptographic engineering practice.
So the scope is public-key cryptography specifically. That is still enormous — it underpins every TLS connection, code signing system, certificate authority, VPN, SSH session, encrypted messaging protocol, and blockchain signature scheme in use.
The practical framing: everything that establishes a shared secret with a party you have not met, or that proves a message came from a specific source, needs replacing. Everything that encrypts bulk data with an already-shared key mostly needs a longer key.
Harvest Now, Decrypt Later
The reason this is urgent despite the hardware being distant.
An adversary with storage capacity can record encrypted traffic today and retain it. When capable quantum computers become available, they decrypt the archive. The encryption you use today protects data against today’s adversaries and does not protect it against a future one who kept a copy.
This makes the relevant question not “when will quantum computers arrive” but “how long must this data stay confidential.”
The arithmetic is straightforward. If your data requires twenty years of confidentiality, and cryptographically relevant quantum computing arrives in fifteen, then data encrypted today is exposed five years before its protection requirement expires. Migration needed to happen already.
Categories where this matters most: government and diplomatic communications, medical records, financial and legal records with long retention requirements, intellectual property, and anything whose disclosure remains damaging decades later.
Categories where it matters less: session data with no lasting value, ephemeral communications, and information that becomes public shortly anyway.
The asymmetry is worth noting. Signatures are less affected by this threat model, because a signature verified today cannot retroactively be forged by a future computer — the signature was valid when checked. What matters for signatures is the validity period going forward, which makes long-lived certificates and firmware signing keys the concern rather than transient authentication.
The Standardised Replacements
Standardisation has completed for the primary algorithms, which removes the main obstacle that existed for years.
Lattice-based key encapsulation. The primary recommendation for key establishment. Security rests on the difficulty of problems in high-dimensional lattices. Performance is good — comparable to or faster than elliptic curve operations — and key and ciphertext sizes are larger.
Lattice-based signatures. The general-purpose signature recommendation. Reasonable performance, larger signatures and public keys than elliptic curve equivalents.
Hash-based signatures. Security rests only on hash function properties, which is the most conservative assumption available. Signatures are large and some variants are stateful, meaning key reuse is catastrophic — a serious operational hazard. Suited to firmware signing where signature count is low and conservatism matters.
Alternative-family signatures. Additional schemes based on different mathematical assumptions, standardised specifically so that a break in lattice mathematics does not leave the field without options.
The diversity of mathematical foundations is deliberate. Lattice problems are believed hard and less studied than factoring, which has received centuries of attention. Maintaining alternatives based on unrelated assumptions is prudent given that history includes post-quantum candidates broken during the standardisation process itself.
That history is worth remembering: several proposed schemes were broken by classical attacks while under evaluation. The surviving algorithms have been examined intensively and the field is younger than classical public-key cryptography, which argues for hybrid deployment rather than wholesale replacement.
Larger Keys Break Assumptions
The practical difficulty most likely to cause implementation problems.
Post-quantum keys, ciphertexts, and signatures are substantially larger than their elliptic curve equivalents — in some cases by an order of magnitude or more. This breaks assumptions embedded throughout deployed systems.
Where the size increase causes problems:
Protocol message limits. Handshakes designed around small keys may exceed message size limits or require additional round trips, which adds latency.
Packet fragmentation. A handshake message that previously fitted in one packet may not. Fragmentation interacts badly with some network middleboxes.
Embedded device memory. Devices with tight memory budgets may be unable to hold the larger keys and intermediate values. This is a hard constraint rather than an optimisation.
Certificate sizes. Certificate chains grow substantially, which affects TLS handshake size and storage.
Blockchain and ledger systems. Where signatures are stored permanently, larger signatures mean permanently larger storage and higher transaction costs.
Firmware storage. Signature verification code and larger keys must fit in constrained boot regions.
Bandwidth-constrained links. Satellite, cellular IoT, and industrial protocols where every byte matters.
The embedded case is the most difficult. A device with limited memory, deployed for a fifteen-year service life, that cannot be updated, and that will still be operating when quantum computers arrive, has no migration path. The only answer is to replace the hardware, which for infrastructure deployments means a capital programme rather than a software update.
Hybrid Schemes Hedge the Risk
The approach that manages the genuine uncertainty about post-quantum algorithm security.
A hybrid scheme performs both a classical and a post-quantum key exchange, then combines the results so that the derived key depends on both. Breaking the session requires breaking both.
The properties this provides: security holds if the classical algorithm remains unbroken, which protects against a flaw in the newer post-quantum mathematics. Security also holds if the post-quantum algorithm remains unbroken, which protects against quantum attack on the classical one. And deployment can proceed now without betting entirely on algorithms with less analytical history.
The cost is additional computation and message size, which is modest for key exchange and more consequential for signatures.
Hybrid key exchange has seen substantial real-world deployment already, notably in browsers and messaging protocols, which means the interoperability questions have largely been worked through for that case.
Hybrid signatures are more awkward. Two signatures means roughly double the size, and signature size is already the main post-quantum problem. Practice here is less settled, and for many applications a single post-quantum signature is the likely path with the classical one retained during a transition period.
The reasonable position: hybrid for key exchange now, since the cost is low and the hedge is valuable. For signatures, plan the transition and be more selective about hybrid deployment given the size cost.
Discovery Is the Hardest Step
Everything above assumes you know where cryptography is used in your systems. Most organisations do not, and finding out is the largest portion of the work.
Where public-key cryptography hides:
TLS termination points. Load balancers, reverse proxies, CDNs, service meshes, and application servers. Each may have its own configuration.
Certificate infrastructure. Internal certificate authorities, certificate stores, and every service validating certificates.
Code and artefact signing. Software releases, container images, packages, and firmware.
Authentication tokens. Signed tokens, session assertions, and federation protocols.
Database and storage encryption. Where key management uses public-key operations.
VPN and remote access. Every tunnel and its key exchange.
Secure boot chains. Frequently keys burned into hardware, which cannot be changed.
Hardware security modules and secure elements. Which support specific algorithms in firmware.
Vendor and SaaS dependencies. Their migration timeline becomes yours.
Embedded and operational technology. Industrial controllers, medical devices, vehicles, and sensors, frequently with long lifespans and limited update capability.
Payment and smart card systems. With their own standards processes and hardware constraints.
Building this inventory is unglamorous and it is the prerequisite for everything else. Automated network scanning identifies cryptography in use on the wire; code scanning finds library calls; and neither finds what a vendor does internally or what is baked into a hardware root of trust.
The output that matters is a list of systems ranked by the confidentiality lifetime of the data they protect and by their update capability. Systems with long-lived data and no update path are where the programme should start, because they are the ones requiring hardware replacement on a long lead time.
Signatures Are Harder Than Encryption
An asymmetry worth understanding, because it affects sequencing.
Key exchange migration is comparatively tractable. Both endpoints negotiate per connection, hybrid schemes work well, deployment can be incremental, and a session established today does not constrain tomorrow’s choices.
Signature migration is harder for structural reasons. Signatures on long-lived artefacts — firmware, certificates, archived documents — must remain verifiable for years, which means verifiers must support the algorithm for as long as the artefact matters. Root keys in hardware cannot be changed. Certificate hierarchies require the whole chain to migrate coherently. And verification code in constrained environments must be updated, which is precisely where updating is difficult.
The specific hazard is a secure boot chain with a root key in hardware. That key validates the firmware that validates everything else. If it uses an algorithm that becomes breakable, the device’s entire trust foundation fails and there is no software remedy — the key is physically fixed.
Which is why devices being designed now, for deployment lifetimes extending decades, need post-quantum-capable roots of trust in their initial silicon. That decision cannot be deferred, because the hardware is the constraint.
Cryptographic Agility as the Real Goal
The lasting value of this migration is not the specific algorithms adopted. It is building systems where algorithms can be changed.
Properties that constitute agility: algorithm identifiers in protocols and stored formats, so what was used is recorded and can be distinguished. Negotiation mechanisms rather than hardcoded choices. Abstraction layers so application code does not embed algorithm assumptions. Key formats and storage that accommodate varying sizes. Certificate infrastructure supporting multiple algorithms simultaneously. And an update path for every component performing cryptographic operations.
The argument for building this regardless of quantum computing: algorithms are periodically deprecated for entirely classical reasons. Hash functions have been broken. Cipher modes have been found flawed. Key sizes have become inadequate as computing improved. Each transition has been painful in systems that assumed one algorithm forever.
An organisation that completes post-quantum migration by building agility has acquired something durable. One that completes it by hardcoding the new algorithms has performed the same painful work it will need to repeat.
That reframing also helps with justification. Agility is defensible on general engineering grounds without requiring anyone to agree on a quantum computing timeline.
Common Misconceptions
“Quantum computers can break everything.” Public-key cryptography, yes. Symmetric encryption is weakened and manageable with longer keys.
“There is time because the hardware is distant.” For data requiring long confidentiality, recorded traffic decrypted later means the deadline has already passed.
“It is just changing an algorithm.” Larger keys break protocol and memory assumptions, discovery is a major project, and some hardware cannot be updated.
“Post-quantum algorithms are proven secure.” Believed secure, standardised after extensive review, and based on younger mathematics than factoring. Several candidates were broken during evaluation.
“Blockchains are quantum-proof.” They depend on elliptic curve signatures, which Shor’s algorithm breaks. Migration is a governance problem there as much as a technical one.
“Quantum key distribution is the answer.” It addresses key exchange over dedicated links with specific hardware and does not solve signatures or general deployment. Post-quantum algorithms are the practical path.
Conclusion
The algorithms are standardised, which removes the obstacle that justified waiting. What remains is a migration project whose difficulty lies in discovery rather than in cryptography.
The urgency comes from the harvest-now-decrypt-later threat: traffic recorded today is decrypted whenever capable machines arrive, which makes the deadline a function of your data’s confidentiality lifetime rather than of the hardware timeline. For long-lived data, that deadline has already passed.
Start with the inventory, because you cannot migrate what you have not found — and public-key cryptography hides in load balancers, certificate stores, signing pipelines, hardware roots of trust, and vendor systems whose timelines become yours. Rank by data confidentiality lifetime and by update capability, because systems with long-lived data and no update path require hardware replacement on long lead times.
Deploy hybrid key exchange now, since the cost is low and it hedges against flaws in newer mathematics. Sequence signature migration carefully, because long-lived artefacts and hardware roots of trust are the genuinely hard cases.
And build for agility rather than for these specific algorithms. Algorithms get deprecated for classical reasons too, and the organisation that emerges from this with changeable cryptography has gained something that outlasts the quantum question.
Frequently Asked Questions
Is symmetric encryption safe from quantum attack? Substantially. Grover’s algorithm effectively halves the security level, so 256-bit keys remain adequate and 128-bit keys become marginal. Doubling key length addresses it.
Why migrate now if the hardware is years away? Recorded encrypted traffic can be decrypted later. If your data must stay confidential longer than the time until capable machines exist, today’s encryption is already insufficient.
Are the standardised algorithms definitely secure? Believed secure after extensive review, and based on mathematics younger than factoring. Several candidates were broken during standardisation, which is why hybrid deployment and algorithm diversity are recommended.
What makes larger keys a problem? Protocol message limits, packet fragmentation, constrained device memory, certificate chain sizes, and permanent storage in ledger systems. Embedded devices with fixed memory are the hardest case.
Should hybrid schemes be used? For key exchange, yes — low cost and it hedges against flaws in either algorithm family. For signatures, more selectively, because doubling signature size compounds the main post-quantum problem.
Where should a migration programme start? Inventory, then prioritise by data confidentiality lifetime and update capability. Long-lived data on systems that cannot be updated needs the earliest attention because it requires hardware replacement.
Does quantum key distribution replace post-quantum algorithms? No. It addresses key exchange over dedicated physical links with specialised hardware. It does not address signatures or general internet deployment, which is what post-quantum algorithms are for.
