Security teams should build a relationship graph that connects assets, identities, permissions, applications, and telemetry. A flat inventory tells you what exists, but not how it is connected or where trust can be abused. The practical goal is to understand dependencies and access paths well enough to spot weak points before an attacker chains them together.
Why a relationship graph matters more than a flat inventory
A flat list of servers, apps, users, and endpoints is useful for asset management, but it does not show how an attacker can move. A relationship graph adds the missing context: which identities can reach which services, which permissions bridge environments, which applications depend on others, and where telemetry can confirm or deny suspicious paths.
The security value is not visual polish, it is path visibility. Once assets are connected by trust, dependency, and access relationships, teams can reason about blast radius, privilege chaining, and which weak links matter most to the actual attack surface.
That is why relationship graphs are often more operationally useful than CMDB-style inventories. They help separate isolated assets from reachable assets, and reachable assets from high-value paths that an adversary would naturally test first.
What the graph needs to show to be attacker-useful
The graph should not stop at hostnames and software versions. It needs the relationships that explain reachability and abuse potential, including identity to application access, service-to-service trust, admin pathways, secrets and tokens that enable those pathways, and telemetry that proves whether a path is actually active.
A useful graph also distinguishes direct connectivity from effective access. For example, a firewall rule, IAM grant, token scope, or delegated permission can matter more than network adjacency because attackers often exploit the shortest path to meaningful control rather than the shortest packet route.
When security teams model those relationships explicitly, they can ask better questions: which assets can be touched after one credential is stolen, which dependencies create shared failure points, and which dormant permissions or stale trust links silently expand the attack surface.
How to map exposure the way adversaries do
Start with the assets that can actually be abused: internet-facing systems, privileged identities, sensitive applications, integration points, and secrets stores. Then connect them through concrete relationships, such as authentication paths, authorization grants, third-party integrations, remote management channels, and data flows that reveal where a compromise can spread.
Threat modeling works best when the graph is enriched with evidence from logs, EDR, cloud control-plane events, and identity telemetry. That lets teams distinguish theoretical connectivity from observed and repeatedly exercised access paths, which is the difference between a large diagram and a usable attack-surface model.
For adversary perspective, combine the graph with known exploitation patterns. MITRE ATT&CK Enterprise helps teams think in terms of credential access, lateral movement, and privilege escalation, while CISA's Known Exploited Vulnerabilities Catalog helps prioritise exposed assets that are already being actively abused in the wild.
Risk and Threat Considerations
The main risk is false confidence. If the graph is incomplete, stale, or too abstract, teams may miss the exact trust path an attacker would use and overestimate the difficulty of moving from one foothold to another. That leads to weak prioritisation, because the most dangerous edges are often permissions, tokens, or dependencies rather than the most visible servers.
Failure mechanism: Hidden or stale relationships, especially excessive permissions, unused but valid access paths, and unmodelled third-party dependencies, let attackers chain apparently small exposures into broad reachability and privilege gain.
Impact: The organisation underestimates blast radius, misses likely pivot paths, and may leave high-value systems exposed even after obvious perimeter controls or vulnerable hosts have been addressed.
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 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1098 — Account Manipulation | Models how attackers abuse permissions and trust paths to expand reach. |
| T1078 — Valid Accounts | Explains why stolen or reused credentials make relationship graphs attack-relevant. | |
| Recommendation — Map access paths and privilege changes to T1098, then hunt for unexpected delegation or grant changes. Correlate identity-to-resource edges with T1078 indicators and prioritise reachable accounts. | ||
| NIST CSF 2.0 | ID.AM-01 — Identities and Roles | Asset mapping here depends on understanding which identities can reach which assets. |
| ID.AM-03 — Assets and Inventory | A relationship graph extends asset inventory by showing how assets connect and depend on each other. | |
| PR.AA-01 — Identities and Credentials Are Issued, Managed, Verified, Revoked, and Monitored | Access-path analysis relies on governed credentials and monitored trust relationships. | |
| Recommendation — Maintain an accurate inventory of identities and roles that can connect to critical assets. Document assets with their dependencies and trust relationships, not just their presence. Monitor credential lifecycle and revoke access paths that no longer need to exist. | ||
| NIST SP 800-53 Rev 5 | AC-4 — Information Flow Enforcement | Relationship graphs expose which information flows and trust paths are actually allowed. |
| AC-6 — Least Privilege | Attack-surface mapping is used to find overbroad reachability and excessive access. | |
| AU-6 — Audit Record Review, Analysis, and Reporting | Telemetry is needed to confirm which graph edges are active and abused. | |
| Recommendation — Enforce and review information-flow restrictions across mapped trust paths. Reduce reachable paths by removing unnecessary privileges and delegated access. Review audit and telemetry data to validate active access paths and suspicious pivots. | ||
Practitioner Guidance
What to prioritise: Build the graph around pathways to impact, not around asset count. The first relationships to model are identity-to-resource access, privileged delegation, service-to-service trust, and external dependencies that connect trust boundaries.
What to verify: Confirm that every high-risk edge is backed by current evidence, such as live authentication events, recent configuration data, or control-plane records. If a path cannot be observed or validated, treat it as uncertain until proven otherwise.
Practitioner takeaway: The goal is not to map everything equally, but to make the attack surface legible enough that the most reachable and most abusable paths are visible before an attacker discovers them.
Related resources from NHI Mgmt Group
- How should security teams prioritise cyber assets when the attack surface keeps expanding?
- How should security teams define assets in attack surface management to avoid missing exposure after changes?
- How should security teams build visibility into assets and identities before they try to improve cyber controls?
- How do security teams know whether they are testing the real attack surface?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 27, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
