Harvest now, decrypt later (HNDL)

An adversary who cannot break RSA today does not need to. They intercept the traffic, exfiltrate the encrypted data, and put it somewhere. Storage is cheap and patience is free. When a cryptographically relevant quantum computer arrives, they decrypt everything they collected.

Nation-state actors are widely assumed to be doing this already. The attack requires no quantum computer. It just requires a hard drive.

The exposure math is an inequality, usually attributed to Michele Mosca — who co-founded the Institute for Quantum Computing at Waterloo, and whose reasoning helped justify NIST’s decision to standardize post-quantum algorithms through open competition:

Confidentiality horizon + migration time > time until a quantum computer

If that inequality holds for a given data set, you will still be migrating when the quantum computer shows up — and everything captured by an attacker in the interim becomes readable. Finishing the migration does not undo that. It protects what you encrypt from that day forward, and nothing that was copied onto somebody else’s storage array last year. Which is the genuinely unpleasant thing about HNDL: by the time you can prove it happened, the proof is worthless.

Now look at the first term. How long must this data stay confidential? Nobody on your PKI team can answer that. It is a data classification question — and it is the one variable almost nobody is measuring.

Not all data deserves the same attention

HNDL only threatens data with a long confidentiality horizon. Your Q3 forecast, your session tokens, your shipping manifests — by the time anyone decrypts them, the forecast is a historical curiosity, the token expired in 2027, and the package arrived. If a foreign intelligence service spends fifteen years and a national quantum program to learn your Tuesday pricing, you have won.

Protected health information. Genomic sequences. Social Security numbers. Source code. Trade secrets. M&A material. Sealed legal records. Biometric data. Long-lived credentials somebody swore they would rotate. These stay sensitive for twenty years or more. Your genome, in particular, has a poor rotation policy.

That is where the risk concentrates, so the prioritization variable is data shelf life. And your CMDB does not know it. Your CMDB knows APPSRV-04 is “Tier 2,” a designation applied in 2019 by someone who most likely since left the company.

The CBOM inventory is just the start

A Cryptographic Bill of Materials (CBOM) inventories every algorithm, key, certificate, and protocol used by a single piece of software. Built on CycloneDX 1.6 — the same standard as the SBOM (Software Bill of Materials) — it drops into pipelines you already run. IBM’s open-source CBOMkit generates one, as does cdxgen and a growing crowd of vendors who noticed that “CBOM” fits nicely on a booth banner. It is real, it is standards-based, and if your CI pipeline already generates an SBOM it is largely a matter of turning it on. This is why every post-quantum program starts here but should not end there.

CBOM is also a minority of your cryptographic estate. A CBOM covers code you wrote and can rebuild. It does not see purchased or SaaS applications. It does not see mainframe, or the middleware layer that three people understood and two of them retired. It does not see what cipher suite two systems actually negotiated at runtime. It does not see certificates on load balancers, keys in HSMs, or database TDE.

A CBOM lists what the scanner found; it does not list what the scanner missed. An application with no cryptography and an application the scanner could not parse produce the same file, and the difference between them is a decade of remediation.

This is why cryptographic posture platforms ingest rather than scan. IBM Guardium Cryptography Manager pulls from network scanners, Vault, Qualys, Nessus, and CBOM output through a plug-in framework, then normalizes and scores what arrives. It is an excellent aggregation layer. But it only knows what the scanners feed it, and most demos that makes it look like discovery was quietly skipped, the months somebody spent tuning those scanners are overlooked.

DSPM is the missing input your PQC migration plans

Every crypto posture platform ranks its finding. The formula is, roughly:

Exploitability = violation severity × business criticality

Severity is objective. RSA-2048 is quantum-vulnerable no matter who’s it is — so the platform can score it without knowing anything about your data.

Business criticality is supplied. No scanner can discover it. There is no packet you can send that returns how much a company cares about a database. So, it comes from that CMDB field, or an architect’s reasonable guess.

A measured number times a guessed number is a guessed number. That product should not be your roadmap.

Data security posture management (DSPM) fixes precisely this. DSPM knows which data stores hold twenty-year data, and whether a bucket contains ten records or four million — a distinction no certificate scanner will ever make. Paired with DLP flow telemetry, it knows which sensitive data crosses interceptable networks, and which of it walks out to a third party entirely.

Feed that into the criticality variable and the exploitability score stops being a proxy and becomes a measurement.

Two inventories, no shortcuts

Be clear about the limits, because this industry often is not. Most DSPM platforms do not discover cryptographic algorithms; they discover data. Any vendor claiming their DSPM performs post-quantum discovery is overselling, and any vendor claiming a CBOM constitutes your cryptographic inventory has not met your mainframe. Although we do know of a few DSPM vendors that can discover encryption keys, secrets and algorithms as well as data.

The value lives in correlating two inventories. No single product spans both. That correlation is work someone has to own — it is the part we do best at Adaptive Systems — and it belongs in the plan and the budget from the start, not discovered in month eight.

Mosca makes a broader point better than most: the quantum threat is the most visible symptom of a general fragility. What you are really building is the ability to change algorithms without an eighteen-month project. Quantum is the forcing function; crypto-agility is the deliverable, and it holds its value even in the timeline where the quantum computer stays perpetually five years away. He also supplies the best line in the discipline: hope and luck are not strategies.

Most organizations begin by asking what cryptography they have. A reasonable question. It produces a large, expensive, unsortable list.

The better first question is which of your data will still be sensitive in 2045 — and whether any of it is crossing the wire this afternoon.

The first question produces an inventory. The second produces a plan.

We run this as a working session for security teams — two hours, your estate, no slideware about lattice cryptography. You leave knowing which of your data has a twenty-year horizon and which of your crypto is protecting it. If that’s useful, get in touch.

Raj Soni is founder of Adaptive Systems, which builds cryptographic and data inventories for regulated enterprises. Reach him at info@adaptivesystemsinc.com.