IAM Blast Radius

Understand the potential consequence associated with control of an AWS identity.

Two identities can both have security findings while creating very different levels of organizational risk. Blast-radius analysis helps answer:

If this identity were controlled by an unauthorized actor, what could the resulting access potentially affect?

Why severity alone is not enough

Consider two IAM identities.

• Identity A — can read a limited development resource.
• Identity B — can operate with broad permissions, assume or pass roles, reach sensitive AWS capabilities, access secrets or encryption-related functions, and modify or disable security controls.

Both may have findings. But the potential consequence is not equivalent. Blast radius adds a consequence-oriented prioritization layer.

Where to find Blast Radius

The report summarizes blast-radius context by identity. Securitain also uses blast-radius analysis as part of identity-risk intelligence.

What Blast Radius represents

Blast radius is not a single AWS permission. It is a way of reasoning about the potential reach and consequence associated with an identity. Supported context can include concepts such as administrative capability, role-assumption capability, role-passing capability, access to supported data/security services, security-control modification capability, and reach into additional AWS security contexts.

The exact available dimensions depend on product coverage and evidence available to the assessment.

A simple comparison

Development resource
  ↓
Limited consequence

Assumable roles
PassRole capability
S3-related access
KMS-related access
Secrets-related access
Lambda-related capability
Security-control changes
  ↓
Broader consequence

The second identity deserves greater attention even if both identities have the same number of findings.

Blast score

Securitain can represent blast-radius analysis using an overall score. Use the score to prioritize identities for investigation.

Admin-capable identities

Administrative capability is an important blast-radius signal because a broadly privileged identity may affect many parts of the AWS environment. However, “admin” should still be interpreted in context. Questions to ask include:

• Is this a human or workload identity?
• Is it actively used?
• Is access temporary or persistent?
• Is federation involved?
• Is the identity protected by strong authentication?
• Is use restricted by organizational workflow?
• Does the account contain production or sensitive resources?

Blast radius helps prioritize the technical consequence. It does not replace identity-governance context.

Assumable roles

If an identity can successfully assume another role, the target role can expand the identity's reachable capability.

DeveloperRole
  ↓
sts:AssumeRole
  ↓
ProductionRole
  ↓
Production capability

The meaningful question is not just whether sts:AssumeRole exists. It is whether the applicable identity permission, role trust and conditions support the role-assumption relationship. Use Effective Permissions, the Relationship Graph and Cross-Account Access to investigate that context.

Passable roles

iam:PassRole can matter to blast radius when the principal can pass a powerful execution role to an AWS service it is allowed to configure or invoke.

Developer
  ↓
iam:PassRole
  ↓
Execution Role
  ↓
AWS Service
  ↓
Role-powered capability

Use Privilege Escalation for detailed path analysis. Blast radius uses the resulting capability context for prioritization.

Sensitive-service reach

Blast-radius context can include supported access indicators related to security-relevant AWS services, such as S3, KMS, Secrets Manager and Lambda.

The presence of service-level capability should not automatically be interpreted as proven access to every resource in that AWS service. Where resource-level reachability is required, use the appropriate resource-policy, identity-to-data and evidence views.

Security controls

A principal capable of changing security monitoring or configuration controls can create greater potential consequence. Examples can include supported capabilities associated with logging, threat-detection configuration, configuration recording and security posture controls.

Blast Radius vs number of findings

Finding count answers:

How many detected security conditions are associated with this environment or identity?

Blast radius asks:

How consequential could control of this identity be?

These can differ significantly. Example:

Security prioritization should not rely only on finding volume.

Blast Radius vs Attack Paths

The two analyses complement each other.

How to investigate a high-blast identity

1. 1

   Confirm the identity

   Review type, purpose, owner, account, and whether it is human or workload.

2. 2

   Review effective permissions

   Identify which actions contribute to the identity's power.

3. 3

   Review role relationships

   Inspect assumable roles, PassRole relationships, role trust and cross-account trust.

4. 4

   Review sensitive capabilities

   Look for supported access involving secrets, encryption, data, deployment capabilities and security controls.

5. 5

   Check attack paths

   Determine whether the identity can escalate into even broader access.

6. 6

   Review credential posture

   If the identity is human or uses long-lived credentials, inspect the corresponding credential risk.

7. 7

   Prioritize remediation

   Focus on the permissions or trust relationships that reduce consequence without breaking legitimate workloads.

Evidence and limitations

Blast radius is derived from the security information Securitain can assess. The result is therefore affected by:

• scan freshness
• effective-permission coverage
• role and trust coverage
• supported AWS service analysis
• resource-level evidence
• organization context
• account scope

Related guides

• Effective Permissions
• Privilege Escalation & Attack Paths
• IAM Relationship Graph
• Cross-Account Access