The Blast Radius Problem

By Domenic DiNatale

When a breach happens — and at some point, it will — the question that matters most isn't how it got in. It's how far it got.

Most organizations spend the majority of their security budget on prevention: firewalls, endpoint detection, identity controls, vulnerability scanning. These are worthwhile investments. But they're built on a quietly optimistic assumption — that if something bad gets through, you'll catch it fast enough to matter. In practice, the average dwell time for an attacker inside a network is measured in weeks, not hours. The breach isn't the disaster. The blast radius is.

Blast radius is a term borrowed from physics. In security, it describes how far damage can propagate from a single point of compromise. One compromised credential. One vulnerable service. One misconfigured storage bucket. The question is whether that entry point is a door into everything, or a door into one room.

The answer is almost always architectural.

Prevention Is Not Containment

There's a category error that runs through a lot of security thinking: treating prevention and containment as the same investment. They're not. A lock on the front door doesn't limit where a burglar can go once they're inside. A firewall doesn't constrain lateral movement once an attacker has valid credentials. Antivirus software doesn't segment your database from your application servers.

Containment requires deliberate architectural choices — and those choices are rarely made with containment in mind. Systems are designed to function, not to fail gracefully. When engineering teams make decisions about network topology, service permissions, data access models, and credential scope, they're usually optimizing for performance and developer convenience. Containment is an afterthought, if it's a thought at all.

The result is systems where a single compromised service account has read access to the entire data warehouse. Where internal services trust each other implicitly because they share a VPC. Where the development environment and production environment share a credential store because it's easier to manage that way. Each of these decisions, individually, seems minor. Collectively, they describe a system where a single entry point becomes a full-scale breach.

Designing for the Breach That Will Happen

The organizations that handle breaches well — the ones where an incident is a contained, manageable event rather than a headline — share a common characteristic. They've accepted that breaches happen and have designed their systems accordingly.

This looks like several concrete things. Microsegmentation: internal services don't trust each other by default; they authenticate. Least-privilege access: service accounts and human accounts have only the permissions they need for the specific task they perform. Data minimization: not every service needs access to every field in every table. Network zoning: not every system needs to reach every other system. Immutable infrastructure: systems can be rebuilt from a known-good state rather than patched in place after compromise.

None of these are novel ideas. They all appear in security frameworks. What's underappreciated is that they're primarily architecture decisions, not security decisions — meaning they need to be made when systems are being designed, not retrofitted after a scare. A microsegmentation strategy applied to a system that was built without segmentation in mind requires re-engineering the system. That's expensive. Designing for segmentation upfront costs almost nothing.

The Leverage Point Is at Design Time

This is the core problem with how blast radius is treated: it's handled reactively. After an incident, organizations do table-top exercises and implement controls. But the controls are constrained by the architecture they're applied to. You can add monitoring to a flat network, but monitoring doesn't stop lateral movement — it just detects it faster. You can rotate credentials after a compromise, but if the architecture allows those credentials to access everything, rotation only limits damage if you catch the compromise immediately.

The leverage point is at design time. When you're making decisions about how services communicate, what they're allowed to access, where data lives, and how credentials are scoped — that's when blast radius is determined. Not in the security audit. Not in the incident response retro.

This means security needs to be in the room when architecture decisions are made. Not as a gatekeeper reviewing finished designs, but as a participant shaping them. The question "how does this fail?" needs to be asked alongside "how does this work?"

The Uncomfortable Implication

Here's what this means in practice: many organizations have already made their blast radius decisions, and they were made years ago. The network was designed flat. Services were built to trust each other. Credentials were issued broadly. The architecture is what it is.

This doesn't mean there's nothing to do — incremental segmentation, tighter credential scoping, and improved network controls all reduce blast radius even in legacy environments. But it does mean that the work is harder and the gains are more limited than they would have been if these decisions had been made intentionally from the start.

The organizations building new systems and new services today have an opportunity the older ones don't: they can design blast radius in from the beginning. Not as a constraint, but as a property. Not "how do we prevent a breach?" but "when we're breached, how much does it cost us?"

That framing shift is harder than it sounds. It requires accepting that prevention will fail. Most security cultures aren't built on that acceptance. They're built on the hope that if you do enough of the right things, the breach won't happen.

It will. The question is how big it gets.

This post is part of a series on security as an architectural problem. Read the full series on the Intellitech blog.