up:: The Human & Organizational Side MOC
The Cryptographic Risk Register
A cryptographic risk register is the entry in an organization’s enterprise risk management where quantum-vulnerable cryptography stops being a technical curiosity and becomes a tracked risk like any other, with a named exposure, a named owner, a severity, and a remediation status. It’s the artifact that carries a finding from the cryptographic inventory across the boundary into the language a board, an auditor, and a risk committee already speak. The inventory tells you what cryptography you run and where. The risk register tells you which of it is dangerous, how dangerous, who’s accountable for fixing it, and whether the fix is moving.
The short version:
- The register is where the inventory’s raw findings become governed risks: each quantum-vulnerable exposure gets a severity, an owner, a target date, and a status the organization tracks like any other risk.
- The severity of a cryptographic risk is driven by data shelf-life, so the Mosca timing calculation (how long the data must stay secret plus how long migration takes, against how long until a quantum computer arrives) is what sets the priority, not the algorithm’s name alone.
- It lives inside the risk management you already run rather than in a separate quantum silo, so the migration competes for attention and budget in the same forum as every other enterprise risk.
- An entry with no owner and no date is a note, not a risk. The register’s discipline is that every line carries accountability and a clock.
- Its highest value is translation: it turns “we still run RSA-2048 on the customer-data gateway” into a risk a non-cryptographer can rank against everything else on the board’s plate.
Think of it like the deferred-maintenance register a facilities team keeps for a large building. Every known problem (the roof section past its rated life, the elevator on borrowed time, the fire panel that predates the current code) sits on one list with a severity, a cost, an owner, and a date. Nobody fixes everything at once, but nothing important falls off the radar, and when the budget meeting comes the list is what turns “the building has issues” into a ranked, fundable plan. The cryptographic risk register is that list for the cryptography a quantum computer will break.
Why does quantum risk need a register at all?
Because a finding that lives only in the inventory never competes for the resources that fix it. A CBOM is an engineering artifact: it enumerates algorithms, keys, certificates, and protocol configurations across the estate, and it’s the necessary first deliverable. What it doesn’t do is rank those findings against fraud risk, outage risk, or regulatory risk in the forum where budget actually gets allocated. Left in the inventory, “this gateway uses quantum-vulnerable key exchange” reads as a technical fact with no owner and no urgency, and it waits.
The register is the mechanism that pulls the finding into governance. Once a quantum-vulnerable exposure is a line on the enterprise risk register, it inherits everything the organization already does with risks: it gets a severity score, an accountable owner, a treatment decision, a target date, and a review cadence. It shows up in the same quarterly risk review as everything else, which is the only place a multi-year, invisible, patch-type program like a post-quantum migration reliably gets funded. The governance problem is precisely that a perfect technical roadmap produces no motion without this translation, and the register is where the translation happens.
What goes on each entry?
A cryptographic risk register entry has to carry enough to make the exposure rankable and actionable by someone who isn’t a cryptographer. The fields that earn their place:
| Field | What it captures | Why it matters |
|---|---|---|
| Exposure | The specific vulnerable primitive and where it runs (e.g. RSA-2048 key exchange on the customer-data API) | Ties the risk to a real system, not a general worry |
| Data shelf-life | How long the data this protects must stay confidential or trustworthy | The single biggest driver of severity, via Mosca |
| Blast radius | How many systems depend on this cryptography and what fails if it does | Separates an isolated exposure from a load-bearing one, per Blast Radius |
| Vendor or in-house | Whether you control the fix or a third party does | Decides whether remediation is engineering or procurement, per Vendor-Controlled Crypto Surfaces |
| Severity | The ranked risk level, driven by shelf-life and blast radius | Lets the board compare it to non-cryptographic risks |
| Owner | The named person accountable for remediating this exposure | An exposure with no owner doesn’t get fixed, per Cryptographic Ownership |
| Treatment | The decision: remediate now, schedule, accept with justification, or transfer | Records a governed choice rather than drift |
| Target date | When the remediation is due | Turns intent into a commitment with a clock |
| Status | Where the remediation stands right now | Makes the register a living view, not a snapshot |
The two fields that make a cryptographic register different from an ordinary one are data shelf-life and vendor-versus-in-house. Shelf-life is what makes a low-traffic system holding decades-sensitive records outrank a high-traffic one holding data that’s stale in a week. The vendor field is what tells you whether the remediation lands on an engineer or on a procurement officer holding a contract renewal, which changes the timeline entirely.
How does the Mosca timing set the severity?
The severity of a cryptographic risk is a timing judgment before it’s a technical one, and Mosca’s inequality is the tool that makes the judgment defensible. The rule is X + Y > Z: if the time your data must stay secure (X) plus the time your migration takes (Y) is greater than the time until the cryptography can be broken (Z), you’re already late for that asset. Applied to a register, it means severity isn’t read off the algorithm, it’s computed from the data behind the algorithm.
- A short-shelf-life exposure is lower severity even on a broken algorithm. A session token that’s worthless in an hour, protected by quantum-vulnerable key exchange, carries little harvest-now-decrypt-later risk, because there’s nothing worth decrypting years later.
- A long-shelf-life exposure is high severity even with years on the clock. Health records, sealed legal files, state secrets, and long-lived signing keys have to stay protected for decades, so the moment they’re recorded under quantum-vulnerable encryption today, the future compromise is already being locked in. These are the entries that jump to the top of the register.
- Migration time (Y) is almost always underestimated, and it belongs in the calculation. A vendor-controlled surface with a slow roadmap has a large Y you don’t control, which raises the effective severity even when the algorithm’s break date feels far off.
The practical output is that the register ranks by delayed regret, not by proximity of the threat. The asset most worth protecting isn’t the one closest to being attacked, it’s the one whose secrets stay valuable longest and whose migration drags longest, because that’s the combination Mosca shows is already out of time.
Where does the register live in enterprise risk management?
Inside the risk management framework the organization already runs, treated as a category of an existing risk rather than a parallel structure. Quantum risk is a fresh instance of an ordinary cyber risk, and the frameworks have rooms for it. In the NIST Cybersecurity Framework, the risk strategy and the ownership of it sit under the Govern function, the inventory that feeds it sits under Identify, and the register is the artifact that carries a Govern-level risk decision. Folding cryptographic risk into the enterprise register means it competes for budget and attention in the same forum as fraud, outage, and compliance risk, which is exactly where a program that would otherwise be exiled to a technical backlog gets the standing to move.
This placement also solves the defensibility question. A regulator, an auditor, or an insurer asking how an organization manages quantum risk is asking to see it governed like a real risk, and a register entry with an owner, a severity, a treatment decision, and a date is the evidence that it is. An organization that can produce a maintained cryptographic risk register has answered the reasonable-organization question before it’s asked, while one that treats quantum risk as a research topic with no home in its risk management has not.
How is a cryptographic risk register different from an inventory?
They’re sequential artifacts, and confusing them is a common way a program stalls with the easy half done. The inventory is discovery: it answers “what cryptography do we run, and where.” The register is governance: it answers “which of that is dangerous, how dangerous, who owns the fix, and is it moving.” One is the input; the other is what turns the input into managed risk.
| Cryptographic inventory (CBOM) | Cryptographic risk register | |
|---|---|---|
| Question it answers | Where does our cryptography live, and what is it? | Which exposures are risks, how severe, and who owns them? |
| Primary audience | Engineers and architects | Risk committee, board, auditors |
| Unit of record | An algorithm, key, certificate, or configuration | A ranked, owned, dated risk |
| What it drives | Assessment and migration planning | Prioritization, budget, and accountability |
| Without it | You can’t see your exposure | You can see it but can’t govern or fund the fix |
An organization that has an inventory but no register can name its exposures and still watch them go unfunded, because nothing has translated them into the language the budget forum uses. The register is the translation layer, and it’s the reason an accountable owner can point at a ranked list and ask for resources against it.
Common misconceptions
- “The inventory is the risk register.” They’re different artifacts. The inventory catalogs cryptography for engineers; the register ranks, owns, and dates the exposures for the people who fund remediation. You need both, in that order.
- “Severity comes from the algorithm.” It comes mostly from the data. A broken algorithm protecting throwaway data is lower severity than a slightly weaker one protecting records that must stay secret for 30 years, because Mosca weights shelf-life heavily.
- “Quantum risk needs its own separate register.” It belongs in the enterprise risk register you already maintain, as a category, so it competes for budget in the same forum as every other risk rather than sitting in a silo no one funds.
- “An entry without an owner still counts.” An exposure with no named owner and no date is a note, not a governed risk. The whole point of the register is that every line carries accountability and a clock.
- “We accepted the risk, so we’re covered.” Risk acceptance is a valid treatment only when it’s a recorded, justified decision by an accountable owner. An exposure that’s unmanaged by default is drift, and it reads to an auditor as a gap rather than a choice.
Questions people ask
What’s the difference between a cryptographic inventory and a cryptographic risk register? The inventory is the engineering catalog of what cryptography runs where. The register takes those findings and turns each dangerous one into a ranked, owned, dated risk that the organization governs alongside every other enterprise risk. Discovery first, governance second.
How do I decide the severity of a cryptographic risk? Start from data shelf-life and blast radius, then apply Mosca’s timing: the longer the data must stay protected and the slower the migration, the higher the severity, even when a quantum computer feels far off. The asset with the longest-lived secrets and the slowest fix ranks highest.
Where should the cryptographic risk register sit? Inside the enterprise risk management framework you already run, as a category of cyber risk, so it’s reviewed and funded in the same forum as fraud, outage, and compliance risk. In CSF terms it’s a Govern-function artifact fed by Identify-function discovery.
Does a risk register satisfy a regulator or auditor? A maintained register is strong evidence that quantum risk is being governed like a real risk, with owners, severities, treatment decisions, and dates. It’s most of what a reviewer asking “how do you manage this?” wants to see, and it pairs with the ownership structure that makes the owners real.
Can I just accept the risk on a vulnerable system? Sometimes, when it’s a recorded decision by the accountable owner with a stated justification and a review date, especially for short-shelf-life data. What doesn’t hold up is an exposure left unmanaged by default, because that reads as an oversight rather than a governed choice.
Who owns the entries? Each exposure needs a single named owner accountable for its remediation, and the register’s owners roll up to the migration’s accountable executive owner. A register full of exposures with no named owners is the same vacuum that stalls migrations, just written down.
Everything here is the map, given freely. When your team needs its inventory findings turned into a governed, ranked, board-ready cryptographic risk register, that’s the work I do, and there’s an alignment briefing for it.
Last verified 2026-07-12 · Maintained by Addie LaMarr, LaMarr Labs.