In August 2024, NIST published three new encryption standards. Not updates. Not patches. Entire replacements for the cryptographic algorithms that protect virtually every digital transaction on the planet.

The reason? A computer that doesn't fully exist yet is going to break all of them.

That might sound like a problem for the future. It isn't. Adversaries are already stealing your encrypted data today, stockpiling it, waiting for quantum computers to catch up. It's called "harvest now, decrypt later," and it means the clock on your current encryption started ticking years ago.

Why Quantum Breaks Everything

Here's the short version. RSA, ECC, Diffie-Hellman — the algorithms behind TLS, SSH, VPNs, digital signatures, certificate authorities, and basically every secure connection you use — rely on math problems that classical computers can't solve in any reasonable timeframe. Factoring massive prime numbers. Computing discrete logarithms on elliptic curves.

A sufficiently powerful quantum computer running Shor's algorithm solves these problems in hours. Not years. Not decades. Hours.

RSA-2048? Broken. ECC-256? Broken. Every HTTPS connection, every signed software update, every encrypted email — all of it becomes readable.

We're not there yet. Current quantum processors — Google's 105-qubit Willow chip, IBM's 120-qubit Nighthawk — are impressive engineering milestones, but they're still in what researchers call the NISQ era (Noisy Intermediate-Scale Quantum). They can't run Shor's algorithm at a scale that threatens production cryptography. Not today.

But the trajectory is clear. Google's Willow demonstrated exponential error reduction in late 2024 — a critical threshold for fault-tolerant quantum computing. IBM expects to deliver quantum advantage by end of 2026 and fault-tolerant systems by 2029. The industry consensus puts cryptographically relevant quantum computers at 10 to 15 years out.

That sounds like plenty of time. It isn't.

Harvest Now, Decrypt Later

This is the threat that makes post-quantum cryptography urgent today, not in 2035.

Nation-state actors and sophisticated threat groups are intercepting encrypted traffic right now and storing it. Government communications. Financial transactions. Healthcare records. Intellectual property. Military intelligence. Any data with a long shelf life.

When quantum computers become capable, they'll decrypt the entire archive.

The Federal Reserve published a research paper in 2025 specifically analyzing this risk for financial infrastructure and blockchain networks. The conclusion was blunt: data encrypted with classical algorithms today has a defined expiration date on its confidentiality.

If your data needs to stay confidential for 10 years, and quantum computers arrive in 10 years, you needed post-quantum encryption yesterday. The math doesn't leave room for procrastination.

The New Standards: What NIST Actually Published

On August 13, 2024, NIST released three finalized post-quantum cryptography standards. These aren't theoretical proposals. They're production-ready specifications with implementation guidance.

FIPS 203 — ML-KEM (Module-Lattice-Based Key-Encapsulation Mechanism)

Derived from CRYSTALS-Kyber. This is the primary standard for key exchange — the mechanism that lets two parties establish a shared secret over an insecure channel. Every TLS handshake, every VPN tunnel, every encrypted session depends on this.

ML-KEM replaces the key exchange portions of RSA and Diffie-Hellman. It's fast, the key sizes are manageable, and it's built on structured lattice problems that quantum computers can't efficiently solve.

FIPS 204 — ML-DSA (Module-Lattice-Based Digital Signature Algorithm)

Derived from CRYSTALS-Dilithium. This is the primary standard for digital signatures — proving that a message, certificate, or software update genuinely came from who it claims.

ML-DSA replaces RSA signatures and ECDSA. If you're signing code, issuing certificates, or authenticating API requests, this is your migration target.

FIPS 205 — SLH-DSA (Stateless Hash-Based Digital Signature Standard)

Derived from SPHINCS+. This is the backup signature standard, and it exists for a specific reason: it uses completely different math than ML-DSA. While ML-DSA is lattice-based, SLH-DSA is hash-based.

Why does that matter? If someone finds a breakthrough attack against lattice-based cryptography, SLH-DSA still stands. It's diversification against catastrophic failure of a single mathematical assumption.

What's Still Coming

NIST isn't done. A fourth signature standard based on the FALCON algorithm (to be called FN-DSA) is still in development. And in March 2025, NIST selected HQC (Hamming Quasi-Cyclic) as a second KEM standard — a backup to ML-KEM using error-correcting codes instead of lattices. The HQC standard is expected to be finalized by 2027.

The pattern is clear: NIST is building redundancy into every category. They're planning for the possibility that any single mathematical approach might fail.

The Timeline Is Tighter Than You Think

NIST IR 8547, published in November 2024, lays out the deprecation schedule:

Those aren't suggestions. For federal agencies and anyone in their supply chain, those are hard deadlines. For everyone else, they signal the industry timeline for support, compatibility, and insurance coverage.

The NSA's CNSA 2.0 guidance is even more aggressive for certain categories:

And in January 2026, CISA published a list of product categories where federal agencies should only procure PQC-enabled versions. The procurement lever is already being pulled.

If you're thinking "2030 is far away," consider how long your last major infrastructure migration took. Now consider that this one touches every certificate, every key, every TLS configuration, every VPN, every SSH key, every code signing pipeline, and every encrypted database in your environment. Cryptographic migrations are measured in years, not months.

Who's Already Moved

This isn't theoretical. Major platforms have shipped post-quantum cryptography into production.

Apple rolled out PQ3 for iMessage in early 2024, using ML-KEM for post-quantum key exchange. In September 2025, Apple enabled post-quantum TLS encryption by default across iOS, iPadOS, and macOS — every connection, not just messaging.

Google Chrome enabled hybrid post-quantum key exchange (X25519Kyber768) by default starting with Chrome 124 in early 2024. By March 2025, Chrome, Edge, and Firefox combined were protecting 38% of web traffic with post-quantum key exchange.

