Harvest Now, Decrypt Later: Post-Quantum Readiness for AI

June 25, 2026 · Securing AI: How AI Gets Attacked — and Defended (part 35)

▶ Watch on YouTube & subscribe to The Stack Underflow

Your model weights are encrypted. Your training data is encrypted. Your embeddings are encrypted in transit. Everything looks safe — until you realize that “safe today” is not the same as “safe in ten years,” and that an adversary with patience and a large enough storage budget is already copying your encrypted blobs right now.

That is the shape of Harvest Now, Decrypt Later (HNDL): a long-horizon attack that decouples the theft from the decryption. The attacker does not need to break your encryption today. They only need to archive your ciphertext, then wait for quantum computing to mature. AI artifacts — model weights, training datasets, embeddings — are unusually long-lived and unusually valuable, which makes them among the most attractive targets for this strategy.

The one-sentence version: HNDL is when an adversary steals your encrypted AI secrets today and stores them until a quantum computer can read them in the future — and the fix is building your system so you can swap cryptographic algorithms before that day arrives.

The attack flow: harvest, store, decrypt

HNDL is not a single intrusion event. It is a three-phase strategy:

Phase 1 — HARVEST (today)
  Adversary intercepts or copies encrypted blobs:
    - model weights in cloud storage
    - training data in transit or at rest
    - embeddings flowing between services
    - inter-agent TLS traffic
  The ciphertext is unreadable. That is fine. They keep it.

Phase 2 — STORE (now through Q-Day)
  Adversary archives the ciphertext.
  Cost: near-zero (storage is cheap).
  Risk to adversary: none.

Phase 3 — DECRYPT (once a cryptographically relevant
            quantum computer exists)
  The quantum machine runs Shor's algorithm against
  RSA and ECC key material.
  Result: all archived ciphertext becomes plaintext.

The attack exploits a structural asymmetry: the cost of harvesting and storing encrypted data is tiny and immediate, while the defensive window to prevent future decryption is finite and closing. Q-Day (the informal term for the arrival of a cryptographically relevant quantum computer, or CRQC) does not have to be imminent for the attack to be worth launching today.

Forrester (2026) characterizes cryptographically relevant quantum computers as plausible by 2030. Recent research has reduced estimates of the qubit count needed to break RSA-2048 from roughly 20 million qubits down to under 1 million — a 20x reduction in the estimated barrier. The window is narrowing.

Why AI is a uniquely valuable HNDL target

Not all encrypted data is equally worth harvesting. HNDL rewards data whose secrecy has long-term value. AI artifacts score exceptionally high on that dimension.

The Cloud Security Alliance’s 2025 research on AI infrastructure and HNDL puts it plainly: a single future decrypt can yield both the model and the private data it learned from. That combination — weights plus training data — is a complete picture of an organization’s proprietary AI investment.

RSA-2048 and ECC P-256 are already on NIST’s deprecation schedule: deprecated by 2030, fully disallowed by 2035. Large enterprises face migration timelines of 12–15 years. If Q-Day arrives by 2030 and you start migrating in 2028, the math does not work.

The vulnerability: today’s public-key cryptography

To understand why HNDL is real rather than theoretical, you need to understand what a quantum computer actually breaks.

Classical encryption that protects most AI data in motion and at rest relies on two mathematical hard problems:

1. RSA — integer factorization: multiplying two large primes is easy; factoring the product is computationally intractable on classical hardware.
2. ECC (Elliptic Curve Cryptography) — the discrete logarithm problem over elliptic curves.

Shor’s algorithm, published in 1994, solves both of these problems in polynomial time on a sufficiently large quantum computer. A classical computer would take longer than the age of the universe to factor a 2048-bit RSA key. A large enough quantum computer could do it in hours.

Symmetric encryption (AES-256) and hash functions (SHA-3) are much more resilient: Grover’s algorithm provides a quadratic speedup for searching, which halves the effective key length — but AES-256 degraded to AES-128-equivalent is still strong. The HNDL threat primarily targets the key exchange and signature mechanisms that wrap your data, not the symmetric cipher inside.

