The previous post focused on why attackers think in relationships and why defenders get trapped when they are forced to work in tables. This post is about what defenders can actually do once they have the graph.
A security graph is not just a better investigation tool. It is a control plane for exposure management. It shows what could happen before a breach, what is reachable during one, and what data was touched after the fact. Those are three distinct capabilities, and they operate at three different points in the attack lifecycle.
Most security programs over-index on the third one.
Before going further, it helps to be precise about what the graph is doing in each phase.
Attack path analysis answers: what could happen? Given your current environment, what chains of relationships could an attacker exploit to reach a high-value target? This is pre-breach intelligence. It lets you find and break paths before anyone walks them.
Blast radius assessment answers: what is reachable right now? Given a compromised identity, device, or service account, what systems, data, and resources fall within its reach? This is incident-time intelligence. It compresses scope assessment from hours to seconds.
Incident graph reconstruction answers: what appears to have happened? Given observed activity, what is the sequence of entities and relationships involved? This is post-event intelligence. It builds the timeline and connects the chain.
Traditional security operations focuses almost entirely on the third. Graph-based security operations uses all three, and uses them in order.
Every organization has attack paths. Most of them are invisible until an attacker finds them first.
The obvious ones are well understood. A domain admin account logging into a developer workstation creates a direct path. If that workstation is compromised, the attacker has domain admin credentials. Policies exist against this because the risk is intuitive.
The dangerous ones are not obvious at all, because the risk is emergent rather than explicit.
Consider this chain: a service account with read access to a configuration file that contains database credentials, running on a server that a contractor VPN can reach, connecting to a database that stores customer PII. That is a four-hop path from external access to sensitive data.
Here is what makes it hard to find: every individual relationship in that chain is justified. The service account needs read access to do its job. The credentials need to be in the config file. The server needs to be reachable from the VPN for legitimate business reasons.
Every individual relationship is justified. The problem is the path they create when combined.
Traditional vulnerability scanning does not find this. It finds misconfigured systems, missing patches, weak passwords. It does not find relationship risk, because relationship risk is not a property of any single node. It only becomes visible when you look at the graph.
Attack path analysis works by modeling your environment, mapping the relationships, and computing which sequences connect low-privilege entry points to high-value targets. The output is not a list of vulnerabilities. It is a ranked list of exploitable chains, each one showing the specific sequence an attacker would follow.
That is a different category of intelligence.
Finding attack paths solves half the problem. The other half is knowing which ones to fix first.
CVSS scores and asset criticality ratings are poor proxies for actual risk. A critical vulnerability on a completely isolated server is less urgent than a medium-severity finding on a system that is one hop from internet exposure. Severity without reachability is noise.
Attack path analysis lets you prioritize based on the factors that actually determine exploitability: path length, the sophistication required at each hop, the value of the target, and the compensating controls already in place.
A short path requiring minimal skill that leads directly to a domain controller is a priority. A six-hop path requiring advanced techniques at each step, crossing through network segments with enforced MFA and just-in-time access, is a lower priority even if the target is equally critical.
The graph also lets you evaluate remediation leverage. Some fixes break one path. Others break six. When you can model the effect of a proposed change and see how many attack paths it disrupts, you can direct remediation effort toward maximum impact. Remove one excessive permission, sever multiple chains. That is how you reduce exposure efficiently rather than just closing individual findings.
When an incident happens, the first question is always the same: how bad is this?
In traditional incident response, answering that question takes hours. You are querying logs, checking permissions, mapping the environment, building scope manually while the attacker may still be active.
Blast radius assessment answers the scope question immediately.
Select the compromised entity. Query its reachable neighborhood in the graph. The result is not theoretical exposure based on Active Directory group membership. It is actual exposure based on observed behavior and established relationships in your environment.
A compromised user account: every system that account has authenticated to, every resource it has accessed, every privilege it holds.
A compromised endpoint: every user who logs into it, every system it communicates with, every service running on it that could be leveraged for lateral movement.
A compromised service account: every system it has credentials for, every API it can call, every database it can query.
That immediate visibility transforms the response. You know what to contain. You know what credentials to rotate. You know what systems to inspect for persistence. You are not discovering scope as you go. You are seeing it upfront and making containment decisions from a position of actual knowledge rather than incomplete inference.
The graph also surfaces something easy to miss: alternative paths. Containing a compromised account does not fully secure every resource it touched if other accounts share access to the same systems. The graph shows you those overlapping relationships, so containment is complete rather than partial.
Security operations and data security have historically been separate disciplines. Different tools, different teams, different operating rhythms. The SOC handles the intrusion. The data security team handles the exposure assessment, usually later, usually through a separate process.
The graph collapses that separation.
When data sensitivity context from Purview feeds into the same graph layer as identity, endpoint, and cloud telemetry, data impact assessment becomes part of the initial investigation rather than a downstream concern.
The scenario looks like this: you are investigating suspicious activity on a user account. The investigation shows potential credential compromise and unusual file access patterns. In the traditional model, you open a ticket with the data security team and wait.
With an integrated graph, you pivot directly from the security incident to data impact. You see which files the compromised account accessed. You see their sensitivity labels. You see the data types involved, whether PII, financial records, or intellectual property. You see which other identities have accessed the same data, which may indicate broader exposure.
This is not a reporting improvement. It is a posture change. Data risk becomes a first-class input to threat analysis, not an afterthought addressed once the incident is closed.
These three capabilities, attack path analysis, blast radius assessment, and data impact investigation, represent a different security operating model.
The traditional model is alert-driven. Something triggers, analysts respond, scope gets established after the fact. The security posture is reactive by design because the tools only show you what has already happened.
The graph-based model is exposure-driven. You continuously assess what could happen. You understand potential impact before incidents occur. When incidents do occur, scope is immediate rather than reconstructed. Risk-based decisions are grounded in actual relationships, not theoretical concerns.
Microsoft's unified security operations model is moving in this direction across Sentinel, Defender XDR, Entra, and Purview, providing the substrate for this kind of integrated exposure management. Identity context, endpoint telemetry, cloud resource relationships, and data sensitivity feed into a single correlation layer. Investigations that used to require pivoting across four consoles and manually joining the context become single-graph explorations.
The hunting graph in Defender XDR makes this proactive capability operational. Start with any entity and traverse its relationships. Find contractor accounts with unexpected paths to privileged resources. Map lateral movement potential from likely initial access points. Surface anomalous relationship creation, new edges in the graph that signal compromise or misconfiguration, before they become incidents.
That shift, from looking at events to looking at relationships, from reacting to exposure to managing it, is the real value of operating with a security graph.
The attackers already know what is connected to what.
They are calculating paths, estimating blast radius, and identifying data targets before they ever trigger an alert.
The graph gives defenders the same map.
The difference is whether you use it before the attack, or only after you are forced to reconstruct what happened.