up:: Quantum Risk Models MOC

The Shelf-Life Question

The shelf-life question is the measurement that produces the X in Mosca’s theorem: one sentence, put to the business owner of a piece of data, in these words: “If this were published in full tomorrow, on what date does it stop hurting us?” The answer year minus the current year is X, the number of years the data must stay SECRET, which runs on a separate clock from retention, the number of years you must KEEP it. Confusing those two clocks is the single most common way an organization mismeasures its own quantum exposure, because retention schedules are written down everywhere and secrecy lifetimes are written down almost nowhere.

The short version:

• The exact words matter: ask the business owner of the data, “If this were published in full tomorrow, on what date does it stop hurting us?” Answer year minus this year equals X, the secrecy shelf life.
• Secrecy and retention run on separate clocks. Retention measures how long you must keep a record so it can be produced on demand; the shelf life measures how long a stolen copy stays dangerous.
• Route the question to the business owner, because the security team will read back the retention schedule, and retention points the opposite direction from harm as often as it agrees with it.
• Two guards: the longest-lived record sets the whole bucket, because averaging is how exposure vanishes from reports, and signing keys carry a shelf life too, measured in unforgeability rather than secrecy.
• X near zero is an honest, useful answer. The question exists to clear data off the worry list as much as to put it on.

Think of a film studio. The script of a movie that premiered a decade ago sits in the archive permanently, and anyone can quote it, because its secrecy ended on opening night. The single-page treatment for the unannounced sequel might be scheduled for shredding next quarter, and it’s still the most damaging leak in the building. The archive schedule and the damage schedule are two different clocks, and the shelf-life question reads the second one.

What is the shelf-life question?

The shelf-life question is a named measurement tool with 3 parts: a fixed wording, a fixed respondent, and a fixed arithmetic.

1. The wording. “If this were published in full tomorrow, on what date does it stop hurting us?” Every word is load-bearing, and the walk-through below explains why.
2. The respondent. The business owner of the data: the deal lead, the treasurer, the head of product, the chief medical officer. The security team is deliberately the wrong respondent, for reasons covered in its own section.
3. The arithmetic. Answer year minus the current year equals X. An owner who says “2036” in 2026 has given you an X of 10.

X is the first of the 3 variables in Mosca’s theorem, the timing rule X + Y > Z that decides whether a migration is already late. The shelf-life question is the X half of a matched pair: The Receipt Method measures Y, your real migration speed, the same way, from record rather than estimate. Michele Mosca posed the underlying timing problem, how long data must remain secure against how long re-tooling takes against how long the cryptography holds, in the paper that gave the inequality its name.

Source: Michele Mosca, “Cybersecurity in an era with quantum computers, will we be ready?”, IACR ePrint 2015/1075, eprint.iacr.org, which defines x as “the security shelf-life,” y as “the migration time,” and z as “the collapse time,” and states the condition as “If x + y > z, we have a serious problem today.” The 2015 paper restates the inequality and credits it to Mosca’s earlier 2013 ETSI workshop remarks, so it is where the rule is set out rather than where it first appeared.

The question applies to any data class being triaged for quantum exposure, and, reworded for unforgeability, to every signing key in the estate. It measures exactly one variable: X alone decides nothing, and it earns its keep only next to a measured Y and a published Z band, which is what The Mosca Inequality, Worked assembles end to end.

Why is retention the wrong number for X?

Retention is a records-management number. A regulator, an auditor, or a court may demand the record, so the law or the records policy fixes a period during which you must be able to produce it, and the schedule ends in authorized deletion. Its authority is a statute; its enforcement mechanism is storage.

The secrecy shelf life is a harm number. It measures how long the content would damage the company, its customers, or its partners if an adversary could read it, and it ends when the harm dies of old age. Its authority is business reality; its enforcement mechanism is cryptography, plus the discipline about what gets transmitted and archived at all.

