Attack path analysis shows why severity scores miss real risk

At a glance

What this is: Attack path analysis maps how vulnerabilities, identities, and configurations combine into attacker routes that reach critical assets.

Why it matters: IAM, NHI, and security teams need this because isolated findings often hide privilege chains, exposure paths, and cross-domain access that attackers can exploit faster than patch queues can close them.

By the numbers:

• 31% of breaches in Verizon’s 2026 Data Breach
• Median time-to-patch climbed from 32 days to 43 days, widening the gap between disclosure and remediation.
• ArmorCode says its Context Risk Graph spans 400-plus integrations across the security and development stack.

👉 Read ArmorCode's blog on attack path analysis and exposure prioritisation

Context

Attack path analysis is the practice of tracing how separate weaknesses combine into a reachable route to a critical asset. The primary gap it addresses is that traditional severity scoring treats findings as isolated, while attackers treat identity, configuration, and network trust as a connected chain. For identity-heavy environments, that chain often includes service accounts, overly broad permissions, and exposed secrets.

The keyword here is reachability, not raw count. A medium-severity issue that connects to privileged access can matter far more than a critical finding sitting in a dead end. That is why attack path analysis sits naturally beside NHI governance, because service accounts, API keys, tokens, and other non-human identities often provide the bridges that turn exposure into compromise.

Key questions

Q: What breaks when attack path analysis is not in place?

A: Without attack path analysis, teams keep treating findings as isolated items and miss the combinations that actually create breach routes. The result is predictable: medium and low issues can stay open because they do not look urgent alone, even though they connect to privileged access or critical data. That blind spot is especially dangerous in environments with service accounts and shared trust boundaries.

Q: What problem does ownership attribution solve for service accounts and API keys?

A: It closes the gap between exposure detection and accountable remediation. Many organisations can find the secret, but not the human who introduced it, maintains it, or can safely replace it. Ownership attribution gives security teams a practical way to assign action without relying on informal knowledge that disappears during staff changes.

Q: How do teams know if attack path prioritisation is working?

A: It is working when remediation moves away from the largest backlog and toward the nodes that collapse the most routes. You should see fewer critical paths remain open, faster closure of choke points, and better alignment between what is reachable and what is being fixed. If teams still argue mostly about CVSS rank, the model is not yet changing decisions.

Q: What should security teams do when cloud, AppSec, and identity tools disagree?

A: Treat disagreement as a signal that your exposure model is incomplete, not as a reason to pick one tool’s view. Reconcile the asset, identity, and trust data first, then decide whether the finding is actually on a route to something valuable. Cross-domain paths are often missed because each team sees only its own slice of the environment.

Technical breakdown

How attack vectors become attack paths

An attack vector is the entry method, such as phishing, an exposed service, or a misconfigured cloud bucket. An attack path starts only after that entry point connects to other weaknesses through permissions, trust relationships, or lateral movement opportunities. In practice, the path is built from identities, assets, and routes that allow an attacker to move from exposure to objective. The important distinction is that a vulnerability becomes operationally dangerous only when it is reachable from the attacker’s starting point and linked to something valuable.

Practical implication: prioritize the entry points that open access to privileged identities or sensitive systems, not the loudest findings in the queue.

Why CVSS misses chained exposure

CVSS scores describe theoretical severity, not environmental context. A vulnerability with a high score may be unreachable, while a lower-severity flaw can become decisive when paired with exposed credentials, an over-permissioned role, or a shared trust boundary. Attack path analysis adds that missing context by correlating exploitability, identity relationships, and asset connectivity. That is why teams need to see how one finding changes the meaning of another. The problem is rarely one control failure, but the sequence of failures that creates a viable route.

Practical implication: re-rank remediation based on exploitability plus reachability, especially where identities and privileges connect otherwise modest findings.

Why unified exposure data matters for identity governance

Attack path analysis depends on normalised data across cloud, application, infrastructure, and identity systems. If identity data sits in one tool, cloud posture in another, and application findings in a third, the path can disappear between teams. For NHI governance, this matters because service accounts, API keys, and tokens often become the connective tissue of the path. The model is only as strong as its weakest data feed, which is why exposure management must correlate identity context with configuration and asset context before the route is visible.

Practical implication: correlate identity, cloud, and application findings into one exposure model so cross-domain privilege chains do not remain invisible.

Threat narrative

Attacker objective: The attacker’s objective is to turn a reachable foothold into access to high-value data or systems that were not directly exposed.

1. Entry begins with an exposed or misconfigured asset, such as a cloud bucket, leaked credential, or vulnerable endpoint that gives the attacker initial access.
2. Escalation follows when the attacker uses permissions, service accounts, or other non-human identities to move from the first foothold into higher-value internal systems.
3. Impact occurs when the attacker reaches a production database, sensitive records, or an AI system and can exfiltrate data or manipulate outcomes.

NHI Mgmt Group analysis

Attack path analysis is fundamentally an identity problem as much as a vulnerability problem. The article correctly frames risk as a sequence, not a single flaw, and that sequence often depends on who or what can authenticate. Service accounts, API keys, and broad roles are the bridges that make low-severity issues actionable. For IAM and NHI programmes, that means exposure management must include identity relationships, not just technical findings. The practitioner conclusion is simple: if you cannot model access paths, you cannot model attack paths.

