The post quantum cryptography migration is beginning before a quantum computer can break today’s internet encryption because cryptography is not a switch that can be flipped overnight. Large organizations may need years to discover every use of encryption, replace aging software and hardware, coordinate vendors, test compatibility and deploy updates safely. For data that must remain secret for decades, waiting for a proven cryptographically relevant quantum computer could mean waiting too long.

This is not a prediction that existing encryption has suddenly failed. No publicly demonstrated quantum computer is known to be capable of breaking widely deployed RSA or elliptic-curve cryptography at useful scales. The transition is instead an exercise in risk management: prepare for a plausible future capability while reducing the operational danger of an eventual rushed replacement.

Why quantum computing changes public-key security

Much of modern digital trust depends on public-key cryptography. RSA and elliptic-curve cryptography are used in systems that establish secure connections, authenticate software updates, protect virtual private networks, verify digital signatures and secure financial and government services.

A sufficiently capable fault-tolerant quantum computer could use Shor’s algorithm to solve the mathematical problems that underpin RSA and widely used elliptic-curve systems. That would put at risk both encrypted communications and signature schemes based on those families of algorithms.

Symmetric cryptography is affected differently. Algorithms such as AES are not expected to be broken in the same way. Grover’s algorithm could, in principle, reduce the effective brute-force search effort against symmetric keys, which is one reason security planners commonly consider larger key sizes for long-term protection. The practical implications depend on the algorithm, key length and assumptions about future quantum machines; it is not a blanket case for replacing every form of encryption.

The immediate threat is data that can be saved

The most frequently cited reason to move early is known as harvest now, decrypt later. An adversary does not need a quantum computer today to collect encrypted traffic, databases or files. They can retain material that may become readable if relevant public-key protections are broken in the future.

That matters where confidentiality has a long shelf life: health information, trade secrets, government records, legal documents, research data, critical-infrastructure plans and some financial archives. It can also matter for encrypted communications whose value is not obvious when captured. An intelligence target, a corporate negotiation or a scientific result may be far more sensitive years later than it appears at the moment of transmission.

Integrity creates a related problem. If a future attacker can forge signatures protected by vulnerable public-key systems, software distribution, identity systems and archived signed records could require renewed verification or replacement. The priority will differ by organization, but the useful question is not simply, “When will quantum computers arrive?” It is, “How long must this information and this trust relationship remain protected?”

A cryptographic inventory is the first migration task

Before selecting quantum-resistant encryption, organizations need to know where their existing cryptography lives. That is harder than it sounds. Cryptographic functions are embedded in web services, TLS libraries, VPNs, certificates, authentication systems, mobile applications, backups, developer tools, cloud services, smart devices and industrial equipment. In many cases, a company uses encryption indirectly through a supplier’s product or an open-source dependency.

A useful cryptographic inventory maps more than algorithm names. It should identify:

• the systems, protocols and applications using cryptography;
• the algorithms, key sizes, certificate types and cryptographic libraries involved;
• where keys are generated, stored, rotated and controlled;
• the data classification and required confidentiality or integrity lifetime;
• the owners, vendors and contractual dependencies attached to each system; and
• whether a component can be updated, reconfigured or replaced.

This work supports what security agencies have broadly urged: treat the shift as an enterprise planning problem rather than a narrow algorithm upgrade. It also reveals a central constraint. An organization cannot migrate what it cannot locate, and it cannot prioritize what it has not classified.

NIST standards give the transition a common foundation

Standardization has made planning more concrete. In August 2024, the U.S. National Institute of Standards and Technology finalized its first three post-quantum cryptography standards: FIPS 203 for ML-KEM, a mechanism for establishing shared keys; FIPS 204 for ML-DSA, a digital-signature algorithm; and FIPS 205 for SLH-DSA, a hash-based signature scheme.

ML-KEM, derived from the previously named CRYSTALS-Kyber, is designed for key establishment rather than directly encrypting large files. ML-DSA, derived from CRYSTALS-Dilithium, provides signatures. SLH-DSA offers a different, hash-based design and can be relevant where algorithmic diversity is valuable, though its signatures are generally much larger than those of ML-DSA.

The NIST post-quantum standards are an important baseline, not a plug-and-play answer. A standard specifies an algorithm and its approved parameters; real adoption requires protocol support, implementation review, operational testing and coordinated upgrades across the systems that exchange cryptographic messages.

Compatibility, not mathematics, may be the hard part

Post-quantum algorithms have different performance and size characteristics from the public-key schemes they may replace. Public keys, ciphertexts and signatures can be substantially larger. That can affect handshake messages, certificate chains, bandwidth-constrained links, memory-limited embedded devices and systems built around fixed packet sizes or rigid storage assumptions.

Certificates illustrate the broader challenge. Replacing a signature algorithm can involve certificate authorities, browsers, operating systems, device firmware, enterprise trust stores and every service that validates the resulting chain. A VPN or TLS upgrade may depend on support in servers, clients, load balancers, inspection tools, hardware security modules and managed cloud products. One unsupported component can constrain the entire path.

For this reason, early deployments may use hybrid approaches that combine a conventional method with a post-quantum one, where protocols and products support them. Hybrid designs can provide a staged route while ecosystems mature, but they also add complexity and must be assessed for the specific protocol rather than treated as an automatic safeguard.

Implementation mistakes can defeat a sound algorithm

Choosing ML-KEM or ML-DSA does not guarantee a secure migration. Cryptographic implementation has familiar failure modes: weak randomness, incorrect parameter handling, side-channel exposure, flawed protocol integration, insecure key storage, incomplete certificate validation and unpatched libraries. New algorithms may introduce new coding paths, unfamiliar operational tooling and immature integrations.

Updateability is therefore a security requirement. A device expected to operate for many years should have a credible, authenticated path for changing cryptographic software or configuration. Otherwise, a product deployed as “quantum ready” may become stranded by a future standard revision, vulnerability or interoperability change.

Why waiting creates its own risk

Governments are already translating planning into procurement and modernization expectations. The U.S. National Security Agency’s CNSA 2.0 guidance, for example, sets transition expectations for national-security systems over the coming decade. Other public-sector agencies and standards bodies have encouraged inventories, risk assessment and early testing. Exact requirements vary by jurisdiction and sector, but the direction is clear: cryptography migration is entering normal infrastructure planning.

Private organizations face similar realities. Hardware refresh cycles can span years. Industrial and medical devices may remain deployed far longer. Software supply chains are global, and vendors will not all add support at the same pace. Testing must fit alongside reliability, compliance and business continuity requirements. Starting now creates room to find failures when they are inconvenient rather than catastrophic.

Post-quantum readiness is an ongoing capability

The durable lesson is that post-quantum cryptography migration is not a one-time replacement of RSA with a new acronym. It is a move toward cryptographic agility: the ability to identify cryptography, understand its business role, update it safely and govern changes across internal systems and suppliers.

Quantum computing cybersecurity is often framed as a race against a distant machine. In practice, the urgent work is much more ordinary: asset management, software maintenance, procurement discipline, key management and careful interoperability testing. Those are slow tasks, which is precisely why the migration has begun before the feared quantum computer is ready.

Image by Miller_Eszter on Pixabay.