The two clocks routinely point in opposite directions. Published marketing content is kept indefinitely and stopped being secret the day it shipped: long retention, zero shelf life. An unannounced acquisition file may be scheduled for deletion within a few years and would still reprice every future negotiation if it leaked: short retention, long shelf life.

Under harvest-now-decrypt-later, the gap between the clocks turns expensive, and the cleanest illustration is a real retention mandate:

1. A bank operating in Australia keeps transaction records for 7 years, because the AML/CTF Act requires it.
2. An adversary records the encrypted traffic carrying those transactions in year 1. Collection is passive, and the harvested copy sits outside every system the bank controls.
3. In year 8 the bank deletes the record, exactly on schedule. The harvested copy never hears about it.
4. Whenever the key establishment protecting that traffic falls, the copy opens, and the harm clock, set by the customers and counterparties named in the record, is still running.

Source: Anti-Money Laundering and Counter-Terrorism Financing Act 2006 (Cth), Part 10 (record-keeping), 7-year retention requirement, legislation.gov.au.

Retention answers how long the record can be demanded from you. The shelf life answers how long a copy taken from you keeps its teeth. Mosca’s X is the second number, and reading the first one into the formula quietly understates exposure for every long-lived class in the estate.

Who should answer the shelf-life question?

The business owner of the data, every time. The routing rule matters as much as the wording, because the two candidate respondents hold two different bodies of knowledge.

The security team holds custody knowledge: the retention schedule, the classification labels, the handling rules, the deletion calendar. Every one of those encodes who may touch a record today and when it leaves the building, and none of them encodes the date its exposure stops causing damage. Ask a security team for X and you get the retention schedule read back with full confidence, because that’s the number their tooling actually holds.

The business owner holds the harm model. The person who knows when a merger file stops being dangerous is the person whose career depends on that file, and they’ll usually answer inside a minute. They’ve never needed the cryptographic vocabulary, because the question contains none.

The wording earns that minute. Each clause does a specific job:

1. “Published in full” removes the partial-breach daydream. The owner prices total exposure rather than negotiating about which pages matter.
2. “Tomorrow” removes probability. The likelihood debate, the usual swamp of every risk conversation, ends before it starts, and the owner prices pure consequence.
3. “On what date does it stop hurting us” forces a number rather than a feeling, in the owner’s own currency: deals, patients, customers, negotiating position.

Then the arithmetic: answer year minus this year, written down with the owner’s name and the date they said it. The provenance turns out to matter as much as the number, which is where the boardroom section picks up.

How do you run it on real data classes?

A worked pass over a generic mid-market company shows the full range of honest answers. Three data classes, three owners, three X values.

1. Marketing content. The CMO gets the question about the published content library and answers immediately: “It stopped hurting us the day we shipped it.” X = 0. That zero is a result, and it clears the class off the quantum worry list entirely, consistent with the de-scope in What Data Is Vulnerable to Harvest Now, Decrypt Later.
2. M&A records. The corporate-development lead thinks for a moment: announced deals stopped hurting at announcement, but the valuation models and the negotiation record keep pricing the company’s future deals until the current cycle exits. “Call it 2029.” X = 3.
3. Long-term customer PII. The product owner realizes mid-sentence that dates of birth and national ID numbers hurt for as long as the customer is alive, because the fields never change and identity theft has no statute of limitations on usefulness. For the youngest customers, the answer is the customer’s lifetime, and X lands in decades.

The sort falls out of the X column alone, before anyone opens a cryptographic inventory: the PII archive ahead of the deal room, the deal room ahead of the marketing CDN. Feeding those X values into X + Y > Z next to a Y measured by The Receipt Method and a published Z band is the step The Mosca Inequality, Worked walks in full, and the lifetime-class data fails the inequality under any plausible Y and Z before the argument even gets interesting.

How do retention and secrecy shelf-life compare across data classes?

The table below shows the pattern across illustrative categories. The retention column carries the citable anchors; the shelf-life column carries the reasoning, and it’s deliberately reasoning rather than statistics, because the whole point of the framework is that your own owners supply the dates.

