A large enough quantum computer could break the public-key cryptography that protects most web traffic and software signatures today. Nobody can name the date. NIST has already published replacement standards, so the sensible move is to inventory where you use vulnerable algorithms and plan the swap now, starting with data that must stay secret for years.
What would break, and what would not?
NIST's post-quantum project describes the threat as quantum machines that "may be years or decades away" but could eventually break many widely used cryptographic systems. The exposed part is public-key cryptography: the key exchange that sets up an encrypted session, and the digital signatures that prove who signed a file or a certificate.
That matters for supply chain work. Signed packages, signed container images, code signing and TLS certificates all lean on those primitives. A break would not look like a data leak on day one. It would look like signatures you can no longer trust.
This post does not predict when that happens. NIST itself says the question of when a large quantum computer arrives is a complicated one, and we have no better evidence than the people who run the standards project.
What has actually been decided so far?
The facts that are settled and published:
| Date | Event |
|---|---|
| 2015 | NIST starts its process to pick quantum-resistant algorithms |
| 13 August 2024 | FIPS 203 (ML-KEM), FIPS 204 (ML-DSA) and FIPS 205 (SLH-DSA) published |
| 12 November 2024 | NIST IR 8547 draft describes the transition plan |
| 11 March 2025 | HQC selected for standardization as a backup key-establishment method |
FIPS 203 is the main standard for general encryption. FIPS 204 is the main one for signatures, and FIPS 205 is a signature backup built on a different mathematical approach. NIST's lead for the project said there is "no need to wait for future standards" and told administrators to start integrating the three that exist.
On timing, NIST's project page says that under IR 8547 it will deprecate and ultimately remove quantum-vulnerable algorithms from its standards by 2035, with high-risk systems moving much earlier. Treat that as a planning input, not as a prediction of when an attack arrives.
Why not wait until the threat is real?
Two reasons, both from NIST's own text. First, it has historically taken almost two decades to deploy modern public-key infrastructure, so a late start is expensive. Second, migration touches products you do not control: NIST notes that cybersecurity products, services and protocols all need updates.
There is also an ordering problem. Data that needs to stay confidential for ten or twenty years deserves attention before data that expires next quarter. The reverse holds for signatures: a signature only has to be trusted at verification time, but a root key that signs software for a decade is a long-lived asset.
A calm migration order
Start with discovery, because you cannot replace what you cannot find. Cryptography hides in libraries, TLS terminators, VPN gear, HSMs, code-signing pipelines and the SBOM of every product you ship. A software inventory built from your dependencies is a reasonable first map of which crypto libraries you carry, though it will not show every hardware or protocol use.
Then classify by lifetime of the secret, not by how scary the system sounds. Then ask suppliers for their own plans in writing. Then test the new algorithms in a staging path before they reach production, since key and signature sizes differ from what current protocols assume.
What to do
- List every place you use public-key cryptography: TLS, SSH, VPN, code signing, package signing, certificates, JWT signing.
- Generate SBOMs for the products you ship and flag the crypto libraries inside them.
- Rank assets by how long the protected data must stay confidential.
- Ask each critical supplier for a written post-quantum plan and a date for FIPS 203 and 204 support.
- Design for crypto agility: algorithm names in config, not hard-coded.
- Pilot ML-KEM and ML-DSA in a non-production path and measure the size and latency effect.
- Track NIST IR 8547 for changes to the transition timeline.
Quick check
Has a quantum computer broken encryption yet?
No source we fetched says so. NIST describes the threat as machines that may be years or decades away, and its standards work exists to get ahead of that.
Which standards should I look at first?
FIPS 203 for key establishment and FIPS 204 for signatures, both published on 13 August 2024. FIPS 205 is the signature backup.
Sources
- NIST Post-Quantum Cryptography project
- NIST releases first 3 finalized post-quantum encryption standards, 13 August 2024
- NIST IR 8547 initial public draft, Transition to Post-Quantum Cryptography Standards
Last reviewed: 18 October 2026.
