What it means
Blast radius describes how far harm can spread from a failure, compromise, or operational action. It depends on relationships: permissions, network paths, shared infrastructure, data access, and business dependencies. A small technical change can have a large effect if many services rely on the same identity or component. Security teams use this idea both to contain attackers and to limit damage from their own response actions. Reducing blast radius often means narrowing scope, separating privileges, testing on a small sample, and retaining a practical recovery route.
The idea at a glance / Risk
Compare the people inside each action’s scope.
Two containment options can refuse one stolen session while affecting different sets of legitimate readers. Count the exact scope and state what the action leaves open.
Fictional PortalWard tabletop. Group G42 is the only read grant for 42 nurse accounts. PS14 labels one stolen session for N14; the other 41 accounts have separate valid sessions. Every read checks current grants and session validity.
READ THE PICTURE
Read the distinction and scope
Removing G42’s grant refuses all 42 next reads, including 41 legitimate readers. Revoking PS14 refuses that session while the other 41 still read. Both options stop its next read; their scope differs, and future sign-ins remain outside the model.
Keep in mindThese are modeled options under explicit assumptions, not clinical actions. Session revocation does not prevent future sign-ins. Other grants, sessions, dependencies, and patient effects are not established.
Read the complete example
- Read the distinction and scope. Removing G42’s grant refuses all 42 next reads, including 41 legitimate readers. Revoking PS14 refuses that session while the other 41 still read. Both options stop its next read; their scope differs, and future sign-ins remain outside the model. PS14 is a safe internal reference, not a displayed session secret. The fictional tabletop assumes that session PS14 for nurse account N14 has been stolen. It does not borrow the unresolved identity-provider case U12 or treat that earlier uncertainty as a confirmed compromise. Group G42 contains N14 and 41 other accounts and is their sole PortalWard read grant. Each account has a separate valid session; the service checks current grant and session validity on every read. In modeled option A, removing G42’s read grant causes all 42 next read requests to be refused, including requests from the 41 legitimate readers. The session secrets are not revoked by the permission change; refusal comes from the now-missing read grant. In independent option B, revoking only PS14 makes that session’s next read fail validity checking; the grant remains and the other 41 separate sessions still satisfy both checks and return their permitted records. No content is returned to PS14 after the refusal. These are alternative configurations with stated modeled results, not sequential actions, a live hospital test, or evidence of actual patient harm. The comparison counts affected read tasks rather than claiming that every person instantly loses every service. Revoking this one session does not disable N14’s account or prevent a new sign-in; additional compromised sessions, authenticators, grants, or shared dependencies require separate assessment. The figure demonstrates response-action scope and its remaining limits. It does not choose or execute a containment decision.
These are modeled options under explicit assumptions, not clinical actions. Session revocation does not prevent future sign-ins. Other grants, sessions, dependencies, and patient effects are not established.
Diagram references: NIST SP 800-61 Rev. 3 - containment · OWASP - permission on every request
AN ILLUSTRATIVE SCENARIO
A response rule would disable every nurse
A hospital investigates a stolen clinician account. An automation proposes disabling the directory group that grants access to the clinical portal. That group includes every nurse on the shift. The responder instead scopes containment to the affected identity and evaluates session revocation with the clinical operations lead. The team checks related service accounts and active sessions, but does not assume a broad group change is safer merely because it is faster. Patient-care dependencies shape the containment decision.
Put it to work
- Map what the affected identity, system, or planned action can reach. Include shared accounts, inherited permissions, downstream services, and the business workflows that depend on them.
- Choose the smallest action that meets the response objective. Use explicit resource identifiers, limited batches, previewable targets, and additional review when a change could affect critical shared services.
- Set stop conditions and a recovery plan before acting. Observe a small controlled change, verify its effect, and expand only when the evidence supports the next scope.
How to check your work
In a test or tabletop scenario, list the exact resources an action would change and the users it could interrupt. Confirm that an out-of-scope resource remains unaffected and that the team can detect and stop an unexpected effect.
Connect the ideas
- Least privilege
Granting each identity only the actions, objects, and time window required for the current job.
- Postcondition
The independently checked state of the world that should be true after a response action.
- Availability
The property that authorized people can use a system or record when they need it.