Deciding
Worked example: prioritizing three data classes
Run health records, a firmware signing key, and session analytics through the full chain, and come out with a defensible priority order.
6 min read
What you'll be able to do
- Apply the full reasoning chain to concrete, contrasting data classes.
- Distinguish a genuine HNDL priority from a future-forgery priority within the same worked example.
- Produce a defensible priority order and state the reasoning behind each ranking, not just the ranking itself.
The chain only proves useful when it is run on something specific. Take three data classes an organization plausibly holds at the same time: patient health records, a firmware code-signing key, and session analytics. Each goes through the same questions: how long must it stay confidential, where can it be captured, and what cryptography actually protects it.
| Data class | Confidentiality lifetime (X) | Harvestable today? | What protects it |
|---|---|---|---|
| Health records (backups, replicated to a third-party analytics platform) | Decades | Yes — third-party custodian, long retention | Backup encryption key wrapped by a key established through classical RSA key transport |
| Firmware signing key (signs released firmware images) | Not an HNDL question — see below | Not applicable to confidentiality | An RSA or ECDSA signing key |
| Session analytics (short-lived click and session data) | Hours to weeks | Partially — passes over the internet in transit | Hybrid TLS key exchange on ingest; classical-only on one internal replication hop |
The firmware signing key does not belong in an HNDL ranking at all, and that is worth saying out loud rather than leaving implicit: a signature already verified cannot be retroactively forged, so capturing signed firmware today creates no future decryption risk. The key still needs migration, but on the future-forgery timeline, driven by how long that root of trust must keep being trusted against a future CRQC, not by a confidentiality lifetime it does not have.
- 01
Health records — lifetime
Decades of required confidentiality, and roughly none of it has elapsed for recently collected records.
- 02
Health records — harvestability
A third-party analytics platform holds a replicated copy with its own retention policy — a plausible, durable capture surface independent of the primary system.
- 03
Health records — protection path
Traced to a backup encryption key wrapped by a key established through classical RSA key transport — quantum-vulnerable.
- 04
Health records — verdict
Long X, confirmed harvestability, and a quantum-vulnerable protecting mechanism: this is the clearest HNDL exposure of the three, and the one Mosca's inequality would flag first regardless of the exact value of Y.
Session analytics run through the same variables and land somewhere else entirely: a short confidentiality lifetime measured in hours or weeks, partial harvestability limited to one internal hop that has not yet moved to hybrid key exchange, and a protecting mechanism that is already hybrid at the point most exposed to the internet. Even with an unresolved gap on the internal hop, the short lifetime alone caps how much urgency this data class can carry.
RelixQ's QAST runs this same chain across a full inventory automatically; this lesson works it by hand once so the reasoning behind an automated verdict is never a black box.
Marking a lesson complete only updates this browser.