By NHI Mgmt Group Editorial TeamBased on Pentera: “Not All Attack Graphs Are Created Equal” (July 6, 2026)

TL;DR: Passive attack graphs show inferred paths between assets, but they do not prove exploitability; Pentera argues that validated attack mapping uses live attack execution to show which paths actually work, how controls fail, and what exposure should be prioritised first.


At a glance

What this is: This is an analysis of why passive attack graphs and validated attack mapping are not equivalent, and why proof of exploitability changes remediation priorities.

Why it matters: IAM and security teams need to know whether a path is theoretically possible or actually executable, because that determines whether identity controls, segmentation, and detection are stopping real attack chains.


Context

Attack graphs are useful only when they answer a governance question, not just a visualization question. In exposure management, the real issue is whether a mapped path reflects inferred relationships or tested exploitability, because those produce very different remediation decisions.

The identity angle is direct: access paths often depend on credentials, permissions, and trust relationships, so a graph that only mirrors configuration state can overstate or understate actual risk. That is why attack path validation matters when teams are trying to separate theoretical connectivity from live compromise potential.


Key questions

Q: What is the difference between a passive attack graph and a validated attack graph?

A: A passive attack graph models possible movement using observed relationships, permissions, and topology. A validated attack graph is built by executing attack techniques in the live environment, so it shows which paths actually work under current controls. That difference matters because theoretical reachability and proven exploitability often lead to very different remediation priorities.

Q: Why do attack graphs often overstate risk in real environments?

A: They often assume that connectivity equals reachability. In practice, segmentation, endpoint defenses, authentication controls, and policy enforcement can block movement even when the asset relationships appear to form a path. The graph is not wrong, but it is incomplete unless it is tested against live controls.

Q: How should security teams think about attack paths instead of isolated vulnerabilities when prioritising remediation?

A: Security teams should map how assets trust one another and trace the routes an attacker could use from a low-value foothold to sensitive systems. A single weakness rarely matters in isolation. The practical goal is to identify complete attack paths, then fix the links that let an intruder move toward crown jewels, especially externally facing or overprivileged systems.

Q: What does validated attack mapping change for CTEM programmes?

A: It gives CTEM teams a decision-grade view of which exposures actually matter in their environment. Instead of reporting every theoretical path, teams can focus on weaknesses that survive execution testing and then use those results to justify remediation sequencing, detection tuning, and control improvement.


Technical breakdown

Why passive attack graphs overstate what an attacker can do

Passive attack graphs are built from observed relationships such as CMDB links, identity mappings, network paths, and configuration states. They are useful for showing where privilege or connectivity exists, but they stop at inference. A graph can suggest that a route from an exposed asset to a sensitive system is possible even when segmentation policies, endpoint controls, or conditional access prevent execution. The problem is not the diagram itself. It is the assumption that structural connectivity equals attacker reachability. That assumption collapses as soon as the environment contains compensating controls that are not represented in the underlying data. See the Identity Attack Paths Guide.

Practical implication: Treat passive attack graphs as hypotheses that still require validation against live control behaviour.

How active validation turns a path into evidence

Active validation executes controlled attack techniques in the live environment to test whether a modeled path can actually be used. Instead of relying on inferred connections, it attempts the kinds of steps an attacker would take, then records whether lateral movement, credential abuse, or impact is really achievable. This changes the output from a theoretical map to an observed one. In practice, the value is not just finding a route. It is proving whether the route survives the current state of segmentation, authentication, detection, and response. That makes the result suitable for prioritisation, not just inventory. See the Exposure Management and CTEM Guide.

Practical implication: Use validated results to drive remediation order, because they show which paths are exploitable today.

Why AI-assisted validation expands the attack surface view

The article describes deterministic execution alongside agentic AI that can inspect unstructured content, extract sensitive information from images, and adapt payloads as new assets or exposures are discovered. That matters because modern exposure is not only about network reachability. It also includes data visibility, contextual abuse, and discovery of overlooked assets that reshape the attack path mid-test. The technical distinction here is between static path construction and adaptive path exploration. Static models freeze the environment at one point in time; adaptive validation keeps testing as the environment reveals more about itself.

Practical implication: Validate both technical reachability and hidden information exposure, because either can extend the kill chain.


Threat narrative

Attacker objective: The objective is to prove whether an apparently reachable path can be used to gain real access and produce material impact in the live environment.

  1. Entry begins with an exposed asset or weakness that appears connected to a sensitive system in the graph.
  2. Escalation is tested by attempting the techniques needed to move from that asset into adjacent systems or higher-value controls.
  3. Impact is confirmed only when the path survives live conditions and reaches a crown-jewel system or other material exposure.
  • Microsoft SAS token exposure 2023: An over-permissive Azure SAS token in a Microsoft AI GitHub repo exposed 38TB, including workstation backups and Teams messages, for 3 years.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.


NHI Mgmt Group analysis

Validated attack graphs are a control decision tool, not a prettier diagram. The article’s core point is that visual similarity hides a governance difference: one graph shows inferred connectivity, the other shows observed exploitability. That distinction changes whether teams treat a path as architectural noise or an active exposure. Practitioners should stop asking which graph looks more complete and ask which one was proved in the live environment.