Signal upgraded to PQXDH — a hybrid protocol combining classical X25519 with CRYSTALS-Kyber — in September 2023. In October 2025, they published research on a Triple Ratchet protocol incorporating the Sparse Post-Quantum Ratchet (SPQR) for ongoing quantum-safe forward secrecy.

Cloudflare reports that post-quantum encrypted traffic nearly doubled through 2025, reaching 52% by early December. In January 2026, ML-KEM became a default feature for connections to Cloudflare origin servers. They also announced the world's first complete SASE platform supporting post-quantum encryption.

The message is clear: the organizations with the best security teams in the world are treating this as a present-tense priority, not a future one.

The Hybrid Approach: Don't Go Cold Turkey

Every major deployment so far uses a hybrid approach — combining classical algorithms with post-quantum ones. Chrome's X25519Kyber768 is a perfect example: X25519 (classical elliptic curve) combined with Kyber768 (post-quantum lattice).

Why not just switch entirely to post-quantum? Two reasons:

Confidence. These algorithms are new. They've survived years of cryptanalysis, but they haven't been battle-tested at the scale of RSA's 40+ year track record. A hybrid approach means that even if a post-quantum algorithm is broken, you still have classical protection.

Compatibility. Not every system in your stack supports post-quantum yet. Hybrid modes let you incrementally deploy without breaking connections to systems that haven't migrated.

The recommended migration path is: classical → hybrid (classical + PQC) → pure PQC. Most organizations should be targeting hybrid mode now and planning for pure PQC within the NIST timeline.

What a Migration Actually Looks Like

Cryptographic migrations are notoriously complex because cryptography is woven into everything. Here's what the scope actually involves:

1. Inventory Your Cryptographic Assets

You can't migrate what you can't find. Start with a complete inventory:

Most organizations discover they have significantly more cryptographic dependencies than they thought. Shadow IT, legacy systems, embedded devices — they all use cryptography, and they all need to migrate.

2. Classify by Risk

Not everything migrates at the same time. Prioritize based on:

3. Test Compatibility

Post-quantum algorithms have larger key sizes and different performance characteristics. ML-KEM public keys are roughly 800 bytes to 1.5 KB depending on the security level — larger than RSA-2048's 256-byte public key, but manageable. Signature sizes for ML-DSA range from about 2.4 KB to 4.6 KB.

These size increases can impact:

Test before deploying. Measure the performance impact in your specific environment.

4. Upgrade Libraries and Infrastructure

Your cryptographic libraries need post-quantum support. Check whether your current versions of OpenSSL, BoringSSL, or whatever library you're using already include ML-KEM and ML-DSA support. If not, plan the upgrade.

HSMs (Hardware Security Modules) may need firmware updates or replacement. Certificate authorities are working on post-quantum certificate issuance, but broad browser trust for PQC certificates isn't expected until 2027.

5. Deploy Hybrid, Monitor, Iterate

Start with hybrid key exchange on your highest-risk systems. Monitor for performance regressions, compatibility issues, and any operational impact. Expand gradually.

This isn't a weekend project. Budget for a multi-year migration with dedicated resources.

Common Mistakes to Avoid

Waiting for "quantum computers to actually be a threat." The harvest-now-decrypt-later attack means your data is already at risk. Migration takes years. Starting late means finishing late.

Trying to migrate everything at once. Prioritize by risk. Internet-facing systems with long-lived data come first. Internal tooling with ephemeral data can wait.

Ignoring the supply chain. Your encryption is only as strong as your weakest integration. If your payment processor, cloud provider, or SaaS vendor hasn't started their migration, your data is still exposed when it transits their systems.

Assuming AES is fine. AES-256 is quantum-resistant — Grover's algorithm only halves the effective key length, making AES-256 equivalent to AES-128 against a quantum attacker. That's still strong. But AES doesn't protect key exchange. If the key exchange is broken, the AES encryption it protects is irrelevant because the attacker has the key.

Skipping the inventory. Organizations routinely discover they have 5x to 10x more cryptographic dependencies than they estimated. The inventory step isn't bureaucratic overhead — it's how you avoid discovering a critical system you forgot to migrate after the deadline.

The Bottom Line

The math is settled. Quantum computers will break RSA and ECC. The standards to replace them are finalized. The migration timeline has hard deadlines. And the harvest-now-decrypt-later threat means your data is already exposed if it has long-term value.

This isn't a future problem dressed up as an urgent one. Over half of web traffic is already post-quantum protected. Apple, Google, Signal, and Cloudflare have shipped. NIST has published. The NSA has set deadlines.

Start here:

  1. Run a cryptographic inventory across your infrastructure. Identify every system using RSA, ECC, or Diffie-Hellman for key exchange or signatures.
  2. Classify your data by longevity. Anything that needs to stay confidential for 10+ years is your highest priority for PQC migration.
  3. Update your cryptographic libraries. Ensure your TLS stack, SSH implementation, and key management systems support ML-KEM and ML-DSA.
  4. Deploy hybrid key exchange on your most exposed, highest-value systems first. Monitor performance and compatibility.
  5. Engage your vendors. Ask your cloud providers, SaaS platforms, and certificate authorities about their PQC roadmaps. If they don't have one, that's a risk factor.
  6. Build a migration plan with a realistic timeline. Aim to be hybrid by 2028 and fully migrated before the 2030 deprecation deadline.

The organizations that start now will migrate calmly and methodically. The ones that wait will be scrambling against a hard deadline with incomplete inventories and untested deployments. History has shown which group handles cryptographic transitions better.

Your encryption has an expiration date. Act accordingly.