Companies are aware of the risks posed by quantum computers and are making an inventory of all the areas where they use encryption. At the same time, they are updating vulnerable algorithms such as RSA and ECC with new post-quantum cryptography standards. Besides, they are developing ‘crypto-agility’ to allow quick algorithm switching whenever necessary. Largely because the U.S. National Institute of Standards and Technology (NIST) is expected to publish its initial post-quantum encryption standards in 2024, this has been why encouraging a change from theory to practice in the past couple of years.
The reason for this urgency is quite straightforward: a quantum computer with enough qubits running Shor’s algorithm would be capable of breaking the public-key cryptography that secures almost all forms of internet communications, online banking, and stored data at the moment. Nobody can say for sure when such a computer will be available – some speculate the early 2030s while others think it might never happen – Yet, the danger already exists in the form which security experts term ‘harvest now, decrypt later.’ In other words, potential enemies are able to collect encrypted data at present and then decrypt it years later when their hardware is good enough. So, if there is any piece of information that is supposed to remain confidential for a certain long period of time, let’s say 10 years, then, the deadline for the implementation of quantum-resistant cryptography has already passed.
Why Current Encryption Is Vulnerable to Quantum Computers
The majority of the security systems that keep the internet running rely on math problems that classical computers cannot solve for a very long time. For example, if a conventional computer were asked to factor a 2048-bit RSA key, it would need more time than the age of the universe. The entire system depends on this asymmetry being permanent.
But, quantum computers break the assumption. Shor’s algorithm, which was created in 1994, can factor large numbers and solve the discrete logarithm problem much faster than any classical methods. So RSA elliptic-curve cryptography, and Diffie-Hellman key exchange all become vulnerable once the quantum hardware is capable of being several thousand stable logical qubits, a number often cited. Currently, quantum computers are at a stage of a few hundred noisy physical qubits, but error correction and scaling improvements are at a level that security experts can no longer ignore.
Symmetric encryption, such as AES, remains quite resistant. Grover’s algorithm is the principal quantum attack against it and it only reduces the effective key strength by a factor of two. That means, using a doubled key size (from AES-128 to AES-256) compensates for the loss. The major vulnerability is in the public-key infrastructure that, among other things, handles authentication and key exchange, this is actually the part that protects data in transit and verifies identity.
What a Quantum Migration Actually Involves
The initial concrete action almost every company does is to create a cryptographic inventory, and it is usually a much harsher reality than expected. Encryption is all over the place: TLS certificates, VPNs, code-signing pipelines, email gateways, hardware security modules, IoT firmware, payment systems, and vendor integrations that no one has documented in years. Companies regularly uncover thousands of certificates and dozens of cryptographic libraries they had completely forgotten about. You can’t migrate what you don’t see.
After having the inventory, teams determine priorities based on data lifespan and risk. Health records, legal contracts, government data, intellectual property, and anything with regulatory retention requirements are the main focus because their secrecy needs to be maintained even after the arrival of quantum hardware. NIST’s finalized standards (ML-KEM, formerly Kyber, for key exchange and ML-DSA, derived from Dilithium, for digital signatures) provide engineers specific points to aim at for migration. Many companies are actually deploying these with hybrid mode first, meaning classical algorithm together with a post-quantum one so that if either is flawed, there is still a backstop.
The aspect that gets the least attention is the timeline. Previous cryptographic transitions, for example, the switch from SHA-1, took around ten years to become mature in the entire ecosystem. A full enterprise migration is by far the norm of five to ten years given the extent of legacy system use, the existence of embedded devices that usually have a very long replacement cycle, and reliance on third-party software that the business does not control.
How the Threat Differs Across Industries
Not all industries are racing against the same timeline. The financial services, defense, and healthcare sectors experience the greatest risk, as they not only deal with data that needs to be protected for a very long time but are also heavily regulated by authorities. And, many of these sectors have already started running pilot migrations instead of waiting. Banks, in particular, have serious concerns about the accuracy of transactions and the confidentiality of customer records over a period of decades.
Telecommunications and cloud providers have a different type of challenge. They are responsible for the fundamental infrastructure that the entirety of the rest of the world relies on. So the migration decisions they make have a broad impact, and several major cloud platforms have started offering post-quantum cryptography options as part of their key management and TLS services. Manufacturing and critical infrastructure, however, deal with a more complex physical problem. The truth is, industrial controllers and embedded systems generally remain in use for fifteen to twenty years, which is much longer than the software they operate on.
Smaller businesses often assume this is somebody else’s problem, and for the most part they are partly right, since they rarely operate their own cryptographic stack. Their real exposure flows through vendors. The practical move for a mid-sized company is less about rebuilding encryption and more about asking suppliers, SaaS platforms, and payment processors what their post-quantum roadmap looks like, then weighing that into procurement decisions. Organizations that want a structured assessment of their exposure and a phased migration plan increasingly bring in specialists, and resources like The Quantum Insider help connect them with consulting expertise that maps the threat to their specific systems.
Building Crypto-Agility for an Uncertain Timeline
Most teams’ smartest preparations these days don’t involve a single algorithm commitment so much as designing systems that are capable of switching algorithms without the need for a complete rebuild. This is what we call crypto-agility, and it’s important because the post-quantum encryption standards are still evolving. For one thing, SIKE one of the algorithms that was among NIST’s candidates for a while, got broken by a classical computer in 2022 after it was studied for years, which is a valuable reminder that the “safe” choice of today might not stay safe forever.
The bottom line is that crypto-agility means hiding cryptographic functions behind well-defined interfaces, managing certificates and keys centrally instead of embedding choices into individual apps, and making certificate rotation automatic so changing algorithms becomes just a matter of configuration rather than making new code. It also entails building adaptability into vendor agreements and keeping track of the different government and industry timelines because a number of regulators have indicated very long-term migration expectations, possibly till 2030 and beyond.
In fact it may be better to recognize this as risk management in an environment of uncertainty rather than a fire drill with a known date. Having it as a long-term initiative, with someone responsible for it, and properly funded, is far better than waiting to hear about the first cryptographically significant quantum computer. When that point is publicized, the opportunity to protect data that needs to be kept secure will have already been missed and the migration that should have been started years ago will be treated as an emergency rather than a project. The sensible thing in 2026 would be to start the inventory, pose the difficult questions to vendors, and identify the data that absolutely cannot be leaked as the place to begin.
