Gartner published a forecast in late 2024 that most security professionals have either not read or have filed under "future problem." The core claim: quantum computing will be capable of breaking current asymmetric cryptography by 2030. Not 2040. Not "someday." Four years from now, give or take. And the preparation timeline for migrating cryptographic infrastructure across a large organization is two to three years. Run the math and the conclusion is uncomfortable: the migration window is closing.
We are not quantum physicists. We are software engineers who build production systems and have to make practical decisions about cryptographic dependencies. This post is written from that perspective -- not the theoretical end, but the "what do we actually need to change in our codebases and infrastructure" end.
What Changed in August 2024
NIST -- the National Institute of Standards and Technology -- spent eight years evaluating post-quantum cryptographic candidates. In August 2024, they finalized three standards that will form the backbone of cryptography for the next several decades:
ML-KEM (formerly CRYSTALS-Kyber), standardized as FIPS 203, is a key encapsulation mechanism. It replaces the key exchange functions currently handled by RSA and ECDH. When your browser establishes a TLS connection, the key exchange step will eventually use ML-KEM.
ML-DSA (formerly CRYSTALS-Dilithium), standardized as FIPS 204, is a digital signature algorithm. It replaces RSA signatures and ECDSA. Every code-signed binary, every JWT, every certificate in your PKI chain uses digital signatures that ML-DSA will eventually replace.
SLH-DSA (formerly SPHINCS+), standardized as FIPS 205, is a hash-based digital signature scheme. It serves as a backup to ML-DSA, offering a different mathematical foundation. If a breakthrough compromises lattice-based cryptography (which ML-DSA relies on), SLH-DSA provides a fallback based on hash functions, which are better understood.
These are not proposals or drafts. They are finalized federal standards. The migration has officially begun.
Harvest Now, Decrypt Later: The Threat That Already Exists
Here is the part that converts this from a future problem to a current one. Intelligence agencies, state-sponsored actors, and sophisticated criminal organizations are already executing what the security community calls "harvest now, decrypt later" (HNDL) attacks. The approach is straightforward: intercept and store encrypted communications today, then decrypt them once quantum computers become capable.
If the data you are transmitting today has a secrecy shelf life of more than five years -- medical records, financial data, trade secrets, government communications, intellectual property -- it is already at risk. Not from a quantum computer that exists today, but from a quantum computer that will exist when someone decides to decrypt what they captured today.
The NSA acknowledged this threat pattern publicly in 2023. Several European intelligence agencies have issued similar warnings. This is not speculative; it is operational reality.
What Breaks and What Survives
Not everything is vulnerable. Understanding the divide is essential for prioritizing your migration.
What Breaks
RSA (all key sizes) -- The Shor algorithm on a sufficiently large quantum computer factors large integers efficiently, which is the entire mathematical basis of RSA security. RSA-2048, RSA-4096, it does not matter. Quantum computers do not care about key size for this class of problem.
ECDSA and ECDH -- Elliptic curve cryptography falls to the same Shor algorithm attack. The discrete logarithm problem on elliptic curves, which gives ECC its security, is efficiently solvable on a quantum computer.
DSA -- Same vulnerability class. The discrete logarithm problem over finite fields is quantum-vulnerable.
Diffie-Hellman key exchange -- Vulnerable through the same discrete logarithm weakness.
What Mostly Survives
AES-256 -- Grover's algorithm provides a quadratic speedup for brute-force attacks on symmetric ciphers, effectively halving the key strength. AES-256 becomes equivalent to AES-128 against a quantum adversary. AES-128 becomes equivalent to AES-64, which is considered breakable. The practical takeaway: AES-256 remains secure. AES-128 should be phased out.
SHA-256 and SHA-3 -- Hash functions lose some collision resistance to quantum attacks, but SHA-256 retains roughly 128 bits of security against quantum adversaries. SHA-3 was designed with quantum resistance as an explicit consideration. Both remain practical for the foreseeable future.
HMAC constructions -- Generally retain adequate security margins with 256-bit keys.
The Bitcoin Problem
An often-overlooked angle: approximately 6.36 million BTC -- roughly 33% of the total Bitcoin supply -- sit in addresses with exposed public keys. These include early Bitcoin addresses that used pay-to-public-key (P2PK) format, addresses that have sent at least one transaction (which exposes the public key on the blockchain), and Satoshi Nakamoto's estimated 1.1 million BTC.
Once a quantum computer can derive private keys from public keys using Shor's algorithm, these coins become vulnerable to theft. The Bitcoin community has discussed migration strategies, but there is no consensus mechanism in place to force key rotation. This represents one of the largest known concentrations of quantum-vulnerable assets -- valued at over $380 billion at current prices.
This is not FUD. It is a mathematical inevitability with an uncertain timeline. The Bitcoin Core developers are aware. Migration proposals exist. But the decentralized governance model makes coordinated action slow.
The Migration Timeline: Honest Assessment
Here is the honest answer on timing. Nobody knows exactly when a cryptographically relevant quantum computer (CRQC) will arrive. Estimates from credible sources range from 2029 to 2035. IBM's quantum roadmap targets 100,000+ qubits by 2033. Google's Willow chip, announced in late 2024, demonstrated 105 qubits with below-threshold error correction -- a meaningful milestone but still far from the millions of logical qubits needed to run Shor's algorithm against RSA-2048.
The US government's position is clear: National Security Memorandum 10, issued in 2022, mandates that federal agencies achieve quantum-resistant cryptography by 2035. That is a hard deadline with budget implications.
For private sector organizations, we recommend working backward from a 2030 worst-case scenario:
- 2026-2027: Complete cryptographic inventory and risk assessment
- 2027-2028: Implement hybrid cryptographic modes in critical systems
- 2028-2030: Full migration to post-quantum standards for high-value data
- 2030-2035: Legacy system migration and long-tail cleanup
If this feels aggressive, consider that the Y2K remediation effort -- which was fundamentally a simpler problem than cryptographic migration -- took most organizations three to five years.
Current vs Post-Quantum: The Technical Comparison
Here is where developers need to pay attention. Post-quantum algorithms come with significant performance and size tradeoffs.
| Parameter | RSA-2048 | ECDSA (P-256) | ML-KEM-768 | ML-DSA-65 | SLH-DSA-128s |
|---|---|---|---|---|---|
| Public Key Size | 256 bytes | 64 bytes | 1,184 bytes | 1,952 bytes | 32 bytes |
| Signature/Ciphertext Size | 256 bytes | 64 bytes | 1,088 bytes | 3,309 bytes | 7,856 bytes |
| Key Generation Speed | Slow | Fast | Very Fast | Fast | Slow |
| Sign/Encaps Speed | Fast | Fast | Very Fast | Fast | Slow |
| Verify/Decaps Speed | Very Fast | Moderate | Very Fast | Fast | Moderate |
| NIST Security Level | ~112-bit | ~128-bit | Level 3 (~192-bit) | Level 3 (~192-bit) | Level 1 (~128-bit) |
| Quantum Resistant | No | No | Yes | Yes | Yes |
| Mathematical Basis | Factoring | Elliptic Curves | Lattice (MLWE) | Lattice (MLWE) | Hash Functions |
The key takeaway from this table: post-quantum algorithms have significantly larger key and signature sizes. ML-DSA signatures are roughly 50x larger than ECDSA signatures. SLH-DSA signatures are over 120x larger. This has real implications for bandwidth, storage, TLS handshake times, certificate sizes, and blockchain transaction sizes.
Performance benchmarks on modern hardware show that ML-KEM key encapsulation is actually faster than RSA key exchange. ML-DSA signing and verification are comparable to RSA. SLH-DSA is the slowest of the three, which is why it is positioned as a fallback rather than a primary standard.
Your Practical Migration Roadmap
Step 1: Cryptographic Inventory (Month 1-2)
You cannot migrate what you have not mapped. Identify every place your systems use cryptography:
- TLS certificates and their algorithms
- JWT signing algorithms (RS256, ES256 are both quantum-vulnerable)
- Database encryption at rest (usually AES -- check key sizes)
- API authentication tokens
- Code signing certificates
- SSH keys
- VPN configurations
- Encrypted backup storage
- Password hashing (bcrypt, scrypt, argon2 -- these are symmetric and generally safe)
Tools like Venafi, IBM's Quantum Safe Explorer, and Cryptosense can automate parts of this inventory. For smaller organizations, a manual audit of configuration files and certificate stores is sufficient.
Step 2: Risk Prioritization (Month 2-3)
Not everything needs to migrate simultaneously. Prioritize based on data sensitivity and longevity:
Immediate priority: Any data with a secrecy requirement beyond 2030 -- health records, financial data, government data, long-lived credentials, intellectual property.
Medium priority: Session-based authentication, short-lived API tokens, data with a secrecy window under five years.
Lower priority: Publicly available data with integrity requirements (these need signature migration but are not vulnerable to HNDL attacks).
Step 3: Implement Hybrid Mode (Month 3-8)
The recommended transition strategy is hybrid cryptography -- using both classical and post-quantum algorithms simultaneously. If the post-quantum algorithm turns out to have a vulnerability, the classical algorithm still provides security. If a quantum computer arrives, the post-quantum algorithm provides protection.
For TLS, this is already happening. Chrome and Firefox have shipped support for X25519Kyber768 hybrid key exchange. Cloudflare enabled it by default for all customers in September 2024. If your users access your services through modern browsers and you are behind Cloudflare, your TLS key exchange already has post-quantum protection in hybrid mode.
For application-layer cryptography, most languages now have post-quantum libraries:
# Python: using the pqcrypto library
from pqcrypto.kem.kyber768 import generate_keypair, encrypt, decrypt
public_key, secret_key = generate_keypair()
ciphertext, shared_secret_enc = encrypt(public_key)
shared_secret_dec = decrypt(secret_key, ciphertext)// Go: using the Cloudflare circl library
import "github.com/cloudflare/circl/kem/kyber/kyber768"
pk, sk, _ := kyber768.GenerateKeyPair(rand.Reader)
ct, ss, _ := kyber768.Encapsulate(pk)
ss2, _ := kyber768.Decapsulate(sk, ct)Step 4: Migration and Validation (Month 8-18)
Systematically replace classical algorithms with post-quantum or hybrid alternatives. The order matters:
- Key exchange and encapsulation (highest HNDL risk)
- Digital signatures on long-lived artifacts (certificates, code signing)
- Digital signatures on short-lived tokens (JWTs, session tokens)
- Legacy system bridges and backward compatibility layers
Step 5: Continuous Monitoring
Post-quantum cryptography is still young. New attacks, performance improvements, and implementation guidance will emerge. Subscribe to NIST's PQC mailing list. Monitor CVE databases for post-quantum implementation vulnerabilities. Re-evaluate annually.
What Developers Should Do Right Now
Even if your organization is not ready for a full migration, individual developers can take steps today that will make the eventual migration significantly easier.
Stop hardcoding algorithm choices. If your code contains algorithm: "RS256" as a string literal, wrap it in a configuration layer. The day you need to change it, you want a config change, not a code change across forty services.
Abstract your cryptographic operations. Do not call OpenSSL functions directly from business logic. Wrap them in a service layer. When you swap the underlying implementation, the consuming code should not need to change.
Use hybrid TLS in production now. If you use Cloudflare, AWS CloudFront, or Fastly, enable post-quantum key exchange. It costs nothing. It protects your users' traffic today against future quantum decryption.
Start testing post-quantum libraries. Run them in staging. Measure the performance impact of larger key and signature sizes on your specific workloads. The performance characteristics in the table above are generalizations; your mileage will vary depending on your architecture.
Rotate your long-lived keys. If you have SSH keys, GPG keys, or CA certificates that have been in use for years, rotate them. Shorter key lifetimes reduce the window of HNDL exposure.
The Organizational Challenge
The technical migration is the straightforward part. The organizational challenge is harder. Cryptographic changes touch every layer of the stack, every service, every partner integration, every certificate chain. This requires coordination across security, infrastructure, development, and operations teams.
Our recommendation: appoint a quantum readiness lead now, even if it is a part-time responsibility. Have them own the cryptographic inventory, track the timeline, and maintain a migration plan that gets updated quarterly. The organizations that will handle this transition smoothly are the ones that start planning in 2026, not the ones that panic in 2029.
The Honest Bottom Line
Post-quantum cryptography is not an existential crisis requiring emergency action. It is an infrastructure migration with a known timeline, published standards, and available tools. The risk is not that quantum computers will arrive tomorrow and break everything. The risk is that migration takes years and organizations that wait too long will find themselves rushing a process that demands careful execution.
That said, for most small to mid-size companies running standard web applications, the practical risk is low in the near term. Your TLS connections are probably already protected via CDN-level hybrid key exchange. Your biggest exposure is likely long-lived data encrypted with RSA or stored with ECDH-derived keys. Start there.
The quantum threat is real, the timeline is uncertain, and the standards are ready. The rest is execution. And execution, as always, is where the hard work lives.
Wondering how quantum-ready your infrastructure is? Our security team at CODERCOPS runs cryptographic audits that map your exposure and produce a prioritized migration plan. Get in touch -- we will tell you exactly where you stand and what needs to move first.
Comments