Data class (illustrative)	Typical retention anchor	Realistic secrecy shelf life	What actually sets the shelf life
Published marketing content	Kept indefinitely in the brand archive	Zero. It ended on publication day	The publication date
Pre-release financials	7-year audit-record retention under the Sarbanes-Oxley implementing rule	Weeks. It ends at the earnings release	The release calendar
M&A deal file	Records policy, typically years	Months to a few years past close	The deal lifecycle and the next negotiation
Bank transaction records	7 years under Australia’s AML/CTF Act 2006	Runs with the customer relationship, often far past the retention window	The customers and counterparties named in the record
Customer identity fields (DOB, national ID)	Records policy	The customer’s lifetime. The fields rarely change	The data subject
Health records	6-year HIPAA documentation floor, with medical-record retention set by state law and often longer	The patient’s lifetime	The patient
Trade secrets	As long as they’re in use	No expiry while secrecy holds	Secrecy itself is the asset
Code-signing and firmware keys	Key-lifecycle policy	The service life of everything the key ever signed	The oldest device still in the field

Source: 17 CFR § 210.2-06 (7-year audit-record retention under Sarbanes-Oxley), govinfo.gov; Anti-Money Laundering and Counter-Terrorism Financing Act 2006 (Cth), Part 10, legislation.gov.au; 45 CFR § 164.316(b)(2)(i) (6-year HIPAA documentation retention), govinfo.gov.

Read down the middle two columns and the pattern is hard to miss: the rows where retention and shelf life agree are the boring ones, and the rows where they diverge, in either direction, are where mismeasurement lives. The full catalog of what belongs in the long-lived rows is What Data Is Vulnerable to Harvest Now, Decrypt Later.

Why does the longest-lived record set the whole bucket?

A data class inherits the X of its longest-lived record. One 30-year record inside a bucket of 3-year records makes it a 30-year bucket, because the adversary who eventually opens a harvested capture reads everything in it, and the harm concentrates in the tail rather than the middle.

Averaging is the failure mode, and it’s worth watching it happen. A bucket holds 1,000 records at 3 years and one record at 30. The weighted average computes to a tidy figure just above 3, the report rounds it, the class files as short-lived, and the one record that mattered has vanished from the document that decides migration order. Nobody lied at any step. Averaging is how exposure vanishes from reports: the average describes the typical record, while exposure is set by the extreme one, and risk reporting built on class averages systematically underreports quantum exposure for exactly the records adversaries wait longest for.

There are 2 honest ways to handle a mixed bucket:

1. The bucket inherits the maximum. Simple, conservative, and correct by default. The class’s X is 30 because its worst record’s X is 30.
2. Split the bucket. Move the long-lived records into their own class with their own owner and their own X. Usually the better call, because it keeps a handful of 30-year records from dragging a warehouse of 3-year data into the urgent migration lane, and it forces the discovery of who actually owns the long-lived tail.

The same guard settles owner disagreements. When 2 owners give different dates for the same class, the later date wins, and the disagreement itself is a hint that the bucket holds 2 different classes and wants splitting.

Do signing keys have a shelf life too?

Yes, and skipping them is the most expensive omission the framework sees. The question generalizes cleanly from secrecy to unforgeability: for a signing key, the owner-facing wording becomes “if someone could sign as us starting tomorrow, until what date does that hurt us?”

A signing key’s X is how long its signatures must stay trustworthy, and that window runs as long as the signed thing is still in service. Firmware images, software updates, certificates chained to a root certificate authority, signed audit records: each keeps its signing key’s shelf life alive for its own full deployment life. The trap is asymmetry between issuing and revoking trust. You can cut a new key in an afternoon, and the devices in the field that only trust the old root never learn about it, so the old key’s X keeps running until the last of those devices retires.

