The work rarely begins in a quantum laboratory. Instead, it starts with an incomplete inventory: a forgotten VPN, an outdated software library, sensors that cannot be updated. Post-quantum cryptography promises to protect communications against future computers capable of breaking some of today’s safeguards. But its real challenge is already an industrial one: replacing mechanisms embedded everywhere without interrupting services. Looking ahead to September 2026, the standards published in 2024 provide a concrete foundation; the pace of deployment, however, remains a matter of integration, resources and priorities.
The risk is not waiting for the machine
No reliable timeline can predict the arrival of a quantum computer capable of breaking widely used cryptographic systems at an operational scale. The machines required would need substantial capabilities, particularly in error correction. Confusing a scientific demonstration with an industrial-scale attack capability would be misleading. But waiting for evidence of immediate danger would be equally unwise.
The reason comes down to a simple phrase: harvest now, decrypt later. An adversary can record encrypted communications and store the data until tools become available to uncover their secrets. For a promotional code, the stakes are limited. For medical records, trade secrets or diplomatic information that must remain confidential for decades, it changes the calculation entirely.
The threat primarily concerns public-key cryptography, particularly RSA and mechanisms based on elliptic curves. On a sufficiently powerful quantum machine, Shor’s algorithm could solve the mathematical problems underpinning their security. Symmetric encryption, such as AES, is not affected in the same way: appropriate parameters provide security margins. Replacing everything indiscriminately would therefore be a poor strategy.
What the 2024 standards changed
On August 13, 2024, the US National Institute of Standards and Technology published its first three post-quantum cryptography standards. The result of a lengthy international evaluation process, they give developers and industry a common set of specifications. This shift from academic competition to standardization is decisive: interoperable products can now be built around a stable reference.
- ML-KEM, the FIPS 203 standard, derived from CRYSTALS-Kyber, enables two parties to establish a shared secret.
- ML-DSA, the FIPS 204 standard, derived from CRYSTALS-Dilithium, provides a digital signature mechanism.
- SLH-DSA, the FIPS 205 standard, derived from SPHINCS+, offers signatures based on hash functions.
These tools serve different purposes. A key encapsulation mechanism helps establish the secret that will subsequently be used to encrypt communications. A signature makes it possible to verify the origin and integrity of a document, software or an update. This distinction matters: protecting a network tunnel does not automatically secure the firmware installed on a machine.
Nor does “post-quantum” mean “quantum communication.” These algorithms run on classical computers and existing networks. They rely on mathematical problems considered resistant to known quantum attacks. Standardization is not an everlasting guarantee, however: cryptanalysis, implementation quality and vulnerability monitoring remain essential.
The first obstacle: finding hidden cryptography
Within a company, no one necessarily has a complete map of cryptographic uses. The networking team knows the VPNs, developers know their libraries, and procurement knows the cloud contracts. But who keeps track of a printer’s certificates, an industrial controller’s keys or backup signatures? Migration begins with this unglamorous exercise: establishing where the algorithms are, who maintains them and how long they will need to operate.
This inventory must connect technology with risk. How long must the information remain confidential? Can the equipment receive updates? Does it depend on a single supplier? A recent system exposing sensitive data may be a priority, as may an installation intended to remain in service for twenty years. Hardware age alone is not enough to determine the order of work.
The update itself must remain trustworthy
Connected devices bring these difficulties into sharp focus. Their memory, computing power and bandwidth are sometimes limited. Yet post-quantum keys, signatures or messages can be larger than their classical counterparts, depending on the mechanisms being compared. An operation that is trivial on a server can become demanding for a battery-powered sensor.
The transition path must also be secured. If a device recognizes only an old signature mechanism when accepting updates, how can it be taught to verify a new one? This question must be addressed before its chain of trust becomes vulnerable. For some equipment, a software migration will suffice; for other devices, hardware replacement may be necessary.
Migrating without breaking what works
Moving to post-quantum cryptography is not simply a matter of selecting a new algorithm from a menu. Protocols, certificate formats, cryptographic modules and intermediary devices must all be checked. A longer message can expose a limitation in a firewall or an embedded system. Even a correctly implemented library can be poorly integrated or leak information through side channels.
Hybrid approaches offer a transition path: they combine a classical mechanism with a post-quantum one. When properly designed, they aim to maintain protection if either family is compromised. They do, however, add complexity. Their value depends on proven constructions, well-defined protocols and interoperability testing, not an improvised combination.
For critical infrastructure, a sensible approach looks more like a phased renovation than an overnight cryptographic revolution. Testing on a representative platform, measuring latency and memory usage, checking degraded operating modes, then deploying gradually: these steps also protect availability. A theoretically excellent mechanism that interrupts an essential service does not constitute a successful migration.
The real innovation: being able to change again
This undertaking brings crypto-agility back to the forefront: the ability to evolve cryptographic mechanisms without rebuilding an entire application. It requires known dependencies, controlled configurations and tested renewal procedures. It does not mean freely multiplying options at the risk of allowing weak choices. Useful agility remains governed by a security policy.
Procurement therefore becomes a technical lever. Asking for a post-quantum roadmap, a defined maintenance period and evidence of interoperability is more useful than a “quantum-safe” marketing label. In a scenario of growing adoption following the 2024 standards, the best-prepared organizations will not necessarily be those that migrate fastest, but those that can justify every transition.
What next? The next step should be less visible than a quantum processor announcement, but more immediately useful: taking inventory, setting priorities and experimenting. Adoption will depend in particular on the maturity of protocols, products and sector-specific requirements. Without predicting a breaking point, one operational certainty stands out: systems purchased today may still be running when the threat reaches a new scale. Preparing them to evolve means ensuring that tomorrow’s security does not remain trapped by yesterday’s choices.