Post-Quantum Readiness: Why "Harvest Now, Decrypt Later" Is a Today Problem

The attack that already started

The unsettling part of the quantum threat is that it does not wait for quantum computers. It is called harvest now, decrypt later: an adversary records your encrypted traffic today and simply stores it. When a cryptographically relevant quantum computer exists, they decrypt the archive retroactively. Nothing needs to be broken now for you to be exposed later.

That reframes who should care. If your data has a short shelf life, maybe you can wait. But if you hold long-lived PHI or financial records — data that must stay confidential for years or decades — then traffic captured today is a liability the day quantum decryption arrives. Healthcare and fintech are precisely the profiles most at risk, which is why KollGuard treats post-quantum readiness as a compliance concern, not a science-fiction one.

What is actually vulnerable (and what isn't)

A useful thing to internalize: not all of your cryptography is at risk. Symmetric encryption like AES-256 is already considered quantum-resistant — the best known quantum attack (Grover's algorithm) only effectively halves the key strength, and AES-256 has strength to spare.

The exposed layer is asymmetric cryptography: the key exchange that sets up your TLS sessions and the digital signatures that authenticate them. RSA and elliptic-curve (ECC) are the algorithms a quantum computer would break. So "post-quantum migration" is mostly about replacing your asymmetric primitives, not ripping out everything.

The standards are finalized — and so is the clock

This is no longer a research area waiting on a spec. NIST has finalized its post-quantum standards:

• FIPS 203 (ML-KEM) — the standard for key exchange / key encapsulation.
• FIPS 204 (ML-DSA) — the primary standard for digital signatures.
• FIPS 205 (SLH-DSA) — a hash-based signature standard.
• NSA CNSA 2.0 — the National Security Agency's suite mandating these algorithms for national security systems on a defined timeline.

There is also a migration clock worth marking on a roadmap: RSA and ECC are slated to be deprecated around 2030 and disallowed around 2035. That sounds distant until you remember the harvest-now problem — data you transmit in 2026 with only classical key exchange is already at risk regardless of the 2035 date.

What KollGuard's readiness assessment does

KollGuard's Quantum Readiness assessment (currently a Preview feature) turns all of the above into something you can act on:

• A standards-mapped checklist covering the controls implied by FIPS 203/204/205 and CNSA 2.0.
• A 0–100 readiness score so you can track progress instead of guessing.
• Auto-derived controls, where KollGuard can infer some of your posture directly from scan data rather than making you fill in a form.
• Self-attestation for the controls it can't observe automatically.
• An AI-generated migration plan that sequences the work for your specific situation.

The blend of auto-derived and self-attested controls matters. Some of your PQC posture is observable from the outside — for instance, whether your endpoints already negotiate a post-quantum key exchange. The rest lives in your internal systems and processes, where an honest self-attestation is the practical source of truth.

Start before it's urgent

Crypto migrations are slow. Inventorying where you use asymmetric cryptography, finding the long-lived-data paths, and rolling out hybrid key exchange takes time you'd rather spend before a mandate, not during one. A readiness score won't migrate your systems, but it tells you honestly how far you have to go — and it counts the harvest-now clock that's already running.