the only number that matters is blast radius

A head of security at a 350-person company was preparing for a board presentation in the fall of 2025. Her team had assembled the standard metrics package. Number of alerts processed in the quarter. Number of confirmed incidents. Mean time to detect. Mean time to respond. Patch compliance percentage. Phishing simulation click rates. Vulnerability counts by severity.

The deck had 24 slides. Each slide was a metric or a category of metrics. The slides were color-coded with green, yellow, and red indicators.

Most of the indicators were green. Alert volumes were processed. MTTD was within target. Patch compliance was above the SLA. Phishing click rates were declining.

She scheduled a rehearsal with her CISO. The CISO looked through the deck and asked a specific question. “If a significant breach happens next quarter, say, someone clicks a phishing link and their credentials are compromised, what would the impact be?”

The head of security started to answer. The impact would depend on whose credentials were compromised, what systems they had access to, what data was in those systems, and whether the attacker could pivot from the initial access to other systems. The full answer would be different for different users.

The CISO asked the follow-up. “For the ten most-privileged users on our systems, can you tell me, today, what their blast radius is if compromised?”

She couldn’t. The metrics in the deck didn’t include that. The tools the team used didn’t compute it directly. Producing the answer would require a multi-day exercise of cross-referencing user permissions across every system.

She suggested adding the metric to the next quarter’s deck.

This essay is about that metric. Why blast radius is the only security measurement that reliably predicts breach impact, why almost nobody measures it, and what a security program looks like when blast radius is the primary metric.

the industry measures what’s easy to count

Most security metrics describe activity. They measure what the security team is doing, not what the security posture looks like. This is partly a function of what’s easy to measure. Alert volumes are easy to count. Patch levels are easy to compute. Phishing click rates are easy to derive from simulation data.

Blast radius is hard to measure. It requires knowing, for every user and identity in the environment, what systems they can reach, what data is in those systems, and what an attacker could do with that access. The computation spans dozens of systems with different permission models. The inputs change continuously as people change roles, systems get added, and permissions drift.

Because it’s hard, most companies don’t measure it. Because it’s not measured, it’s not a target for improvement. Because it’s not a target, it drifts in the direction of expansion, which is the natural direction of access creep as documented in other essays in this series.

The measurement gap has a specific consequence. Security programs optimize for the metrics they track. Programs tracking alert volumes optimize for processing alerts. Programs tracking patch compliance optimize for patching. None of these optimizations directly reduces the blast radius of a successful attack, which is what actually determines the cost of a breach when one happens.

blast radius is an identity property

The specific definition worth using: blast radius is the set of resources, data, and capabilities that an attacker could access if they compromised a specific identity.

The identity could be a user, a service account, an API key, an OAuth grant, a session token, any authentication artifact. The blast radius is computed by walking the permission graph from that identity to everything it can reach.

For a given employee, blast radius includes every system they can log into, every record they can read in those systems, every action they can take, every other identity they can authenticate as, every credential they can extract from their accessible systems.

The walking is transitive. If the employee can read a config file that contains credentials for another system, the other system is in scope. If they can access a cloud account with permissions to assume other roles, those roles are in scope. The blast radius extends through every identity and credential the initial compromise can chain to.

For most companies, the blast radius of a typical employee is larger than anyone would predict. Individual permissions, each seeming reasonable, chain together through the permission graph to produce a reachable set that wasn’t intended by any single grant.

activity metrics and blast radius answer different questions

activity metrics

what the team did

• Alerts processed
• Tickets closed
• Training completed

blast radius

what one identity could reach

• Systems and data a single login can access
• What an attacker inherits from that login
• Whether that shrank since last quarter

the ten-user baseline

A specific practical question to start with: for the ten most-privileged identities in your company, what is each one’s blast radius?

The ten most-privileged is typically a mix. The primary identity admins (domain admins in Windows environments, super admins in Google Workspace, org admins in Okta). The senior infrastructure engineers with broad cloud permissions. The CFO and senior finance leaders. The CTO or VP of Engineering. Possibly the CEO depending on their technical access. Historical admins whose privileges were never reduced.

For each of these ten, computing the blast radius is a bounded exercise. Walk their permission graph. List every system they can access. For each system, list what they can read and modify. Note any credentials accessible through those systems. Note any identities they can assume or impersonate.

The list, for a typical privileged identity at a mid-market company, is long. A domain admin effectively has everything in the Windows environment. A cloud admin has everything in the cloud environment. A Salesforce super admin has everything in the CRM.

The question worth asking for each identity: is the blast radius justified by the operational need? A domain admin needs broad access to operate the domain, but do they need standing access across every server, or would just-in-time elevation be sufficient? A cloud admin needs to administer the cloud, but do they need standing root permissions, or could they operate through audited break-glass workflows?

For each of the ten identities, reducing the blast radius requires either narrowing their standing permissions or moving to just-in-time access for the elevated portions. Both require engineering investment. Both pay off in reduced blast radius if an identity is compromised.

the typical user surprises

After the ten most-privileged identities, the next question is what the blast radius looks like for the typical user.

A typical employee is not an admin. They have permissions appropriate to their role. The blast radius should be bounded.

In practice, the typical employee’s blast radius is larger than intended. Several factors contribute:

The default permissions on the tools they access often exceed role requirements (discussed in the day-one essay).

Accumulated permissions from previous roles (the stayers problem) extend the blast radius.

OAuth grants and connected apps authorized during the employee’s tenure extend the reach to data in integrated systems.