This is the trust side of quantum risk, Non-HNDL, and it runs on a different clock from harvesting: forgery waits for a CRQC to actually exist, while harvesting is collecting today. The shelf-life question prices both sides with the same arithmetic, because X is X whichever failure mode it feeds, and a code-signing key anchoring a 15-year device fleet routinely carries a longer X than most of the data in the estate.

How do you use the shelf-life question in the boardroom?

One level up, the shelf-life question converts a cryptography line-item into a table a board can interrogate. The slide is the X column with names on it: each top data class, the date its owner gave, and the owner who gave it.

Three properties make that slide survive scrutiny:

1. Every number has a named human source who is accountable for that data, so the follow-up “who says this record matters that long?” gets answered with the deal lead’s name and the date they said it, which ends the argument in a way an IT estimate never does.
2. The arithmetic is checkable in the room. Answer year minus this year. A director can re-derive any cell in seconds, and numbers a board can re-derive are numbers a board will defend later.
3. It reframes the ask. “Quantum” arrives at most boards as a technology bet. The X column converts it into a question about specific records: which of our secrets are still alive in 2035, and does their protection outlive them? The joint CISA, NSA, and NIST quantum-readiness guidance frames harvest risk around exactly this long-term confidentiality lens, so the X column also puts the estate into the language federal reviewers already use (CISA NSA NIST Quantum-Readiness Joint Guidance).

Source: CISA, NSA, and NIST, “Quantum-Readiness, Migration to Post-Quantum Cryptography,” August 2023, cisa.gov.

Pro tips

1. When the owner says “it’s public anyway,” offer to attach it to the next press release. A genuine yes means X = 0, and you record it as the useful answer it is. A flinch is the real answer, and the follow-up writes itself: “which parts would you pull back?” Those parts are the actual data class, and they get the question asked again, separately.
2. Regulatory retention floors are a minimum for X, never the value. A 7-year retention mandate is the state’s standing judgment that the record stays consequential for at least 7 years, so an X shorter than the retention period collapses under any competent review. The true X routinely runs past the floor: the customers named in a transaction record are still alive, still identifiable, and still harmed by exposure long after the mandate expires.
3. Convert “forever” into a proxy date so the arithmetic still runs. The customer’s lifetime, the end of the product’s support window, the filing date of the patent that will replace the secret. Trade secrets legitimately keep “as long as it stays secret” as their answer, and that answer goes to the top of the migration queue rather than into a date negotiation.
4. Capture the provenance with the number. Who answered, their role, the date they answered. An X with a name attached is evidence your program can stand on; the same figure re-pasted into next year’s spreadsheet with the name stripped is a guess again.
5. Ask per record type rather than per system. Systems mix classes, and asking at system granularity either hides the long-lived tail inside an average or silently assigns the archive’s worst X to an entire platform. Record-type granularity is what makes the bucket guard workable instead of punishing.

Where does the shelf-life question break?

Published limits are part of the tool, and this one has 4 honest edges.

1. Genuinely short-lived data. For ephemeral operational traffic, session chatter, and anything already public, the question returns X near zero, and that’s an honest, useful answer rather than a failure. Zeros are half the framework’s output: they clear data off the worry list with a defensible reason attached. An estate dominated by short-lived data gets most of its real quantum urgency from the signing-key side, where service lives stay long even when data lives are short.
2. Orphaned data. Some archives outlive the team that understood them, and no living owner can price the harm. The fallback is the regulatory retention floor plus the most conservative plausible reading, recorded as unowned, and the missing owner is itself the finding worth escalating: unowned long-lived data is a governance gap first, and the cryptography question is simply what exposed it.
3. Harm that lands on other people. The owner prices harm to the company, and for customer PII most of the harm lands on the data subject instead. An honest owner can still lowball X for records that wreck someone else’s life at no cost to the firm. The retention floor and privacy law backstop the number, and the question can be re-asked in the corrected frame: “on what date does this stop hurting the people in it?”
4. It measures one variable. X alone ranks data classes and does nothing else. The decision needs all 3 numbers: a Y measured from your own migration history via The Receipt Method, and a Z band from the published estimates gathered in Quantum Threat Timeline. The shelf-life question is the first third of that arithmetic, and it claims no more.

