Prioritizing migration by data lifetime and HNDL exposure
Not all quantum-vulnerable systems are equally urgent. Mosca's inequality and harvest-now-decrypt-later exposure tell you what to fix first — and what can safely wait.
Sort by shelf life times harvestability, not by hostname
The first systems to migrate are those where long-lived, sensitive data crosses quantum-vulnerable key exchange on a network an adversary can record. Use Mosca's inequality — if data-confidentiality lifetime plus migration time exceeds time-to-quantum, you have a problem today — and weight it by whether the traffic is actually harvestable. Signatures rank differently: forgery risk arrives with the quantum computer, not before.
Once discovery gives you the map, prioritization decides the order of march. Done well, it puts your scarce migration effort where it retires the most risk per unit of work. Done badly — sorting by team, by convenience, or alphabetically — it burns the first quarter on systems that could have waited while genuinely exposed data keeps flowing.
The core test: Mosca's inequality
For any class of data, let X be how many years it must stay confidential, Y the years it will take you to migrate it, and Z the years until a quantum computer can break today's key exchange. If X + Y > Z, the data is still sensitive at the moment it becomes decryptable — it is at risk now, even though the break is in the future. Nobody knows Z precisely, which is the point: you plan against a conservative range, and policy deadlines encode that range for you.
- **X — shelf life.** Health records, biometric identifiers, state secrets, and long-term contracts stay sensitive for decades. Session cookies do not.
- **Y — migration time.** For a real system this is measured in months to years: find the crypto, plan, change it, and validate without breaking production.
- **Z — time to quantum.** Unknown, so treat the conservative end of published policy timelines as your planning anchor.
Weight by harvestability
Mosca tells you whether data is at risk in principle. Harvest-now-decrypt-later (HNDL) tells you whether it is being set up for compromise in practice. Traffic that crosses a network an adversary can tap — the public internet, a shared cloud fabric, an untrusted transit link — is harvestable today: recorded now, decrypted later. Data that never leaves an air-gapped enclave is far less exposed to HNDL even if the same algorithm protects it. Multiply shelf-life risk by harvestability to get the true ordering.
Key exchange before signatures — usually
Confidentiality (key exchange) and authenticity (signatures) fail on different clocks. Recorded key exchange can be broken retroactively, so its exposure is present-tense — this is why hybrid TLS is almost everyone's first move. A signature, by contrast, can only be forged once the quantum computer exists; you cannot forge retroactively. So for most estates, key establishment leads. The exception is anything with a very long verification horizon — firmware and roots of trust that must still be trusted in 15+ years — where signature migration is also urgent because the artifacts you sign today outlive the threat.
A workable scoring model
Turn the above into a repeatable score so prioritization is defensible and not a matter of taste:
- **Data shelf life** — how many years must this stay confidential or trustworthy? (Longer → higher.)
- **Exposure / harvestability** — is the traffic reachable by an adversary who can record it? (More reachable → higher.)
- **Cryptographic function** — key exchange (harvestable now) vs. signature (forgeable later) vs. symmetric (largely safe).
- **Blast radius** — how many systems and how much data depend on this asset?
- **Migration cost and dependency depth** — cheap, unblocked wins can be pulled forward even at moderate risk.
Don't over-index on symmetric crypto
AES-256 and SHA-384 are not meaningfully broken by known quantum attacks — Grover's algorithm only halves the effective key strength, and AES-256 has margin to spare. Spending prioritization energy "upgrading AES" is effort not spent on the RSA and ECC key exchange that Shor's algorithm actually breaks. Confirm symmetric key sizes are adequate, then move on.
The output of this phase is a ranked backlog that the roadmap groups into waves. Keep the scoring model versioned alongside the inventory so that when new assets are discovered, they are scored the same way and slot into the right wave without a re-litigation of first principles.