A medical record stolen today may still be of interest to someone twenty years from now. The same goes for a trade secret, a diplomatic cable or infrastructure blueprints. That is why post-quantum cryptography is not waiting for the arrival of a computer capable of breaking today’s protections. In September 2026, the issue deserves to be treated as a digital asset management project: identifying what needs to last, understanding how it is protected and preparing to replace those protections. The first standards are in place. The hardest part is finding all the locks.
NIST has fired the starting gun
On August 13, 2024, the National Institute of Standards and Technology, the US standards agency, published its first three post-quantum cryptography standards. Their purpose is to provide mechanisms designed to withstand known attacks, whether carried out by classical or quantum computers. Their publication turned years of research and selection into specifications that industry can use.
The first, ML-KEM, standardized in FIPS 203, is derived from CRYSTALS-Kyber. It allows two parties to establish a shared secret, which is then used with symmetric encryption. The other two address digital signatures: ML-DSA, derived from CRYSTALS-Dilithium, and SLH-DSA, derived from SPHINCS+. Among other uses, they help verify the authenticity of a document or software update.
This distinction matters. The aim is not to replace all encryption with a single “quantum algorithm.” These mechanisms run on ordinary computers, and each serves a specific purpose. The standards provide a foundation; they do not automatically make the browsers, network equipment, business applications and security devices that will need to use them compatible.
Why act before the machine exists?
The threat primarily targets today’s ubiquitous public-key cryptography, notably RSA and mechanisms based on elliptic curves. A sufficiently powerful, error-corrected quantum computer could use Shor’s algorithm to solve the mathematical problems on which their security rests. Publicly known machines do not have this capability at an operational scale. When such a turning point might occur remains uncertain.
But that uncertainty does not protect data already intercepted. The scenario known as “harvest now, decrypt later” involves recording encrypted communications in the hope of unlocking them one day. This does not mean that every data stream is actually being stored by an adversary. However, organizations handling long-lived secrets must factor this possibility into their risk assessments.
The strategic calculation comes down to three time frames: how long must information remain secret, how long will migration take, and how soon could a decryption capability emerge? The first two are often already lengthy. Waiting for a spectacular demonstration before starting would amount to changing the locks after allowing the keys to be copied.
The first task looks like an investigation
In a large organization, asking “where do we use RSA?” does not necessarily produce a reliable list. Cryptography is embedded in website certificates, connections between applications, virtual private networks, smart cards, backups, software libraries and industrial equipment. Some of it is managed by suppliers; some remains in systems whose designers have left.
A useful inventory must therefore go beyond the name of an algorithm. It must identify how it is used, its parameters, the system owner and the constraints on replacement. A library can be updated quickly; an industrial controller installed for fifteen years requires a different strategy. A cloud service may announce a post-quantum feature without covering every interface its customers use.
- Map the data: identify information that must remain confidential for ten, twenty years or more.
- Identify dependencies: protocols, certificates, keys, software components, hardware and service providers.
- Assess the capacity for change: possible updates, available resources and equipment that cannot be replaced in the short term.
- Assign responsibility: every critical dependency must have a point of contact and a migration path.
This work involves cybersecurity teams, but also procurement, operations teams and business managers. Medical records illustrate the problem well: protecting their transfer is not enough if an old copy is circulating elsewhere. Conversely, an archive encrypted with a robust symmetric mechanism does not necessarily require the same treatment as an exchange relying on a vulnerable public key.
The transition will hinge on the details
Symmetric encryption is not affected in the same way as RSA. Grover’s quantum algorithm changes theoretical security margins, but it does not mean that all symmetric encryption becomes unusable. Appropriately sized choices, such as AES-256 in suitable contexts, remain relevant. The priority is therefore to examine the entire chain, particularly how keys are established, transported and stored.
For network communications, one transition path is the hybrid approach: combining a classical mechanism with a post-quantum mechanism. Experiments and deployments of this kind had already begun before the final publication of the standards, particularly in the web ecosystem. The aim is to retain protection if either mechanism turns out to have a weakness, provided the combination is properly designed.
This caution comes at a technical cost. Depending on the algorithms, keys, messages or signatures can become significantly larger. Latency, memory consumption, intermediary devices and degraded connections all need testing. A solution that works well in a data center may prove unsuitable for a low-powered sensor. Security also depends on implementation: a sound standard prevents neither programming errors nor side-channel leaks.
Do not confuse announcements with readiness
For decision-makers, the trap would be to buy a “quantum-safe” label in place of a roadmap. A supplier must specify which standards it supports, in which products, with what dependencies and what rollback options. The availability of an algorithm amounts to neither validation of the entire architecture nor certification of every component.
The most reasonable outlook for the period ushered in by these standards is an uneven migration. Regularly updated services should evolve more easily than embedded or industrial systems. Purchases made now will therefore have long-lasting consequences: requiring the ability to switch cryptographic mechanisms, sustained maintenance and interoperability testing can help avoid another dead end. This cryptographic agility is an engineering capability, not a magic button.
What now? The next step should be less spectacular than an announcement of quantum computing power: completing an inventory, testing a hybrid exchange, asking a service provider to clarify its commitments. No credible timeline can establish with certainty when the decisive threat will arrive. But organizations can already shorten their response time. For information that must remain secret for years, the right question is no longer simply “when will we need to migrate?” but “what might we no longer be able to protect if we wait?”
