The blast-radius principle says every vendor should be judged by one question: when they’re compromised, how far does the damage spread? Not if — when. Feature lists tell you what a provider can do for you; blast radius tells you what an attacker can do through them. It’s the single most clarifying lens for evaluating anyone who touches your systems, and almost nobody applies it until after the incident.
What is a blast radius?
Borrowed from engineering and war planning, blast radius describes the reach of a failure from its point of origin. In security terms: if this vendor’s credentials, agent, or infrastructure were compromised right now, what could the attacker reach?
Every vendor relationship has one. The email platform holding your inbox. The monitoring agent running on your server. The IT provider with admin on everything. The question is never whether a blast radius exists — it’s how large you’ve allowed it to grow, and whether anyone has measured it.
Why “when,” not “if”?
Because providers are the efficient target. Breaching one company yields one company; breaching a provider yields their entire client list in a single move. Attackers figured out this arithmetic years ago — it’s why supply-chain and MSP compromises keep producing the incidents with the widest damage. The economics guarantee the attempts will continue. Planning around “our vendors won’t get breached” isn’t optimism; it’s declining to plan.
How do you measure a vendor’s blast radius?
Four dimensions, in order of importance:
1. Standing access. What can the vendor reach right now, without asking? Admin credentials, installed agents, API keys with write scope — access that exists continuously is access an attacker inherits instantly. Access that’s granted per-task and expires has almost no blast radius at all.
2. Depth. Is the access read-only visibility, or can it change things? A tool that observes your site from the outside can leak what it sees. A tool with write access inside your environment can become the attack.
3. Spread. Does one credential reach one system, or does it span every environment the vendor manages? Shared admin accounts, reused keys, and centralized management planes turn a single compromise into a master key.
4. Detonation visibility. If the vendor were breached Tuesday, when would you find out — from them, from your own monitoring, or from the news? A large blast radius with no detection is the worst quadrant on the map.
Score any vendor honestly across those four and the safe ones separate from the dangerous ones fast — often in the opposite order of what their marketing implies.
Why does more capability usually mean more blast radius?
Because the traditional pitch is proximity: install our agent, give us admin, let us inside, and we can do more for you. Every one of those asks enlarges the radius. It’s the trade at the center of the provider model — and it’s the exact distinction we drew in RSP vs. MSP: the provider holding the most access is the biggest risk, and the safest one holds the least.
The blast-radius principle flips the evaluation. The question stops being “what can you do for me?” and becomes “what’s the most you can do to me?” The best vendors have a good answer prepared. The concerning ones have never been asked.
How do you shrink the radius?
- Prefer agentless over installed. Visibility from the outside carries a fraction of the risk of software running inside.
- Prefer expiring access over standing access. If a task needs the keys, grant them for the task — not forever.
- Separate per environment. One credential per client environment means one compromise stays one compromise.
- Demand the breach answer. Ask every vendor: “walk me through what happens to us when you’re compromised.” The quality of the answer is the audit.
- Count the doors. Every additional vendor is another radius overlapping yours — which is half of why vendor sprawl is a security problem, not just a budget one.
For businesses that support other businesses, the principle cuts both ways: apply it to the vendors you buy, and expect your clients to apply it to you. The providers who can answer the blast-radius question with a small number — minimal standing access, agentless where possible, per-environment separation — will increasingly be the ones who win the security review.
Every vendor gets breached eventually; the only variable you control in advance is the radius. Measure it before the incident does it for you. Start with the comparison that frames the whole problem — RSP vs. MSP: The Safest Provider Doesn’t Sit Inside Your Network — or see how Centry Secure engineers its own radius down by design: every connection initiated by the site, no credentials held into the site, and nothing an attacker could turn against the environments it watches.
Was this article helpful?
Thanks for your feedback.
Have a question about this topic?