Reachability is the missing governance concept in most remediation programmes. Severity scoring still dominates because it is easy to measure, but attackers do not prioritise by score. They prioritise by what is connected, what is trusted, and what can be reached from a compromised entry point. That creates a named gap we can call reachable privilege chains, where separate issues become dangerous only when they align across identity and infrastructure boundaries. The practitioner conclusion is to treat reachability as a first-class risk dimension.

Unified exposure management is becoming the control plane for cross-domain risk decisions. The article shows why point tools fail when cloud, AppSec, and identity data are separated. A team that can see only one slice of the environment will always underestimate compound risk, especially where non-human identities connect systems. This is where NHI governance intersects with broader exposure management: the identity layer is often the shortest route to a critical asset. The practitioner conclusion is to make identity correlation mandatory in exposure workflows.

AI systems now belong inside the attack-path conversation. The article’s AI example is plausible because service accounts and internal APIs frequently grant AI platforms access to data and orchestration layers. That means an exposure path can now run from infrastructure into model-facing systems, creating governance blind spots if AI telemetry is excluded. Practitioners should treat AI access as part of the same risk graph as other privileged workloads. The practitioner conclusion is to extend attack-path analysis to AI-connected identities before those routes become routine.

Path-based remediation is a better operating model than backlog-based remediation. The article argues for closing choke points instead of chasing individual findings, and that is the right direction for modern identity-heavy environments. NIST CSF 2.0 and NIST SP 800-53 both support this style of connected control thinking, while ATT&CK helps map the adversary behaviors that make the path real. The practitioner conclusion is to remediate the node that breaks the chain, not the finding that merely appears highest on a scorecard.

What this signals

Reachability will become the practical filter that separates useful exposure programmes from noisy ones. Teams that can correlate identity context with cloud and application findings will spend less time arguing about scorecards and more time closing the few paths that matter. The programme design question is no longer whether you can inventory risk, but whether you can prove that a route to a crown-jewel system exists. NIST Cybersecurity Framework 2.0 provides the governance language for that shift.

Path-based remediation will force IAM and NHI teams into the centre of exposure management. Once service accounts, API keys, and roles are treated as path components, identity lifecycle work stops being back-office hygiene and becomes an exposure control. That means tighter offboarding, shorter credential lifetime, and better access-scoped ownership will directly reduce reachable risk.

Attack-path thinking also changes how organisations assess AI-connected systems. When AI workloads can be reached through the same identity and privilege fabric as other production assets, blind spots emerge quickly. Correlating those routes with the MITRE ATT&CK Enterprise Matrix helps teams see where privilege escalation and lateral movement are likely to occur before an attacker gets there.

For practitioners

• Map identity-aware attack paths across all major control planes Correlate cloud, application, network, and identity findings into a single graph so service accounts, roles, and credentials are visible as path components. Use the graph to identify the smallest set of choke points that collapse multiple routes to critical assets.
• Reprioritise remediation by reachability and privilege Move beyond CVSS-only triage by weighting findings that connect to privileged identities, exposed secrets, or production data paths. Treat a medium-severity issue as urgent when it sits on a reachable route to a crown-jewel system.
• Reduce the trust carried by non-human identities Audit service accounts, API keys, and tokens for excessive permissions, shared usage, and long-lived access that make paths easier to assemble. Shorten the life of credentials and remove permissions that are not required for the current workload.
• Break cross-team silos in exposure management Establish a shared workflow between infrastructure, AppSec, cloud, and identity teams so one team’s findings cannot become another team’s blind spot. Align on common asset IDs, ownership, and remediation triggers to keep attack paths visible end to end.

Key takeaways

• Attack path analysis matters because attackers exploit connected routes, not isolated findings, and identity is often the bridge that makes those routes real.
• CVSS-only remediation misses reachability, which is why medium-severity issues can outrank critical ones when they sit on a path to privileged access or sensitive data.
• Teams should correlate identity, cloud, and application context into one exposure model so remediation can target the choke points that actually break attack chains.

Key terms

• Attack Path Reachability Analysis: A technique for determining whether a vulnerability can actually be reached and exploited along a realistic path into an application or environment. It helps teams separate theoretical findings from issues that are materially exposed and therefore more urgent to remediate.
• Attack Surface Management: Attack surface management is the practice of finding and evaluating assets that could be exposed to misuse or compromise. CAASM focuses on internal visibility across the environment, while EASM focuses on externally reachable assets. It is a discovery discipline, not a complete identity control model.
• Exploitability Cluster: An exploitability cluster is a group of related weaknesses that share a common route, trust boundary, or blast radius. The concept helps teams see that several medium findings may form one actionable risk path, rather than many unrelated tasks.
• Reachability analysis: Reachability analysis checks whether a vulnerability can actually be exploited in the application’s real code paths and dependency graph. It helps teams distinguish theoretical findings from issues that an attacker can reach, which makes prioritisation far more accurate for both AppSec and identity risk management.

What's in the full article

ArmorCode's full blog covers the operational detail this post intentionally leaves for the source:

• How the Context Risk Graph correlates findings across 400-plus integrations and scores exploitability clusters.
• Examples of how EPSS and KEV are combined with business context to rank remediation.
• The article's step-by-step explanation of how attack paths differ from attack vectors and attack surface.
• Vendor-specific workflow details for moving from path discovery to remediation execution.

👉 ArmorCode's full post explains the Context Risk Graph, exploitability clusters, and remediation workflow in more detail.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, secrets management, and identity lifecycle control. It helps security practitioners connect identity discipline to broader exposure and access risk management.