Introduction
Finally - attack path analysis has arrived in AWS. 🎯
While GCP and Azure have long offered attack path analysis, AWS was suspiciously quiet. That silence is finally over. With Security Hub v2, AWS is finally bringing modern risk-based prioritization to its native ecosystem - not just listing misconfigurations, but showing how an attacker could actually use them.
With attack path analysis, Security Hub v2 helps you see the potential routes a bad actor could take, turning hundreds of isolated findings into actionable risk insights. đź§
For anyone managing cloud security in a multi-account AWS Organization, this is a huge step forward. It means we can stop wasting time on low-risk noise and start focusing on what actually matters: exploitable paths.
Let’s walk through what this means, and how to roll it out properly across your organization.
Section 1: Delegate Admin Rights for AWS Organization
Before you can enable Security Hub v2, you’ll need to designate a delegated administrator account for Security Hub in your AWS Organization.
Use the following resource-based delegation policy that allows the delegated admin account to manage Security Hub organization-wide:
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "Statement",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::01234567890:root"
},
"Action": [
"organizations:AttachPolicy",
"organizations:CreatePolicy",
"organizations:DetachPolicy",
"organizations:DeletePolicy",
"organizations:UpdatePolicy",
"organizations:ListPolicies",
"organizations:ListPoliciesForTarget",
"organizations:ListTargetsForPolicy",
"organizations:DescribePolicy",
"organizations:DescribeEffectivePolicy",
"organizations:DisablePolicyType",
"organizations:EnablePolicyType"
],
"Resource": "*"
}
]
}

Section 2: Enable Security Hub v2 Organization-Wide
From the delegated admin account:
- Open the Security Hub v2 console
- Choose the region you want to activate Security Hub v2 in
- Select all accounts (recommended for organization-wide visibility)
- Enable Security Hub v2
That's it. AWS takes care of enrolling all accounts automatically.

Section 3: Understanding Potential Attack Paths in AWS
Security Hub v2 finally connects the dots between misconfigurations and vulnerabilities. Instead of isolated findings, you now get a graph-based visualization showing how an attacker could chain together risks to compromise your environment.
Take this example from my environment:
"Potential Credential Stealing: EC2 instance with service-level administrative instance profile and unprotected credentials through IMDSv1."
In plain terms:
- An EC2 instance has an admin-level IAM role
- It’s still using IMDSv1, which doesn’t require session-bound tokens like IMDSv2
- If this instance is compromised, an attacker could easily retrieve credentials and gain wide access across AWS services
đź§ Why it matters
This is the kind of insight that shifts security from reactive to proactive. You’re no longer firefighting hundreds of disconnected issues - you’re fixing the real risks.

Section 4: What Happens with the Old Security Hub CSPM?
Here’s the good part: Security Hub v2 builds on top of the existing findings, including those from the old version (Security Hub v1).
You still get all your CIS checks, AWS Config rules, and partner findings, but now with an added layer of attack path context and finding aggregation. It’s a centralized, prioritized view that finally makes CSPM useful in AWS.
If you haven’t rolled out Security Hub (v1) across your AWS Organization yet, start there first.

Member discussion