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.
Go deeper
- The Two-Lens Rule: ranks the migration queue by data shelf life and blast radius together.
The precedent
Phaethon went to his father Phoebus and asked to drive the sun chariot for one day. Phoebus had already sworn by the Styx to grant whatever he asked, an oath not even Jupiter could revoke, so he warned him about the route and handed over the reins. The horses were used to a heavier load, felt the difference at once, and bolted. Ovid describes the result at length: moisture evaporating, mountains and forests burning, rivers drying up, the heat driving Neptune down into the sea. To stop the whole world burning, Jupiter loosed a thunderbolt that killed Phaethon and drove the horses into the water.
Ovid, Metamorphoses II.1–328
The moral: the chariot was sound and the route was the one his father drove daily. What made a single bad hour catastrophic is that the sun touches everything.
Blast radius is that property measured in advance. A trust anchor is not dangerous because it is fragile; it is dangerous because everything downstream depends on it, so an ordinary failure inside it reaches every party that ever relied on it. The measurement is population, privilege, reachability, propagation, and how hard recovery is, and the number it produces is usually much larger than the team responsible for the anchor expects. Helios was not reckless with his son. He had sworn the oath before he heard what was being asked, and by then the grant was not his to take back.
Everything here is the map, given freely. When your team needs a consequence model scored against your own architecture, that’s a working session with your team.
Last verified 2026-07-26 · Updated 2026-08-25 · Maintained by Addie LaMarr, LaMarr Labs.