Common misconceptions

1. “X is our retention schedule.” Retention measures how long you must keep a record so it can be produced; X measures how long a copy taken from you stays dangerous. The clocks diverge in both directions, and the divergent rows are where the exposure hides.
2. “Deleting data on schedule ends the exposure.” Deletion protects the forward path only. A copy harvested from the wire in year 1 sits outside your retention system entirely and opens whenever the cryptography protecting it falls.
3. “An average X is fine for reporting.” Exposure follows the maximum, because the adversary reads the whole capture. An averaged X files the class as short-lived and erases the one record that set the real risk.
4. “Only data stamped confidential has an X.” Signing keys carry an X measured in unforgeability, and it runs as long as anything they signed remains in service, which for firmware and root certificates regularly outlasts every document in the estate.
5. “The security team owns X.” The security team owns custody: retention, labels, handling. The harm date lives with the business owner, and routing the question to the wrong desk returns the retention schedule with extra confidence.
6. “A long X means panic.” X is 1 input of 3. A long X next to a short measured Y and a comfortable Z band can still clear the inequality; the point is to find out by arithmetic rather than by mood.
7. “X is measured once.” X moves with the business. Deals announce, products launch, customer cohorts age out, support windows close. Re-ask on a fixed cadence and at every major business event, and re-date the provenance when you do.

Questions people ask

What are the exact words of the shelf-life question? “If this were published in full tomorrow, on what date does it stop hurting us?” Keep all 3 parts intact: “in full” prices total exposure, “tomorrow” removes the probability debate, and “what date” forces a number. Paraphrases that drop any of the 3 reopen the escape routes the wording exists to close.

What if the owner answers “forever”? Convert it to a proxy date so the arithmetic runs: the customer’s lifetime, the product’s end of support, the life of the process the secret describes. Trade secrets are the one class where “as long as it stays secret” stands as given, and they go straight to the top of the queue.

What if two owners give different dates for the same data? The later date wins, by the same logic that makes the longest-lived record set the bucket. Persistent disagreement usually means the bucket holds 2 genuinely different classes, and splitting it resolves the argument better than adjudicating it.

Is X the same as the classification label? A label encodes handling: who may read the record today, where it may live, how it moves. It stays silent on the date exposure stops causing harm, which is why estates full of well-labeled data still mismeasure X.

Can X be longer than the retention period? Routinely. Identity fields in a transaction record stay harmful for the lifetimes of the people named in it, decades past a 7-year mandate. The retention period is a floor under X, never a ceiling and never the value.

How does the answer feed Mosca’s theorem? Directly: X joins Y (migration time, measured by The Receipt Method) and Z (time to a relevant break) in the inequality X + Y > Z. When the sum of the first 2 exceeds the third, migration for that data class is already late. The Mosca Inequality, Worked runs the full arithmetic on realistic numbers.

How often should X be re-measured? At every major business event touching the class (a deal closing, a product sunset, a new market entry) and on an annual review otherwise. The re-ask is cheap, a minute per owner, and it keeps the provenance current, which is most of what makes the X column defensible.

Does the question apply to keys and certificates? Yes, reworded for unforgeability: “if someone could sign as us starting tomorrow, until what date does that hurt us?” The answer runs with the service life of everything the key ever signed, which is why firmware and root-CA keys usually carry the longest X in the building.

Why “stop hurting us” instead of “stop being sensitive”? Sensitivity invites a label, and labels are exactly the custody vocabulary that produced the wrong number in the first place. Hurt prices a consequence, and consequences come with dates attached.

---

Everything here is the map, given freely. When your team needs the shelf-life question run across your own estate, owner by owner, and turned into an X column your board and your regulator would both accept, that’s the work I do. Request the workshop.

Last verified 2026-08-27 · Updated 2026-08-27 · Maintained by Addie LaMarr, LaMarr Labs.