What quantum breaks:
  RSA key exchange .............. vulnerable (Shor's algorithm)
  ECDH / ECDSA .................. vulnerable (Shor's algorithm)
  Diffie-Hellman ................ vulnerable (Shor's algorithm)

What quantum does NOT break (in the near term):
  AES-256 ....................... weakened but not broken (Grover)
  SHA-3 / SHA-256 ............... weakened but not broken (Grover)

The implication: the TLS sessions protecting your model weights in transit, the RSA-wrapped keys protecting your training data at rest, and the ECC signatures proving your model files have not been tampered with — all of these are the attack surface.

The structural fix: crypto-agility

Once you understand the problem, the temptation is to ask: “which algorithm should I switch to right now?” That question contains a subtle error. The right question is: “how do I build my system so that switching algorithms is cheap?”

Crypto-agility is the architectural property that lets you swap cryptographic algorithms — the specific cipher, key-encapsulation scheme, or signature algorithm — without tearing down your application logic and rebuilding it from scratch.

Brittle (NOT crypto-agile):
  application code
      |
      +-- hardcoded: RSA-2048 for key exchange
      +-- hardcoded: ECDSA for signing
      +-- hardcoded: AES-128-CBC for storage
  
  To change any of these, you rewrite the application.

Crypto-agile:
  application code
      |
      +-- crypto provider abstraction (policy-driven)
              |
              +-- algorithm slot: [ ML-KEM-768 ]  <-- swappable
              +-- signature slot: [ ML-DSA-65 ]   <-- swappable
              +-- symmetric slot: [ AES-256-GCM ]  <-- swappable
  
  To migrate, you update the policy; the application is unchanged.

Crypto-agility is the structural defense because it reduces the migration cost to near-zero, meaning you can respond to new threat intelligence or new standards without a multi-year re-architecture project. Organizations building AI infrastructure without crypto-agility are accumulating technical debt that will force costly retrofits — potentially during a crisis window.

The NIST National Cybersecurity Center of Excellence (NCCoE) has a dedicated migration-to-PQC project that provides reference architectures and discovery tooling for building crypto-agile systems.

The post-quantum standards: FIPS 203, 204, and 205

On August 13, 2024, NIST finalized the first three post-quantum cryptography standards, concluding an eight-year standardization process that began in 2016. These are the algorithms to migrate toward.

Each fills a specific role in the cryptographic stack:

FIPS 203 ML-KEM replaces RSA and ECDH for key encapsulation. When your AI service and a client negotiate a session key, ML-KEM is the post-quantum drop-in. This is the most critical migration for protecting data in transit — training pipelines, inference traffic, model downloads.

FIPS 204 ML-DSA replaces ECDSA for digital signatures. This protects model signing: the process of cryptographically asserting that a model artifact was produced by a specific party and has not been modified. See AIBOM and Model Signing for why model signing matters in the AI supply chain.

FIPS 205 SLH-DSA is a second signature standard based on completely different math — hash functions rather than lattices. Its role is insurance: if a cryptographic breakthrough were found in lattice-based algorithms that compromised both ML-KEM and ML-DSA, SLH-DSA remains unaffected. Use it where you need a conservative backup or where regulatory requirements mandate algorithm diversity.

The standard-to-role mapping is worth committing to memory:

FIPS 203 = ML-KEM  = KEY EXCHANGE  (one standard)
FIPS 204 = ML-DSA  = SIGNATURES    (lattice-based)
FIPS 205 = SLH-DSA = SIGNATURES    (hash-based backup)

How to defend: a layered migration plan

Defending against HNDL is not a single patch. It is a phased migration built on a crypto-agile foundation. Here is a practical sequencing:

Step 1 — Inventory your cryptographic dependencies (now)

You cannot migrate what you cannot find. Deploy cryptographic discovery tooling across your AI infrastructure to locate every RSA, ECDH, and ECDSA usage. Prioritize:

• TLS configurations for model training pipelines and inference endpoints
• Key management infrastructure (KMS, HSMs, vaults)
• Model artifact signing and verification toolchains
• Cloud storage at-rest encryption key wrapping

Step 2 — Adopt crypto-agility before you migrate (0–6 months)

Refactor your cryptographic layer into a swappable abstraction before choosing specific PQC algorithms. This investment is the force multiplier: every future algorithm upgrade becomes a configuration change, not a rewrite.

Step 3 — Migrate signing first (6–12 months)

Move model artifact signing to ML-DSA (FIPS 204). This protects the integrity of your deployed models and defends the supply chain. Re-sign existing long-lived model artifacts with the new scheme. See AIBOM and Model Signing for tooling context.

Step 4 — Migrate key exchange for high-sensitivity channels (12–24 months)

Upgrade TLS on the highest-sensitivity channels — training data ingestion, model weight transfer, embedding pipeline — to hybrid configurations that support ML-KEM (FIPS 203). Hybrid TLS runs both a classical key exchange and a PQC key exchange simultaneously, so you are protected if either algorithm is later found to be vulnerable. This is the recommended transitional posture.

Step 5 — Complete cryptographic inventory and full migration (24–36+ months)

Align remaining systems to NIST timelines: RSA-2048 and ECC P-256 are deprecated by 2030 and fully disallowed by 2035 under NIST guidance.

One last point: this is one advanced control on a fully-defended board. Do not let post-quantum planning crowd out input validation, least privilege, model signing, or access controls — the attacks covered throughout this series that are exploitable right now, today, with classical computers.

Common misconceptions

• “Quantum computers don’t exist yet, so I can wait.” HNDL attacks do not require quantum computers to exist — only for the adversary to believe they will exist eventually. Harvesting is cheap and irreversible. Data captured today under RSA encryption will be just as vulnerable to a 2030 quantum computer as data captured in 2029. The attack is already in its first phase.
• “Switching to AES-256 solves this.” AES-256 for symmetric encryption is relatively resilient to quantum attacks (Grover’s algorithm reduces it to roughly AES-128 strength, which is still strong). But AES is not the problem: RSA and ECC handle key exchange and signatures, and those are broken by Shor’s algorithm. Migrating symmetric ciphers without addressing key exchange is incomplete.
• “Post-quantum cryptography is too slow to use in production.” Early PQC implementations had performance concerns, but FIPS 203 ML-KEM and FIPS 204 ML-DSA have been extensively optimized. NIST’s 2024 finalization included implementations that are competitive with classical alternatives for most AI infrastructure use cases. Hardware acceleration for PQC calculations is expected to become broadly available from 2026 onward.
• “My cloud provider handles all this for me.” Cloud providers are migrating their infrastructure, but the cryptographic choices made in your application layer — how you sign models, how you transfer training data between services, how you wrap keys in your key management code — are your responsibility. A crypto-agile application on a PQC-ready cloud is the goal; cloud alone is not sufficient.

Frequently asked questions

What exactly is a cryptographically relevant quantum computer (CRQC), and how far away is it? A CRQC is a quantum computer powerful and error-corrected enough to run Shor’s algorithm against real-world key sizes — RSA-2048, ECC P-256. Current quantum computers have too many errors and too few qubits to achieve this. Estimates vary widely, but Forrester (2026) characterizes CRQCs as plausible by 2030. The important nuance: “plausible by 2030” means migration needs to begin now, because enterprise cryptographic migrations routinely take 12–15 years for large organizations. The uncertainty in the Q-Day timeline cuts in the direction of acting early, not waiting.

Which of my AI systems should I migrate first? Prioritize by asset longevity and sensitivity. Model weights that encode years of proprietary training are the top priority for storage encryption and signing. Training datasets containing PII or medical data are the second priority, especially if subject to long regulatory retention periods. Inference endpoints serving sensitive decisions are third. Internal tooling and staging environments come last. If you have to triage, protect what you would most regret losing.

What is hybrid TLS, and should I use it now? Hybrid TLS runs a classical key exchange (ECDH) and a PQC key exchange (ML-KEM) simultaneously, combining both derived keys. The connection is secure if either algorithm holds. It is the recommended transitional posture because it provides immediate PQC protection while maintaining compatibility with infrastructure that has not yet deployed PQC. For high-sensitivity AI data channels, hybrid TLS with ML-KEM is a concrete step you can deploy today.

Does post-quantum cryptography protect against all quantum attacks on AI? No. PQC addresses one specific threat: the ability of a quantum computer to break public-key cryptographic algorithms using Shor’s algorithm. It does not protect against adversarial examples, data poisoning, prompt injection, model extraction, or any of the other attacks covered in this series. PQC is the defense for the cryptographic layer that protects stored and transmitted AI artifacts. The rest of your defense architecture — input validation, access controls, monitoring, red-teaming — remains fully necessary and is not addressed by PQC.

Is FIPS 205 SLH-DSA necessary, or can I just use FIPS 204 ML-DSA for all signatures? For most organizations, ML-DSA (FIPS 204) is the primary signature algorithm to migrate toward. SLH-DSA (FIPS 205) matters as an insurance policy: it is based on the security of hash functions, not lattices, so it survives any cryptographic breakthrough that might affect lattice-based schemes. High-assurance environments — government, critical infrastructure, long-duration archives — should include SLH-DSA. For most AI product teams, ML-DSA first, then evaluate SLH-DSA for long-lived artifact signing.

Where this fits in the series

This is the final episode of the Securing AI series. You started at The AI Attack Surface Explained, which mapped every stage and plane of the AI threat landscape. This tutorial covers the cryptographic plane that wraps those stages — the protection that, if it fails in the future, exposes every long-lived secret you produce today.

If you have arrived here without following the full series, the essential companion tutorials are AI Governance for Builders: NIST AI RMF and the EU AI Act for the compliance context, AIBOM and Model Signing for supply-chain integrity, and The Architecture of a Secured AI System for how PQC-protected cryptographic controls slot into a complete defense posture.

Browse all tutorials to follow the full series from the attack surface map to this series finale.