The first obstacle to post-quantum cryptography does not look like a futuristic computer. It is an old network appliance, a forgotten library in a business application, a certificate that has been renewed automatically for years. To prepare their systems for a machine capable of breaking some of today’s mechanisms, businesses must begin with an almost archaeological investigation: where is their cryptography hiding? As of September 2026, this undertaking can be described without predicting an imminent catastrophe. The standards exist; deploying them marks the start of a lengthy transformation. Here are the established foundations and the challenges ahead.
The threat does not have to be imminent to matter
A sufficiently powerful, error-corrected quantum computer could use Shor’s algorithm to compromise the mathematical foundations of RSA and elliptic-curve cryptography. These mechanisms are used, among other things, to establish secrets and sign documents, certificates or software. This is therefore not just about protecting a few sensitive files: part of the foundation of digital trust is at stake.
This does not mean that quantum machines capable of carrying out these attacks at scale are available. Announcements of hardware advances are not enough to demonstrate an operational decryption capability. The timing of that turning point remains uncertain. But this uncertainty is no reason to postpone indefinitely a migration affecting systems sometimes designed to operate for several decades.
The problem is particularly tangible for information that must remain confidential over the long term. An adversary can record encrypted exchanges today in the hope of decrypting them later: the “harvest now, decrypt later” scenario. Medical records, trade secrets or certain sensitive government communications can retain their value long after the servers that carried them have been replaced.
NIST has turned research into a starting point
In August 2024, the US National Institute of Standards and Technology published its first three major standards. FIPS 203 defines ML-KEM, derived from Kyber, for establishing a shared secret through a key-encapsulation mechanism. FIPS 204 defines ML-DSA, derived from Dilithium, for digital signatures. FIPS 205 specifies SLH-DSA, derived from SPHINCS+, another family of signatures based on hash functions.
These technical names mark an industry milestone: vendors now have common specifications for building implementations and ensuring interoperability. They do not provide an absolute, everlasting guarantee. Like all cryptography, these mechanisms must withstand public scrutiny, be implemented correctly and fit into robust protocols. A standardized algorithm does not automatically make a product secure.
Another misconception needs clearing up: post-quantum cryptography runs on classical computers. It does not require a quantum link between two buildings. Nor does all current encryption need to be discarded: symmetric algorithms such as AES do not face the same fundamental disruption as RSA. The task is to distinguish between uses, not to replace indiscriminately every component labeled “security.”
The underestimated challenge of taking inventory
In a large organization, no one necessarily has a complete map of the cryptographic mechanisms in use. The network team knows the VPNs; developers know their libraries; operations teams know certain certificates; procurement knows some of the contracts. Between these areas lie indirect dependencies: a backup agent, a payment terminal, industrial equipment, a cloud service or a legacy application whose maintainer has disappeared.
A useful inventory therefore goes beyond a list of algorithms. It must link each use to a function, to data and to an owner. A frequently renewed certificate protecting a public website has a different profile from a signing key embedded in equipment that is difficult to access. The right question becomes: what does this mechanism protect, for how long, and how can it be changed?
- Locate protocols, libraries, certificates and key-management systems.
- Identify the applications and vendors that depend on each mechanism.
- Assess how long data must remain confidential and the expected lifespan of equipment.
- Document update options, constraints and responsible parties.
Discovery tools can analyze code, configurations or observable communications. But no scan sees everything: an inactive dependency, an opaque encrypted exchange or a function buried in firmware may escape detection. Results must be cross-checked against documentation and technical interviews. Above all, this inventory must remain a living resource; otherwise, each new release will create fresh blind spots.
Changing the algorithm is not enough
On paper, a migration looks like a substitution. In practice, keys, signatures or exchanged messages may take up more space. This can affect connections, available memory, intermediary equipment and resource-constrained devices. Performance varies depending on the mechanism and its implementation: a result obtained on a recent server does not describe how an industrial sensor will behave.
Initial trials must therefore measure an entire chain, not just the speed of a mathematical operation. An organization might test its portal, load balancer, certificate management and oldest clients. An industrial company will also need to examine update signing: protecting communications is not enough if the device later accepts software whose authenticity can be forged.
Hybrid approaches, combining classical and post-quantum mechanisms, offer a transition path. Their value lies in preserving protection if one of the families holds up, provided the combination is designed correctly. But they also increase complexity. Hybrid approaches must rely on proven constructions and profiles, rather than combinations improvised by individual businesses.
As much about procurement as mathematics
The most realistic path is to proceed by priority: data that remains sensitive over the long term, critical infrastructure, then systems whose replacement will be particularly slow. Vendors must be questioned about their planned mechanisms, compatible versions, update arrangements and interoperability tests. A “quantum-safe” sales promise is no substitute for either a technical description or a verifiable roadmap.
In the longer term, this migration could above all drive greater cryptographic agility: the ability to change mechanisms without rebuilding an entire application. That requires clear responsibilities, testing procedures and controlled rollback options. The benefit extends beyond quantum computing: a conventional vulnerability or poor implementation can already force the rapid replacement of a security component.
What now? The sensible course is neither an immediate, universal switchover nor waiting for a firm date when the threat will materialize. Organizations would benefit from starting an inventory now, launching a few representative pilots and setting contractual requirements for upcoming purchases. If threatening quantum computers are slow to arrive, this work will have improved control over their systems. If they advance faster than expected, organizations that understand their dependencies will have a decisive head start: they will know what to change.
