A reachability graph is a directed model of which systems can plausibly be accessed from others. For security teams, it turns network and identity relationships into a structure that can be scored, compared, and reduced based on real attacker routes.
Expanded Definition
A reachability graph extends the primary definition by mapping not just direct connectivity, but the practical paths through which a system, workload, account, or service can be reached under real security conditions. In security operations, that means modelling the direction of trust, authorization, exposed interfaces, and dependency chains rather than treating the environment as a flat list of assets. The result is a graph that helps teams see how an initial foothold could move through infrastructure, identity layers, and service relationships. This makes the concept especially useful in cloud, hybrid, and identity-heavy environments where a single misconfigured route can create an unexpected path to sensitive resources. It also aligns well with control thinking in NIST SP 800-53 Rev 5 Security and Privacy Controls, where access and boundary protections must be understood in operational context.
Definitions vary across vendors on whether a reachability graph includes only network paths or also identity, privilege, and application-layer routes. At NHI Management Group, the more defensible view is the broader one: if an attacker can use it to get closer to a target, it belongs in the graph. The most common misapplication is treating the graph as a static topology diagram, which occurs when teams ignore firewall policy, privilege inheritance, service-to-service trust, and conditional access.
Examples and Use Cases
Implementing reachability analysis rigorously often introduces modelling overhead, requiring organisations to weigh better attack-path visibility against the cost of maintaining accurate environment data.
- Cloud teams use a reachability graph to show how a public load balancer, security group rules, and internal service permissions can create a path to a database subnet.
- Identity teams use it to trace whether a compromised admin account can reach privileged systems through delegated access, token reuse, or over-permissive role links.
- AppSec teams use it to understand whether an exposed API endpoint can reach secrets stores, message queues, or internal control planes through chained service calls.
- NHI teams use it to analyse whether a workload identity or agent credential can move from one cluster namespace to another, especially when trust relationships are broad or poorly segmented.
- For policy baselines, practitioners often compare the graph to guidance in NIST SP 800-207 Zero Trust Architecture to identify paths that should not exist at all.
In practice, reachability graphs are also used during change reviews, after infrastructure-as-code updates, and when validating whether compensating controls actually block the path a threat model says should be impossible.
Why It Matters for Security Teams
Security teams need reachability graphs because the hardest problems are rarely about a single vulnerable host. They are about how many small, legitimate relationships combine into an attacker route. A system may be individually hardened and still remain reachable through another host, a reused identity, or a service dependency that no one reviewed as a path. That makes the concept central to attack surface reduction, segmentation design, privilege minimisation, and identity governance. It is also one of the clearest ways to surface where NHI risk lives: service accounts, workload identities, API tokens, and agent credentials often create reachability that looks harmless in isolation but becomes dangerous when chained. That is why practitioners increasingly pair graph analysis with control expectations from NIST SP 800-53 Rev 5 and Zero Trust design assumptions.
When reachability is misunderstood, teams usually overestimate isolation and miss the paths that matter most to attackers. Organisations typically encounter the true impact only after a breach simulation, exposed credential, or lateral movement incident, at which point the reachability graph becomes operationally unavoidable to address.
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 SP 800-63 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AC-3 | Access control and remote access protections shape which paths remain reachable. |
| NIST SP 800-53 Rev 5 | AC-4 | Boundary protection governs how systems can be reached across trust zones. |
| NIST Zero Trust (SP 800-207) | Zero Trust assumes no implicit trust in any reachability path. | |
| OWASP Non-Human Identity Top 10 | NHI trust chains can create unexpected machine-to-machine reachability. | |
| NIST SP 800-63 | AAL2 | Authenticator assurance affects whether identity-based paths are realistically reachable. |
Require strong authentication before identity routes can be used to reach sensitive systems.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on July 11, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
