A medical record stolen today may still be valuable in twenty years. So may a trade secret, diplomatic correspondence or infrastructure plans. 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 challenge can be summed up as follows: replace the locks before someone has the master key. The standards published by the US National Institute of Standards and Technology (NIST) have provided a framework for this undertaking. What remains is to locate the locks, understand what they protect and change them without blocking the doors.
A future threat, with exposure already possible
The risk does not come from some magical machine that would render all cybersecurity useless. A sufficiently powerful, error-corrected quantum computer could use Shor’s algorithm to compromise widely used public-key mechanisms, notably RSA and those based on elliptic curves. These mechanisms are used to establish shared secrets, authenticate parties or verify digital signatures. They underpin secure connections, certificates and software updates.
Symmetric encryption, used to protect bulk data, is not affected in the same way. AES does not suddenly become obsolete: the choice of key sizes remains critically important. The post-quantum transition primarily concerns key exchanges and signatures, rather than the indiscriminate replacement of everything that encrypts.
No reliable timeline can tell us when today’s protections will fail. But an adversary can record encrypted communications in the hope of decrypting them later. This strategy, often described as “harvest now, decrypt later,” is enough to change the calculation. For data that must remain secret for several decades, waiting for an attack to be demonstrated would mean waiting too long.
NIST turns research into an industry-wide undertaking
There is a concrete foundation: in August 2024, the National Institute of Standards and Technology published its first three post-quantum standards. FIPS 203 defines ML-KEM, derived from CRYSTALS-Kyber, for establishing a shared secret. FIPS 204 defines ML-DSA, derived from CRYSTALS-Dilithium, for digital signatures. FIPS 205 defines SLH-DSA, derived from SPHINCS+, also intended for signatures but based on a different mathematical family.
This distinction matters. ML-KEM is not a tool for directly encrypting a database: it enables parties to agree on a secret that will then be used by symmetric encryption mechanisms. Signature standards address a different need: verifying the origin and integrity of a document, software or message. A company therefore needs to identify the functions it must replace, not simply choose a new acronym.
Standardization means neither invulnerability nor automatic deployment. It provides common specifications, essential for building compatible products and evaluating their implementations. Diversification continues: in March 2025, NIST selected HQC for future standardization as an additional option. The projections presented here for September 2026 build on these public milestones; they do not constitute a verified assessment of adoption at that date.
The first obstacle: no one can see all their cryptography
In a large organization, cryptography is less like a central vault than a network of pipes. It runs through the website, VPNs, backups, access badges, industrial equipment and exchanges between applications. It also hides in an old library or a cloud service whose components are outside the customer’s control.
An inventory therefore becomes the first worthwhile investment. Organizations need to identify not only algorithms, but also protocols, certificates, libraries, those responsible and the available upgrade options. A simple list of names is not enough. Two applications using RSA may have different levels of urgency depending on the sensitivity of the information, their exposure and the system’s lifespan.
- What are we protecting? Long-lived personal data, manufacturing secrets or information that quickly loses its value?
- For how long? Does the required confidentiality period extend beyond the migration project’s duration?
- Who can make changes? The in-house team, a software vendor, a cloud provider or a manufacturer that no longer exists?
- What will need to be preserved? Lasting confidentiality, proof of authenticity, or both?
This work often reveals previously invisible technical debt. Equipment that is difficult to update may take priority over an exposed but easily replaceable server. For new purchases, migration capability must be included in the specifications: guaranteed updates, documented components and an explicit vendor roadmap.
Changing algorithms without breaking the service
The move to post-quantum cryptography is not a simple box-ticking exercise. Public keys, signatures or exchanged messages may be larger. Depending on the mechanisms chosen, this changes memory consumption, computational load or network behavior. A modern server may be able to absorb the difference; an industrial sensor, smart card or constrained connection may face a serious bottleneck.
End-to-end workflows need to be tested: user login, tunnel establishment, update verification and recovery after an incident. One component may accept the new algorithm while an intermediary rejects an oversized message. Average performance does not tell the whole story: rare failures and incompatibilities carry significant weight at scale.
Hybrid approaches: a bridge that needs careful construction
One approach is to combine a classical mechanism with a post-quantum mechanism for establishing keys. When properly designed, this hybrid approach aims to maintain security as long as either mechanism remains secure. It allows new protection to be introduced without immediately abandoning the guarantees offered by proven mechanisms. But it must rely on reviewed constructions and protocols, not an improvised combination.
Security also depends on the code: random number generation, protection against side-channel leakage, error handling and key storage. A poorly implemented standardized algorithm remains vulnerable. Finally, it is important to distinguish between the publication of a standard, the availability of a library and the validation of a product for regulated use: these stages are not interchangeable.
A transition to be managed as a business risk
The most credible path is not a single sweeping switchover on a Monday morning. It is a series of projects: inventory, prioritize, experiment, then deploy with metrics and controlled rollback procedures. Long-lived confidential data deserves immediate attention. Software signing chains and infrastructure expected to operate for many years represent another major front.
For business leaders, the benefit extends beyond quantum risk alone. Developing cryptographic agility means being able to change algorithms or providers without rebuilding the entire system. This capability will also prove useful when facing a conventional vulnerability or a new regulatory requirement. It does, however, require a budget, expertise and clearly assigned responsibility.
What now? The reasonable outlook is a gradual migration, accelerated by replacement cycles and customer requirements. Its pace will depend on available products, sector-specific constraints and scientific advances. Businesses do not need to predict the arrival of a quantum computer powerful enough to break today’s protections before taking action: they need to know which secrets cannot wait, where they circulate and how long it will take to protect them.
