In a bank, the problem rarely begins in front of a quantum computer. It lurks in a forgotten certificate, a legacy application or a piece of network equipment that is difficult to update. Post-quantum migration is first and foremost an investigation into existing systems. As of September 2026, its urgency does not hinge on a spectacular demonstration: the standards exist, and some information must remain secret for decades. Here are the established facts and the outlook for an undertaking whose effects could remain largely invisible to users.
NIST has fired the starting gun
On August 13, 2024, the US National Institute of Standards and Technology published its first three finalized post-quantum cryptography standards. The result of an international process launched in 2016, this milestone provided a common foundation for manufacturers, developers and buyers. It does not mean that every product is ready, but that work can now proceed on stable specifications rather than candidates still competing for selection.
- ML-KEM, the FIPS 203 standard, derived from CRYSTALS-Kyber, establishes a shared secret that can then be used to encrypt communications.
- ML-DSA, the FIPS 204 standard, derived from CRYSTALS-Dilithium, enables the creation of digital signatures.
- SLH-DSA, the FIPS 205 standard, derived from SPHINCS+, offers another family of signatures based on hash functions.
This diversity matters: security must not depend on a single mathematical assumption. In March 2025, NIST also selected HQC for future standardization as a complementary key-encapsulation mechanism. Selection, however, is neither a finalized standard nor a requirement for immediate deployment. For organizations, the initial foundation is already enough to begin taking stock, testing and holding contractual discussions.
Why act before a computer can break the keys?
The threat primarily targets public-key cryptography. RSA and elliptic-curve systems currently protect key exchanges, identities and signatures. A sufficiently powerful, fault-tolerant quantum computer could undermine their foundations using Shor’s algorithm. No publicly demonstrated machine currently has this capability at the necessary scale. Announcements about qubit counts are not enough to establish otherwise.
But waiting for that machine would be a timing mistake. An actor can record encrypted communications today in the hope of decrypting them later: this is the “harvest now, decrypt later” scenario. A medical record, an industrial secret or diplomatic information may retain its value long after the server that processed it has been replaced. The risk therefore depends as much on how long confidentiality must be maintained as on the highly uncertain date of a quantum breakthrough.
Not all encryption faces the same threat. Symmetric algorithms, such as AES, are not affected in the same way as RSA. Appropriate parameters, particularly 256-bit keys, provide substantial security margins against known quantum attacks. The task is therefore not to discard all existing security, but to identify vulnerable mechanisms and their uses precisely.
The first obstacle: no one has a complete view of their cryptography
In a large corporation, cryptography is scattered across software libraries, browsers, VPNs, cloud services, smart cards and hardware security modules. It also appears in update signatures, exchanges between applications and backups. An IT department may know its servers without knowing which algorithms each component actually uses, or who will be able to replace them.
The inventory must therefore go beyond a list of certificates. For each use, organizations need to identify the protocol, library, supplier, key lifetime and data sensitivity. Then comes a very practical question: will an update be enough, or will the hardware need replacing? Industrial equipment with no update mechanism poses a far more enduring problem than a web application maintained every week.
Three sectors, three timelines
For a bank, one particular challenge lies in interdependence: payments, authentication, partner connections and trust infrastructure must continue to work together. Compatibility takes precedence over headline-grabbing announcements. In industry, the long service life of machinery complicates the equation. An industrial controller purchased today may remain in service long enough to span several generations of cryptographic recommendations.
Government agencies, meanwhile, combine legacy application estates, sensitive information and lengthy procurement procedures. Priority should go to data that must remain confidential for a long time, as well as systems that are difficult to replace. An effective migration does not treat every application with the same urgency: it weighs exposure, the required protection period and the cost of change.
Replacing an algorithm is not enough
Post-quantum cryptography runs on classical computers. There is no need to install a quantum machine in a data center to benefit from it. Its keys, messages used to establish shared secrets and signatures, however, may be larger than those of the mechanisms being replaced. These differences can affect latency, available memory or the operation of an intermediate network device.
Testing must therefore cover complete end-to-end paths. A successful connection in a laboratory does not guarantee that it will work behind every firewall, over a degraded mobile network or on a resource-constrained device. Implementation robustness also matters: a standardized algorithm prevents neither programming errors nor side-channel attacks. Software quality and key protection remain essential.
A transition may use hybrid mechanisms, combining a classical component with a post-quantum component. When properly designed, this approach aims to maintain protection as long as either component remains secure. It can reduce some uncertainties, but also adds complexity. It must not become an improvised patchwork: proven protocols and analyzed combinations are essential.
The real investment: being able to change again
For decision-makers, the immediate deliverable is not a “quantum-safe” badge. It is a roadmap: designated owners, documented dependencies, a test environment and requirements communicated to suppliers. New contracts can ask which standards will be supported, how updates will be distributed and what evidence of validation will be available. A commercial promise is no substitute for a verifiable capability.
This approach has a name: crypto-agility. It means being able to replace algorithms, keys and certificates without rebuilding the entire system. Its value extends beyond the quantum threat, since weaknesses can also emerge in classical technologies. The main cost may stem less from additional computation than from coordination: testing, documenting, certifying and organizing cutovers without interrupting services.
What happens next? The most plausible path is a gradual, uneven and largely invisible migration, rather than a single watershed moment for encryption. The best-prepared organizations will be those that began by understanding what they are protecting and for how long. The quantum deadline remains uncertain; the time needed to transform infrastructure, however, is already a very real constraint.
