Attack-path modelling maps the sequence of systems, identities, and permissions an attacker could chain from initial access to a target asset. It is useful because it shows which connections matter operationally, not just which weaknesses exist in isolation, and it helps teams identify choke points that collapse multiple paths.
Expanded Definition
Attack-path modelling is a security analysis method that traces how an intruder could move from a foothold to a high-value outcome by chaining identities, systems, permissions, trust relationships, and reachable services. It differs from vulnerability scanning because it evaluates how weaknesses combine in context rather than treating each finding as isolated. The result is a map of operational exposure, showing which routes are actually viable and which assets act as choke points. In modern environments, the method often spans cloud, endpoint, identity, and SaaS layers, because privilege and trust are usually the bridges that make a path possible. For teams working with identity-heavy estates, the model frequently reveals that the shortest route to impact is not a technical exploit, but a weak entitlement, an over-permissioned service account, or a compromised admin session. NIST does not define attack-path modelling as a single standalone control term, but the idea aligns closely with control reasoning in NIST SP 800-53 Rev 5 Security and Privacy Controls and adversary path analysis in MITRE ATT&CK Enterprise Matrix. The most common misapplication is treating the output as a static network diagram, which occurs when teams ignore identity permissions, lateral movement prerequisites, and asset-to-asset trust edges.
Examples and Use Cases
Implementing attack-path modelling rigorously often introduces data-quality and modelling overhead, requiring organisations to weigh clearer prioritisation against the effort of maintaining accurate asset, identity, and relationship data.
- A cloud security team models how a compromised developer token could lead from a CI/CD secret store to production workloads by following service-to-service permissions and secret exposure.
- An identity team maps how a stolen helpdesk account could be used to reset higher-privilege credentials, then pivot into privileged access management workflows.
- A red team uses attack-path modelling to identify a route from a low-value endpoint to a domain admin account, then validates whether segmentation and conditional access truly break the chain.
- A detection team correlates likely path segments with alert logic so that repeated access to a jump host, admin portal, and secret vault triggers investigation sooner.
- A security architect compares multiple routes to the same crown-jewel system and invests in the control that collapses the largest number of paths, rather than fixing one weakness at a time.
For incident-driven modelling, threat intelligence from CISA cyber threat advisories helps teams anchor paths in observed adversary behaviour, not just theoretical misconfigurations. Where AI systems are in scope, path analysis may also include prompt access, tool permissions, and model-adjacent secrets, which is why some organisations now pair it with MITRE ATLAS adversarial AI threat matrix for AI-enabled workflows.
Why It Matters for Security Teams
Attack-path modelling matters because it turns large, noisy environments into a prioritised picture of how compromise would actually unfold. That makes it especially useful for security teams trying to reduce blast radius, harden identity dependencies, and decide where zero trust measures will have the most effect. In practice, the term is most valuable when cloud entitlements, human admins, service accounts, and NHI are interconnected, because those relationships often define the real attack surface more than device posture alone. It also helps teams see where an exposed credential, weak token hygiene, or overbroad role can undermine multiple controls at once. For AI-era environments, path modelling is increasingly relevant to agentic AI because an agent with tool access, secrets access, or delegated permissions can become part of the attack path itself if governance is weak. The technique is not a replacement for detection or prevention; it is a decision aid that shows which control failures are likely to compound. Organisational pain usually becomes visible only after a breach investigation reconstructs the route taken, at which point attack-path modelling becomes operationally unavoidable to explain how the compromise spread and what should be cut next.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0, NIST SP 800-53 Rev 5, NIST Zero Trust (SP 800-207) and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | ID.AM-01 | Asset and dependency visibility underpins attack-path modelling in NIST CSF. |
| NIST SP 800-53 Rev 5 | AC-2 | Account management and privilege control are core inputs to viable attack paths. |
| OWASP Non-Human Identity Top 10 | NHI guidance focuses on managing non-human identities that often form attack paths. | |
| NIST Zero Trust (SP 800-207) | Zero trust reduces implicit trust edges that attack-path modelling often exposes. | |
| NIST AI RMF | AI RMF applies when attack paths include AI systems, tools, or delegated agent actions. |
Maintain accurate asset and dependency inventories so path analysis can reflect real exposure.
Related resources from NHI Mgmt Group
- How should organisations respond when trusted access becomes the attack path?
- What breaks when attack path analysis is not used for AI workloads?
- How should security teams reduce reliance on perimeter controls when credentials are the main attack path?
- Why do stolen credentials remain such an effective attack path?
