Shor’s algorithm factors large integers in polynomial time on a fault-tolerant quantum computer, so any public-key scheme whose security rests on that problem loses its guarantee once such a machine exists.
Current devices sit far below the threshold. They hold a few hundred noisy qubits and cannot yet run the error-corrected circuits Shor’s method requires. The gap is not merely one of scale; every added logical qubit demands thousands of physical qubits for correction, and gate fidelities must improve by another order of magnitude before the overhead becomes practical.
Limits of the Threat Model
Grover’s algorithm supplies only a quadratic speedup for symmetric-key search. Doubling key lengths from 128 to 256 bits restores the original security margin against that attack. The concrete decision is therefore narrow: organisations that rely solely on AES-256 or equivalent symmetric primitives face no structural break, only a modest performance tax if they later choose longer keys.
Asymmetric schemes split into two groups. RSA, finite-field Diffie-Hellman, and elliptic-curve systems fall to Shor. Lattice-based, hash-based, and certain code-based candidates do not. Standardisation bodies have already selected Kyber and Dilithium for key encapsulation and signatures precisely because their hardness assumptions survive known quantum attacks.
Migration Trade-offs
Replacing every RSA or ECC certificate is an engineering project, not a cryptographic one. The dominant costs are inventory, testing, and interoperability rather than raw computation. New lattice schemes produce larger public keys and signatures; on constrained devices the increase can force protocol redesign or hardware upgrades. Where bandwidth is abundant and devices are general-purpose servers, the overhead stays within a factor of two to three for most workloads.
Hybrid deployments let operators run classical and post-quantum algorithms in parallel during transition. That approach adds negligible risk and buys time to measure real performance before committing to a single replacement.
Concrete Next Actions
Map every system that performs public-key operations and tag those whose data must remain confidential for more than a decade. Those are the first candidates for hybrid key exchange. Update procurement language to require algorithm-agility so future swaps do not repeat the full inventory cycle. Test one or two NIST-selected candidates in a non-critical service to collect latency and packet-size data under your actual traffic mix.
Once that data exists, the remaining choice is budgetary and operational rather than theoretical: schedule replacement on the same cadence used for other cryptographic library upgrades.