Harvest Now, Decrypt Later: Why Your Encrypted Data Is Already At Risk

Most engineers think quantum computing is a future problem. It isn't — it's a present problem with a future trigger.

The attack that's already happening

"Harvest Now, Decrypt Later" (HNDL) is not theoretical. Nation-state actors and sophisticated threat groups are already capturing encrypted traffic today — TLS sessions, VPN tunnels, encrypted backups — and storing it. They don't need to break the encryption now. They just need to wait.

When a sufficiently powerful quantum computer arrives — estimates range from 8 to 15 years — every RSA and ECDSA-encrypted payload captured today becomes readable.

Today:        [Encrypted data] → Captured and stored by adversary
+10 years:     Quantum computer breaks RSA-2048
Result:        All captured data from today is now plaintext

This means data encrypted right now with RSA-2048 or ECDSA has an expiration date on its confidentiality — and that date is not decided by you.

Why this matters more than people think

Most threat models assume "if it's encrypted, it's safe." HNDL breaks that assumption for any data with a long confidentiality requirement:

Healthcare records (often need 50+ years of confidentiality)
Government and military communications
Financial transaction histories
Legal and contractual records
Audit logs that need to remain verifiable for compliance

If your data needs to stay confidential for more than a decade, it's already vulnerable — today, not in the future.

What NIST is doing about it

NIST finalized three post-quantum cryptography standards in 2024:

These are lattice-based and hash-based algorithms believed to be resistant to attacks from both classical and quantum computers.

The migration problem

Here's the part most articles skip: knowing you need to migrate isn't the same as knowing what to migrate.

Most organizations have no real inventory of where RSA, ECDSA, and other quantum-vulnerable algorithms are used in their stack. Crypto-agility — the ability to swap algorithms without architectural rewrites — is rare in legacy systems.

A practical first step: audit before you migrate

Before touching a single line of cryptographic code, you need an inventory. What algorithms are you actually running? Where? With what risk level?

curl -X POST https://vortex-dfs.onrender.com/v1/pqc/audit \
  -H "Content-Type: application/json" \
  -d '{"content": "RSA-2048 signing, ECDH key exchange, AES-128, SHA-1"}'

{
  "quantum_risk": {
    "score": 0.78,
    "band": "critical",
    "harvest_now_decrypt_later": true,
    "estimated_threat_horizon": "2030-2035"
  },
  "recommendations": [
    {
      "from": "RSA / ECDSA / DSA",
      "to": "ML-DSA (CRYSTALS-Dilithium)",
      "nist_standard": "FIPS 204",
      "priority": "critical"
    }
  ]
}

This scans any text, config file, or codebase snippet and returns a quantum risk score with specific migration recommendations mapped to NIST standards.

The bottom line

You don't need a quantum computer to be at risk from quantum computing. You need data worth protecting for more than a decade and an adversary patient enough to wait.

The migration window is now — not when the quantum computer arrives, but while there's still time to act before it does.

This post is part of ongoing research at Okamoto Security Labs on post-quantum cryptographic infrastructure. Try the audit API: okamotosecurytlabs.com.br