Blast Radius
Blast radius is how far and how badly things break when one cryptographic control fails. It’s the consequence model that answers the question everyone actually cares about once they’ve heard “this is vulnerable,” which is: how bad would it be if it failed? In the quantum transition, blast radius is what separates a contained weakness from one that takes the whole estate down with it, and it’s why two systems using the exact same vulnerable algorithm can sit at completely different priorities.
The short version:
- Blast radius measures consequence, not vulnerability. It asks how much depends on a control, how privileged it is, how far its failure spreads, and how hard recovery is.
- It stops the two failure modes of quantum planning: “everything is urgent” and “nothing matters yet.” Instead it gives you “these few things matter first, because their failure spreads farthest.”
- A small internal app on vulnerable crypto is low blast radius. A root CA, a central identity provider, or a code-signing key on vulnerable crypto is enormous.
- It pairs with the other risk models: Mosca tells you when, HNDL and Non-HNDL tell you what kind, and blast radius tells you how bad.
Think of it as the difference between a blown fuse in one room and a fault at the main panel. Both are electrical failures. Only one of them takes down the building.
What are the five dimensions of blast radius?
Blast radius gets useful the moment you stop treating it as a vague label and break it into concrete dimensions. Score each one, and a fuzzy sense of “this seems important” turns into a defensible ranking.
| Dimension | The question it answers | What raises the score |
|---|---|---|
| Population | How many people, systems, devices, datasets, or workflows depend on the exposed thing? | More dependents |
| Privilege | How powerful is the compromised trust: does it sign code and certificates, authorize machine identity, or gate admin access? | Higher privilege |
| Reachability | How exposed is the surface: public-facing, partner-facing, or internal only? | Easier to observe or reach |
| Propagation | How far does the failure spread once it starts: one system, or a cascade across many? | More cascading |
| Recovery complexity | How hard is it to contain and recover: rotate in a day, or trust-store updates across a whole fleet? | Slower, wider recovery |
Reachability carries a trap worth naming: low reachability doesn’t mean low blast radius. An internal root CA is hard for an outsider to reach and catastrophic if it falls. A sixth dimension, time-to-impact, is sometimes worth adding: would the business feel the damage immediately, or only later when harvested data is decrypted? That’s what distinguishes a fast-moving Non-HNDL trust failure from a slow-burn HNDL confidentiality failure.
How do you use blast radius to prioritize?
Blast radius earns its keep by sorting cryptographic problems by consequence rather than by theoretical weakness. Two moves make it practical:
Pair it with an inventory. For each major cryptographic or trust dependency in a CBOM, ask what depends on it, how privileged it is, how widely it’s used, and how hard recovery would be. That turns a flat list of vulnerable systems into an ordered queue.
Use it to compare equally vulnerable things. ECDH in a small internal service and ECDH in external API transport are both quantum-vulnerable, but their blast radius can be worlds apart. Prioritizing by algorithm alone flattens that difference and wastes the first, most valuable phase of a migration on low-consequence cleanup. Prioritizing by blast radius puts the high-consequence trust surfaces first: root CAs, high-value transport, identity federation, central token issuers, code and firmware signing, and large archives with long-lived sensitivity. Isolated, low-privilege, bounded systems wait.
The payoff is a much stronger explanation for why a program starts where it starts. “We’re starting with these certificate and identity systems because their blast radius is highest” is far more defensible than “we’re starting here because they use RSA.”
How does blast radius relate to the other risk models?
Blast radius doesn’t replace the other models. It combines with them, and each answers a different question.
- With HNDL: blast radius sizes the confidentiality loss. How much data can be harvested, how many users or systems are exposed if later decryption succeeds, how broadly sensitive the traffic is, and how hard re-encryption would be. High-blast-radius HNDL exposures are things like public-facing TLS, major IPsec tunnels, and large archives.
- With Non-HNDL: blast radius sizes the trust collapse. How much trust fails if signatures become forgeable, how many services trust the compromised issuer, and how far a forged assertion can propagate. High-blast-radius Non-HNDL exposures are PKI collapse, central identity providers, and widely trusted signing keys.
- With Mosca’s theorem: Mosca handles timing, blast radius handles consequence. A mature roadmap uses both, so that a low-blast-radius vulnerable system can wait while a high-blast-radius one moves to the front regardless of whether its exploitation is imminent.
Common misconceptions
- “Blast radius just means number of affected systems.” No. Population is one of five dimensions. Privilege, propagation, and recovery difficulty matter just as much, and sometimes more.
- “Any technically vulnerable system is high blast radius.” No. Plenty of vulnerable systems are bounded and low-consequence, and treating them as urgent is how a migration loses its first phase to noise.
- “Low reachability means low risk.” Not always. An internal root CA has low reachability and enormous blast radius.
- “Blast radius replaces Mosca’s theorem.” No. They’re complementary: one is about when, the other about how bad.
Everything here is the map, given freely. When your team needs a consequence model scored against your own architecture, that’s what an alignment briefing is for.
Last verified 2026-07-09 · Maintained by Addie LaMarr, LaMarr Labs.