Shared credentials and service account access stored on the employee’s endpoints are reachable if the endpoint is compromised.

The employee’s email history contains information, credentials, and links that extend the reach beyond their current accounts.

Computing a typical employee’s blast radius requires acknowledging all of these. The computation is approximate, because the data in email history is heterogeneous. The approximation is still useful.

For a randomly-sampled employee, the blast radius is typically several orders of magnitude larger than what their current role requires. The excess is the access creep surface.

the measurement approach

Measuring blast radius in practice requires a combination of data from several sources. Identity provider data (who has what accounts). SaaS admin data (permissions within each SaaS tool). Cloud provider data (IAM roles and policies). Data classification data (what’s in each store). Connectivity data (what systems can reach what other systems).

For a mid-market company, assembling this into a coherent measurement is a non-trivial project. There are tools in the category, collectively labeled Identity Security Posture Management (ISPM) or variations thereof, that attempt to automate this. Some of them work. Most are early and require significant customization to produce meaningful output.

A reasonable starting approach is to measure blast radius approximately, for a sample of identities, rather than comprehensively for all identities. The approximate measurement is still more informative than no measurement.

The specific measurement pattern:

Pick a target identity. A high-privilege identity for the first pass, typical user later.

Enumerate the identity’s access across your main categories of systems: identity providers, cloud providers, primary SaaS tools, code repositories, data warehouse, email.

For each access, note what data or capability is reachable. Customer records. Financial data. Source code. Email history. Cloud infrastructure.

Note transitive access: from the accessible systems, what further access can be obtained? Credentials stored in email. Service account tokens in cloud metadata. SSH keys on development servers.

Summarize the total reachable surface. This is the blast radius for that identity.

Repeat for a sample of users.

one long-tenured identity, mapped

• email and calendarexpected for the role
• shared documentsexpected, but how many?
• CRM export rightsfrom a past project
• production consolegranted during an incident
• identity provider admin"temporary", years ago
• finance toolfrom a previous role

beyond the current roleusually handled

the reduction targets

Once blast radius is measured, reduction becomes a target. Specific patterns of reduction:

Eliminate accumulated permissions from previous roles. This is the stayers problem. Long-tenured employees shed permissions they no longer need.

Move standing admin access to just-in-time elevation. Admin roles are assumed for specific tasks, audited, and released. The blast radius of the day-to-day identity is smaller than the blast radius of the elevated identity, and the elevated identity is used less often.

Narrow OAuth grants and connected apps. Apps authorized for historical reasons are uninstalled or have their scopes reduced.

Rotate credentials stored in accessible locations. Credentials in email, in documentation, in repositories are rotated and migrated to secrets management.

Segment cloud environments. An identity with access to one environment shouldn’t be able to pivot to another. Segmentation at the cloud IAM level bounds the blast radius within that environment.

Each of these reductions is specific and measurable. The blast radius of the target identity is smaller after the reduction than before. The improvement can be tracked over time.

the metric as a dashboard item

The specific metric worth presenting to leadership is blast radius of typical privileged identities over time. The number, whatever its unit (systems reachable, records reachable, a composite score), should be trending downward if the security program is working.

The metric is more useful than most of the metrics currently on security dashboards. It predicts breach impact. It directly ties to the controls that reduce breach impact. It aligns the security team’s work to outcomes rather than to process.

The challenge of presenting it is that it’s harder to explain to non-security leadership than the process metrics. Alert volume is intuitive. Blast radius requires some explanation. For a board context, the explanation is worth the effort, boards are increasingly sophisticated about security and appreciate metrics that describe risk directly.

The transition from process metrics to outcome metrics is a multi-quarter project for most security programs. Blast radius is the central outcome metric for identity-driven risk, which is the majority of current breach risk. Other outcome metrics exist for other threat categories (supply chain exposure, application vulnerability exploitability, etc.), but identity-driven risk dominates, and blast radius is the identity-driven risk metric.

the connection to the other essays

The essays in this series have described specific patterns that contribute to blast radius expansion. Day-one over-provisioning. Stayers accumulating access. Reorgs that don’t deprovision. Contractors who don’t offboard. Service accounts with sprawled permissions. Long-lived tokens. RAG indexes flattening permissions. SharePoint over-sharing.

Each of these patterns contributes to blast radius for the identities affected. Reducing any of them reduces blast radius. The programs that are effective are not the ones that address every category in depth, they are the ones that measure blast radius and address the categories that most contribute to it.

The measurement provides the prioritization. Without the measurement, the security program is working on whatever it thinks matters. With the measurement, the program is working on what actually matters for reducing breach impact.

the exercise

For your own program, here is the specific exercise.

Pick the top five privileged identities at your company. For each, document the blast radius using the measurement approach above.

Pick three typical users, one long-tenured, one mid-tenure, one recent hire. For each, document the blast radius.

Put the eight measurements on one slide. Not with specific numbers, the numbers are too variable across measurements, but with the enumerated list of what each identity can reach.

Bring the slide to your next security review. The discussion that follows is different from the one you have when reviewing alert volumes.

The discussion is about which reductions are achievable, which would most reduce aggregate risk, and how the reduction work should be prioritized against other security investments.

That discussion, recurring quarterly, moves the program from process optimization to outcome improvement. The outcome, reduced blast radius, is what actually changes the breach cost when something eventually goes wrong.

Measure what matters. The rest of the metrics are decoration.