Exposure management now depends on proof, not proximity. CTEM programs only become decision-grade when validation can separate weaknesses that exist from weaknesses that can be exploited. The identity implication is important because access, privilege, and trust relationships are often the bridge between an asset inventory and a real attack path. Teams should treat path validation as a requirement for prioritisation, not a nice-to-have benchmark.

Observed exploitability is the missing governance layer in attack-path analysis. Passive mapping can tell you where credentials, permissions, and segmentation create theoretical routes, but it cannot prove whether those routes survive current controls. That leaves a blind spot for remediation planning and executive reporting. Security leaders should require evidence of live attack execution before assigning highest priority to a path.

Continuous validation changes the meaning of control effectiveness. If a path remains possible after testing, then the issue is not just exposure inventory. It is control failure across authentication, segmentation, detection, or response. That reframes the problem from discovery to operational assurance, which is where meaningful risk reduction actually happens.

Identity and attack-path governance are converging. A path is only as real as the access relationships behind it, which is why privilege, credential scope, and trust boundaries matter as much as asset reachability. Teams that map attack graphs without identity context will keep mistaking structure for exploitability, and that will distort remediation choices.

What this signals

Attack-path governance is moving from inventory to assurance. Teams that only catalogue relationships will keep confusing possible movement with actual movement, which weakens remediation discipline. The next stage for exposure management is to tie every path claim to live validation evidence, not diagrammatic confidence.

Identity context is what makes attack graphs operationally useful. When credentials, privileges, and trust boundaries are visible in the path model, teams can distinguish asset adjacency from real compromise potential. That is where exposure management starts to become a governance control rather than a reporting exercise.

Continuous validation will increasingly define control credibility. In programmes that claim to reduce exposure, the practical test is whether the control still blocks the path after it has been exercised in the live environment. If it does not, the organisation has discovered a control gap, not just a vulnerability.


For practitioners

  • Separate inferred paths from validated paths Classify every attack graph as passive or active so remediation teams know whether the path is based on relationships or live exploit testing. See the Identity Attack Paths Guide.
  • Prioritise remediations proven exploitable in your environment Use live validation results to rank findings ahead of theoretical routes that have not survived control testing.
  • Test whether segmentation actually blocks movement Replay the path against network, identity, and endpoint controls to confirm whether lateral movement is genuinely prevented.
  • Correlate attack execution with detections and response Measure whether logs, alerts, and SOC workflows appear during the tested attack chain so you can see where detection fails.

Key takeaways

  • Passive attack graphs describe theoretical reachability, but they do not prove that an attacker can actually move through the environment.
  • Validated attack mapping changes prioritisation because it shows which paths survive live controls and therefore represent real exposure.
  • For identity and security teams, the key question is no longer whether a route exists on paper, but whether credentials, segmentation, and detection actually stop it.

Related NHI Mgmt Group resources: Exposure Management and CTEM Guide · Identity Attack Paths Guide · Identity Security Programme Guide · NHI Lifecycle Management Guide


Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

MITRE ATT&CK addresses the attack and risk surface, while NIST CSF 2.0, CIS Controls v8 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.

FrameworkControl / ReferenceRelevance
MITRE ATT&CKTA0006; TA0008 — Credential Access; Lateral MovementThe article is about proving whether real attack paths can reach credentials and move laterally.
Recommendation — Map validated paths to TA0006 and TA0008 so you can prioritise exposed routes that survive live testing.
NIST CSF 2.0PR.AA-05 — Access Permissions, Entitlements and AuthorizationsAttack paths depend on whether permissions and authorisations actually allow movement.
Recommendation — Review access permissions with validation evidence so theoretical routes are not mistaken for real ones.
CIS Controls v8CIS-5 — Account ManagementIdentity mappings and credential scope are central to whether an attack path can be executed.
Recommendation — Tie account management reviews to validated attack paths to find which identities can actually be abused.
NIST SP 800-53 Rev 5AC-6 — Least PrivilegeThe article hinges on whether privilege boundaries stop or permit movement along a path.
Recommendation — Use AC-6 to reduce privileges that allow validated movement toward crown-jewel assets.

Key terms

  • Validated Attack Mapping: Validated attack mapping is the practice of proving whether an attack path can actually be executed in a live environment. It goes beyond inferred connectivity by using controlled attack techniques to confirm reachability, control failure, and potential impact under current conditions.
  • Passive Attack Graph: A passive attack graph is a model of possible movement built from observed relationships such as identity links, network paths, and configuration states. It is useful for seeing where risk may exist, but it does not prove that the path survives segmentation, authentication, or endpoint controls.
  • Attack-path validation: Attack-path validation is the practice of proving whether an attacker can move from one weakness to another until they reach meaningful impact. It goes beyond scanning by testing how exposures connect across identity, network, cloud, and application layers under realistic adversarial conditions.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It helps practitioners connect identity controls to broader security decisions across programmes and teams.
NHIMG Editorial Note
Published by the NHIMG editorial team on October 22, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org