Harvest now, decrypt later: a data-lifetime model for PQC priority.

The model assumes an adversary can collect ciphertext now, retain it, and attempt decryption later if a cryptographically relevant quantum computer can attack the public-key mechanism that protected session-key establishment. OMB M-26-15 states that a CRQC is not yet known to exist. RFC 9794 likewise notes that predictions vary, while warning that information encrypted today can be stored for a future attack.

Those statements support preparation without a fabricated countdown. The planning question is whether the information will still matter when an attacker might gain new capability, and whether the organization can replace the vulnerable path before that risk window overlaps. A precise program records assumptions and uncertainty rather than converting an unknown CRQC date into a marketing deadline.

The first clock is the useful confidentiality lifetime: how long disclosure would still create material harm. The second is migration lead time: how long it takes to discover dependencies, obtain protocol and product support, test interoperability, rotate trust material, deploy, verify, and retire the old path. The third is the uncertain time until an adversary can perform a relevant attack.

If confidentiality lifetime plus migration lead time can reach beyond the assumed capability horizon, the flow deserves earlier action. This is a prioritization heuristic, not a probability formula and not an official forecast. Use scenario ranges and sensitivity analysis: a decision that changes completely when an arbitrary CRQC estimate moves by one year is not robust enough for a long-lived security program.

A dataset may cross several cryptographic boundaries: user device to edge, edge to application, service to service, application to backup, export to partner, and replication into a managed platform. Each hop can use a different endpoint, certificate, termination point, library, vendor, and key lifecycle. HNDL exposure follows the capture opportunity along those paths, not the database label alone.

For each flow, record the information category, retention and deletion policy, future value to an adversary, origin and destination, public-key mechanism, termination owner, passive capture opportunity, copies and archives, supplier control, and replacement lead time. Also ask whether minimization, tokenization, shorter retention, segmentation, or application-level protection can reduce exposure before a protocol migration completes.

Harvest-now-decrypt-later primarily describes confidentiality: an attacker stores encrypted material and later defeats the vulnerable public-key step used to establish protection. That is why U.S. Executive Order 14412 and OMB M-26-15 place post-quantum key establishment for high-value and high-impact federal systems on a December 31, 2030 milestone, ahead of the December 31, 2031 milestone for digital signatures.

Signatures still carry serious quantum risk, but the failure mode differs. A future attacker may forge identity, software, firmware, certificates, or records, while long-lived roots of trust may be difficult to replace. Do not bury signature work inside an HNDL score. Maintain linked but separate confidentiality and authenticity tracks, each with its own lifetime, dependencies, protocol readiness, validation needs, and acceptance evidence.

Teams can act before every end-state standard is ready. Build the cryptographic inventory, locate long-lived data flows, reduce unnecessary collection and retention, tighten access to archives, segment capture paths, confirm modern symmetric protection, and obtain dated vendor roadmaps. Where a suitable standards-based implementation and protocol path exist, run a bounded post-quantum or PQ/T hybrid pilot with explicit approval and rollback.

A pilot must protect the actual hop under study rather than merely execute an algorithm benchmark. Record endpoints, negotiated group, library and module versions, certificate and key path, packet-size and latency behavior, middlebox compatibility, failure handling, fallback, telemetry, and whether the old vulnerable route remains available. The result is evidence about one trust boundary, not a claim that the enterprise is quantum-safe.

For each prioritized flow, preserve which data and path were assessed, the confidentiality-lifetime basis, known capture surfaces, current cryptography, migration dependencies, vendor evidence, capability-horizon scenarios, available mitigations, selected action, residual risk, owner, approver, and review trigger. Keep the source date visible because policy and protocol status will change during a multi-year program.

This record prevents two distortions. The first is alarmism, where every encrypted flow receives the same urgent label. The second is complacency, where uncertainty about quantum timelines becomes a reason to ignore information that must remain secret for decades. Evidence permits proportional decisions and makes later changes auditable when assumptions move.

Leadership reporting should distinguish observed facts, external requirements, planning assumptions, and open dependencies. Facts include the inventory coverage, known algorithms, retention periods, vendor statements, and tested protocol behavior. Requirements include the rules that actually apply to the organization. Assumptions include CRQC scenarios. Open dependencies include standards, suppliers, budgets, and hardware refresh cycles.

A useful statement is that certain long-lived flows are prioritized because their confidentiality horizon and migration lead time create exposure under plausible scenarios. An unhelpful statement is that all present encryption will fail in a named year. The first supports funded work and review; the second creates false certainty and will age badly as science, standards, and systems evolve.