Risk & Data Classification

Key insight

Prioritise by data shelf life first: long-lived secrets are already being harvested, so they push Mosca’s X + Y > Z into the present. Then build a full risk score combining sensitivity/shelf-life, exposure type (confidentiality vs authenticity, with long-lived trust anchors weighted heavily), and how hard the system is to change (which raises migration time Y). The result is a ranked register: high-sensitivity, long-shelf-life, hard-to-change systems go first.

In one sentence

Fix the riskiest things — long-lived, sensitive, hard-to-change — before the easiest, and let data shelf life, not gut feel, set the order.

Data shelf life: the master lens

For each thing a system protects, ask: how long must this stay secret? A password rotating next month has a shelf life of weeks. A medical record, a state secret, or a root key might need 20, 30, or 50 years. Long-shelf-life data is the harvest-now nightmare — it’s being stolen today to be read after Q-day, so it’s already at risk.

Mosca’s inequality, applied

X + Y > Z ⇒ you’re already exposed

Term	Meaning	What raises it
X	How long data must stay secret	Long-shelf-life data (records, secrets, keys)
Y	How long migration takes	Hard-to-change systems (embedded, vendor, legacy)
Z	Time until a capable quantum computer	(Estimated; shrinking with progress)

Classification’s first job is to sort data by shelf life, because long X drags your effective deadline into the present.

Building a risk score

Shelf life isn’t the only factor. Combine three:

Factor	Question	Effect
Sensitivity & shelf life	How secret, for how long?	Drives X
Exposure type	Confidentiality (harvested) or authenticity (forgeable key)?	Long-lived trust anchors weighted heavily
Difficulty to change	Agile service vs 20-year embedded device?	Drives Y

A rough score: Risk ≈ Sensitivity × ShelfLife + AnchorWeight + Difficulty. You don’t need precision — you need a defensible ordering.

To make that usable, put each factor on a simple 1–5 scale, then apply the formula. Suggested anchors:

Factor	1	5
Sensitivity	public / trivial	regulated, breach-catastrophic
ShelfLife	< 1 year	10+ years
Difficulty	config-flag change	vendor / hardware / protocol change
AnchorWeight	0 (not a trust anchor)	+5 (long-lived root / firmware-signing key)

AnchorWeight is a flat additive bump, not a multiplier — add +5 for any long-lived trust anchor (a root CA, a code- or firmware-signing key) so it floats to the top of the list regardless of its other scores, because a forged anchor is catastrophic. Everything else scores 0.

Worked example. A firmware-signing root: Sensitivity 5, ShelfLife 5, Difficulty 5, AnchorWeight +5 → (5×5) + 5 + 5 = 35. A one-hour session token behind a config flag: Sensitivity 2, ShelfLife 1, Difficulty 1, AnchorWeight 0 → (2×1) + 0 + 1 = 3. Decision rule: sort descending and work top-down — the 35 is first-wave, the 3 can wait. The absolute numbers don’t matter; the ordering does, and it’s defensible because every input traces back to a documented question.

Long-lived and hard-to-change = your first wave. Short-lived and easy can wait.

Simple classification bands

Band	Shelf life	Examples
Critical	10+ years	Health/financial records, state secrets, root & firmware keys
High	3–10 years	Contracts, IP, long-term customer data
Moderate	1–3 years	Operational data, most business records
Low	< 1 year	Ephemeral sessions, short-lived tokens

From inventory to register

Score every CBOM entry, sort descending, and you have a risk register — a ranked, defensible sequence of work with owners and target dates. This register is what the migration roadmap turns into waves.

Data shelf life: How long a piece of data must remain confidential.
Mosca’s inequality: X + Y > Z: if secrecy need plus migration time exceeds time-to-quantum, you’re exposed.
Trust anchor: A long-lived root or firmware key; forging it is catastrophic.
Risk register: A ranked list of cryptographic exposures with owners and deadlines.
CBOM (Cryptographic Bill of Materials): The cryptographic inventory whose entries you score to build the register.
CA (Certificate Authority): The issuer of certificates; a root CA is a long-lived trust anchor that scores highest.
IP (Intellectual Property): Proprietary information (designs, source, trade secrets) that often needs multi-year confidentiality.

What to carry forward

Data shelf life is the master lens — long-lived data is already at risk.
X + Y > Z: long X (shelf life) and long Y (hard to change) both pull the deadline forward.
Risk score = sensitivity/shelf-life + anchor weight + difficulty.
First wave = long-lived AND hard-to-change; short-lived, easy can wait.

Next: Assessing Cloud, Identity, Apps & Network → — where to actually look.

Understand it in your own words

Paste into any AI assistant to check yourself:

I'm learning how to prioritise post-quantum migration. Quiz me one question
at a time, correcting me gently:

1. What is "data shelf life" and why does long shelf life mean a system is
   already at risk?
2. State Mosca's inequality and say what raises each of X, Y, and Z.
3. What three factors go into a full risk score?
4. Why do long-lived trust anchors get extra weight?
5. Which quadrant of (shelf life x difficulty) is the first wave, and why?

References & further reading

M. Mosca, Cybersecurity in an era with quantum computers (the X+Y>Z framing). eprint.iacr.org/2015/1075
CISA, NSA & NIST, Quantum-Readiness: Migration to PQC — prioritisation guidance. cisa.gov/quantum
NIST, SP 800-60: Guide for Mapping Types of Information to Security Categories. csrc.nist.gov/pubs/sp/800/60
Canadian Centre for Cyber Security, Preparing your organization for the quantum threat. cyber.gc.ca