An attack path is a route, not an event. Serious intrusions rarely happen in a single dramatic leap from outside to crown jewels; they unfold as a chain of small, individually unremarkable steps, each of which borrows something from the step before. A phished password becomes a mailbox. The mailbox reveals which server holds the finance data. A stale account on that server has more rights than anyone remembered. One weak link connects to the next, and the sum is a path from a place that seemed harmless to a place that very much is not. Learning to see those chains — before anyone walks them — is one of the most useful shifts a beginning defender can make.
The reason path thinking matters is that isolated findings lie to you about their own importance. A single low-severity misconfiguration looks ignorable on its own. But defense is not played one node at a time; it is played on a graph. What turns a minor exposure into a real problem is what it is connected to and what it grants access to next. Attackers reason this way instinctively, following the cheapest available edges toward value. Defenders who model the same graph can find and cut the connecting edges early, while it is still cheap and safe to do so.
A path is a graph of nodes and edges
The clearest way to picture an attack path is as a graph. The nodes are things an intruder could stand on or want: a laptop, a service account, a database, a cloud storage bucket, an administrative role, a build server. The edges are the relationships that let one node reach another: this account can sign into that machine, this machine can talk to that database, this role can grant itself more permissions, this shared credential unlocks three systems at once. An attack path is any connected sequence of edges that starts somewhere reachable and ends somewhere valuable. Framing it this way makes the defensive job concrete. You are not trying to imagine every clever thing an attacker might do; you are trying to understand the edges that already exist in your environment, because those edges are the only routes anyone can travel.
Two properties of the graph do most of the work. The first is reachability: which nodes can be touched from outside, or from a place an outsider could plausibly land. The second is privilege: how much power sits at each node, and whether an edge lets that power grow. Dangerous paths tend to combine a highly reachable starting node with one or two edges that quietly escalate privilege along the way. When you learn to spot those combinations, you stop treating every finding as equally urgent and start prioritizing the edges that shorten or empower a route to something that matters.
Chokepoints and where to cut
Because a path is a chain, it fails if any single link is broken. That is the defender’s structural advantage. You do not need to fix everything on a route; you need to find the link where cutting does the most good for the least disruption. Security teams call these chokepoints — edges that many different paths run through. A shared administrative credential used across a dozen machines is a chokepoint: remove or scope it down and you sever many routes at once. A single network segment that everything can reach is a chokepoint in the other direction, because it gives a foothold too many onward edges. Requiring strong authentication at a widely used entry point, or isolating a segment so it can no longer talk freely to the rest, collapses whole families of paths without touching every node individually.
Thinking in chokepoints turns an overwhelming map into a short list of high-value moves. Rather than asking “how do I secure all fifty nodes,” you ask “which three edges, if removed, cut the most routes to my most valuable node?” The related guides in this collection describe the specific kinds of edges that recur: the way authentication weaknesses open entry points, covered in MFA, Passkeys, and Recovery Paths ; the way flat networks hand out too many onward edges, covered in Network Segmentation and Flat Networks ; and the way over-broad permissions let privilege grow mid-path, covered in IAM Roles and Least Privilege .
Toy example
Consider a fictional design studio, Halcyon Works, with a public website, an internal file server holding client contracts, a cloud account, and a small set of staff logins. Drawn as a graph, the public website is highly reachable but holds nothing sensitive. The contracts server is valuable but sits inside the network. Between them lies a support account that can sign into both — and, it turns out, an old shared password that a departed contractor’s login still accepts.
A path becomes visible: reach the exposed website, use the support account’s ability to move inward, and land on the contracts server through the stale login. None of these facts is alarming alone. The website is supposed to be public. The support account is supposed to reach both places. The old login was simply never removed. The danger is the sequence. The defensive read is not “we are breached” but “there is a route here, and the cheapest link to cut is the stale contractor login.” No system is scanned, no credential is guessed, and no step is actually performed — the studio and every detail are invented. The exercise is only about seeing how ordinary edges compose into a route.
What evidence matters?
Path thinking runs on relationship evidence, which is different from the point-in-time signals triage usually starts with. The questions worth answering are structural: from any given node, what can it reach, and what can reach it? Which identities can sign into which systems? Which permissions can be used to grant further permissions? Where does a single credential unlock more than one place? Good sources for this are inventories of accounts and their rights, records of network reachability between segments, group and role memberships, and lists of externally exposed services. A defender modeling a path wants those relationships written down and dated, because the graph drifts constantly as people add access “just for now” and forget to remove it.
The strongest path evidence is the kind that lets someone else reconstruct the same route without trusting your intuition. “This account can reach both the website tier and the contracts server, per the access records exported today” is a checkable claim about an edge. “An attacker will definitely use this” is a prediction the evidence does not support. Keeping those separate is what makes a path map a planning tool rather than a scare story. It also keeps the work honest: a modeled path is a hypothesis about what is possible, to be confirmed against real access records, not a declaration that anything has happened.
Worked defensive review
Reviewing a candidate path means writing the route as a short chain of checkable claims and then asking, for each link, whether it is true and whether it is the best place to cut. For Halcyon Works you might write: the website tier is externally reachable; the support account can sign into both tiers; a stale contractor login still authenticates on the contracts server. Each of those is a fact an access record can confirm or refute. Then comes the judgment layer — how confident are you that the edge exists, and how much would cutting it cost. Removing the stale login is low cost and high value, so it rises to the top. Narrowing the support account’s reach is more valuable still but touches a live workflow, so it needs an owner conversation. The review’s output is a ranked, small list of edges to change, each tied to the evidence that the edge is real, exactly the kind of note the discipline in Evidence-First Triage produces.
Common mistakes and false positives
The first common error is treating every theoretically possible path as an emergency. A graph of any size contains enormous numbers of hypothetical routes, most of them requiring conditions that do not hold. The discipline is to weight paths by reachability and privilege, not to panic at their sheer number. The mirror error is refusing to model paths at all because “we would need real access to prove it” — mapping the edges that exist is legitimate, valuable defensive planning even before anything is confirmed. A third mistake is over-fixing: rushing to change dozens of nodes when cutting one chokepoint would have collapsed the same routes with far less disruption.
False positives in path modeling usually mean a route you drew turns out not to exist — the account no longer has that access, the segment was already isolated, the credential was rotated last month. That is a good outcome, not a wasted effort. Every disproven edge tightens your map of what is actually connected, and an accurate map is the whole point. The recurring failure is the opposite: assuming an edge is absent because it “should” be, without checking the record. Paths live in the gap between how access was intended and how it accreted, and that gap is exactly where you should be looking.
Practice lab
Spend twenty minutes drawing one invented graph. Sketch four or five fictional nodes — a public app, an internal server, a cloud account, an admin role — and draw the edges you imagine between them: who can sign into what, what can talk to what, which permission can grow. Then trace one route from an exposed node to a valuable one, name the single edge you would cut first, and explain in one sentence why cutting there beats cutting elsewhere. Keep every element imaginary and never map, scan, or probe a real environment; the skill being built is the reading of relationships, not the touching of systems. Finish by writing the one edge you were least sure existed, since that is the claim your map most needs to verify.
What to do next
If the graph view is new, ground it first in the trunk guide, Cyber Defense Quickstart: Think Like a Defender , then in Assets, Identities, Exposures, and Controls , which names the nodes and edges a path is built from. From there, follow whichever edge type dominates your environment: authentication into MFA, Passkeys, and Recovery Paths , network reach into Network Segmentation and Flat Networks , or permission growth into IAM Roles and Least Privilege . If you are looking at a live incident rather than a planning exercise, stop modeling and start preserving: keep the evidence intact, follow your incident-response plan, and involve qualified responders.
How this guide was made
This page is defensive education, drawn from public frameworks and widely documented breach patterns rather than any private technique. Its example is fictional and contains no exploit detail, so the reasoning is safe to practice on paper. It claims no certification, legal standing, or incident-response authority, and modeling a path here means sketching relationships for planning, never rehearsing an intrusion.
Official references
To go deeper, the MITRE ATT&CK Enterprise Matrix catalogs the individual technique steps that connect into paths, the NIST Cybersecurity Framework 2.0 helps organize defenses around the routes you identify, and the CIS Critical Security Controls v8 prioritizes the safeguards that most often sever common edges. Read them as maps of the terrain, not as certifications to earn.
Related guidebooks
Pair this with Cyber Defense Quickstart: Think Like a Defender for the underlying posture, Assets, Identities, Exposures, and Controls for naming the pieces a path connects, and Evidence-First Triage for confirming a modeled route against real records.
