What is blast radius in security?

Blast radius is the extent of what an attacker, or a mistake, could reach through one compromised thing, such as a single leaked API key, a stolen laptop, a departing employee's account or a hijacked CI job, measured in the systems, data and other credentials that become reachable from it.

Why think in blast radius

You can't make leaks impossible. Keys end up in logs, laptops get stolen, people leave on bad terms. The useful question is what happens next. Two teams can lose the same key and have very different days: one replaces a test-mode key that only worked in staging, the other discovers the key also opened production, the billing account and a backup bucket.

Thinking in blast radius turns a vague goal ("be secure") into a concrete review: for each credential and each person, list what it reaches, then cut what it doesn't need.

What widens it

• Reuse. One database password for staging and production; one API key for three services. OWASP's Non-Human Identities Top 10 lists "NHI Reuse" and "Environment Isolation" as separate risks for this reason (OWASP NHI Top 10).
• Broad scopes. An unrestricted key where a restricted one would do; a token with access to every repository.
• Secrets that lead to other secrets. A credential that can read a vault, a CI system or a cloud console reaches everything stored there. Protect these first.
• Long lifetimes. A credential that works for years has years to be found.
• No boundaries between people. When everyone receives the same shared file, everyone's laptop carries everything.

What narrows it

• One credential per consumer. A key per service and per environment means a leak names its source and has one place to fix.
• Narrow permissions. Restricted keys, fine-grained tokens, read-only roles.
• Separation by environment. Development credentials should be unable to reach production by construction, not by convention.
• Network limits. A key usable only from known addresses is worth less to someone elsewhere.
• Short lifetimes. See short-lived credentials.

Common mistakes

• Counting only the first hop. A leaked CI token's radius includes every secret that CI can read.
• Forgetting people. Each person's access is also a blast radius, and it is the one that walks out the door at offboarding.
• Measuring after the incident. Do the inventory while it is calm.

How Crunu limits it

Several Crunu mechanisms exist to keep one compromise small:

• A key per environment. Access to payments-api / development never includes the production key, so a compromised developer session or machine can't decrypt production.
• Roles on each environment. Reader, Editor, Specific files for only selected files, and Operator, which can enroll machines without seeing values.
• Scoped machines and tokens. A service token gets only the environments it's granted, can have a usage limit and a lease, and can be bound with OIDC to one repository and branch.
• Network rules. An environment can be served only to allowed address ranges. This is enforced by the server, not by encryption, so it limits a stolen credential, not a compromised server.

When something does go wrong, the exposure report shows which versions a person or credential received, which is the measured radius rather than the estimated one. For the departure case end to end, see what to rotate when a developer leaves.

Sources

• OWASP Non-Human Identities Top 10 (2025), checked October 30, 2026.