Every one of those events is a fact. But none of them, on its own, is context.
The problem isn't the data. It's how we're forced to look at it. Traditional SIEMs present security telemetry as isolated events in flat tables. To understand an attack, analysts have to manually connect the dots. They query one table for authentication logs. Another table for file access. A third for network connections. They look for common fields, matching usernames or IP addresses, trying to stitch together a narrative from fragments.
It's slow. It's error-prone. And it's fundamentally misaligned with how attacks actually work.
When an adversary compromises your environment, they don't think in log entries. They think in relationships and pathways.
"I've got credentials for this user account. What systems can that user access? Which of those systems have access to sensitive data? What's the shortest path from where I am now to where I want to be?"
Attackers are navigating a graph. They're moving through a network of connected entities, exploiting relationships between users, devices, applications, and data. Each step in their attack chain leverages a relationship. A user trusts a device. A device can access a server. A server can query a database. A database contains the target information.
Meanwhile, defenders are stuck trying to reconstruct that graph by manually joining log tables. We're trying to solve a graph problem with table lookups at machine speed.
That mismatch is exactly why modern security architecture is moving toward unified, graph-based correlation instead of isolated tabular analysis. Sentinel, Defender XDR, Entra, and Purview are converging around this model not because graphs are an interesting data structure, but because the problem is inherently a graph problem.
Let me walk you through what investigation looks like in a traditional SIEM.
You get an alert: suspicious file access on a file server. The log shows a username and a timestamp. That's your starting point.
First question: Is this user behaving normally? You query the authentication logs. Filter by username. Look at login patterns over the past week. You see the user authenticated from a workstation you don't recognize. New device? Compromised credentials? You need more context.
Second question: What is that workstation? You pivot to asset inventory. Search by hostname or IP. Find some basic information about the device. It's registered to someone in accounting, but your suspicious user is in marketing. That's interesting. You make a note.
Third question: What else has that workstation been doing? Back to the logs. Query endpoint detection telemetry. Filter by hostname. You see some process execution that looks suspicious. Maybe PowerShell with encoded commands. You copy the command, decode it, try to figure out what it was doing.
Fourth question: Did this user access anything else suspicious? Query file access logs again. Different table, different schema. Filter by username and timestamp range. You see access to several file shares. Now you need to check if those shares contain sensitive data. That's probably in a different system. Maybe your data classification tool, maybe a manual spreadsheet someone maintains.
You've been at this for 20 minutes and you're juggling findings from five different queries across multiple systems. You're trying to hold the entire picture in your head because there's no visualization showing you how these pieces connect. You're building the graph manually, one query at a time, hoping you don't miss a connection.
Now multiply that effort across every alert. Every investigation. Every threat hunt. And hope your analysts don't burn out from the cognitive load.
At its core, a security graph models two things: the entities in your environment and the relationships between them.
The entities are everything that matters in your digital estate: users, devices, applications, servers, files, IP addresses, cloud resources. The relationships are the activities and permissions that connect them: authentication, access, communication, containment, trust.
When you model security data as a graph, you're representing your environment the way it actually exists. As a web of interconnected entities where relationships matter as much as the entities themselves.
Traditional SIEM correlation asks analysts to infer relationships from logs. A security graph stores those relationships as first-class objects. That distinction sounds subtle. The operational difference is enormous.
This isn't a new concept in computer science. Graph databases power social networks, search engines, and fraud detection systems. Security operations has been stuck in the tabular world, even though the problems we're trying to solve are inherently graph problems.
The advantage of graph-based analysis isn't just visualization, though that helps. It's that graph structures align with how security threats actually manifest.
Attack paths are graph traversals. An attacker moving laterally through your network is literally walking a graph. They move from one node (compromised workstation) to another node (file server) along an edge (network access). Then from that file server to a database along another edge (application trust relationship). The attack path is a sequence of connected nodes and edges.
Blast radius is graph reachability. When you want to know "what could an attacker do from this compromised account?" you're asking a graph question. What nodes are reachable from this starting node? What sensitive resources are within two hops? Three hops? The answer is the subgraph of all connected entities.
Privilege escalation is graph analysis. Attackers look for paths to higher privileges. Maybe they can't directly access the domain controller, but they can compromise a service account that has admin rights on a server that has a trust relationship with the DC. That's a three-hop path through the graph. Finding those paths is exactly what graph algorithms are designed to do.
Data exfiltration follows relationships. Sensitive data doesn't exist in isolation. It's stored in databases, accessed by applications, queried by users, backed up to storage, synchronized to cloud services. Understanding the potential exposure of sensitive data means understanding all the entities that have relationships with it. That's a graph problem.
When your data model matches the structure of the problem you're solving, everything gets easier. You stop fighting against your tools and start using them the way they were meant to work.
Modern attacks don't stay in a single domain. They start with a phishing email, move to endpoint compromise, escalate through identity abuse, pivot into cloud resources, and culminate in data theft. That's five different security domains.
In a traditional SIEM architecture, each domain has its own logs, often in different tables with different schemas:
An analyst investigating a suspected breach needs to correlate across all five. They need to trace the phishing email to the user who clicked it, to the endpoint where malware executed, to the identity that got compromised, to the cloud resources that identity accessed, to the sensitive data that was exfiltrated.
Each of those pivots requires a manual query. Each query requires knowing which table to look at, which fields to join on, and how to account for schema differences. It's exhausting and time-consuming. And if you miss one connection, you miss part of the attack chain.
A unified graph solves this by modeling entities across all domains in a single structure. The phishing email node connects to the user node via a "received by" edge. The user node connects to the endpoint node via an "authenticated to" edge. The endpoint node connects to the identity node via a "compromised" edge. The identity node connects to the cloud resource via an "accessed" edge. The cloud resource connects to the data via a "contains" edge.
Now you can traverse that entire attack chain in a single query. You can visualize it in a single view. You can ask questions like "show me everything connected to this compromised user within three hops" and get an answer that spans all five security domains.
This is the real value of a unified security operations platform: not just more telemetry, but a correlation model that preserves relationships across identity, endpoint, cloud, and data. That's the architectural direction Microsoft has committed to across Sentinel, Defender XDR, Entra, and Purview, and it's why cross-domain attack chains that used to take hours to reconstruct are becoming single-query operations.
Graph-based security analysis reveals patterns that are invisible in tabular data.
Shared access patterns. Multiple users accessing the same sensitive resource might be legitimate. But if those users have no business relationship, no shared projects, and different reporting structures, that's worth investigating. In a graph, you can see that pattern instantly. These users (nodes) all connect to this resource (node) but have no edges connecting them to each other.
Unusual relationship creation. When a new edge appears in your graph, that's an event. A user who has never accessed a particular server suddenly has an access relationship. A service account that typically only communicates with specific databases starts connecting to a file share. These new relationships are often the first sign of lateral movement.
Privilege path discovery. Attackers look for the shortest path to high-value targets. Graph algorithms can compute those same paths, showing you where your vulnerabilities are before an attacker exploits them. If a low-privilege service account is three hops away from domain admin through a chain of trust relationships and excessive permissions, that's a risk you need to address.
When you have graph-based security data, the investigation process fundamentally shifts.
Instead of starting with a log entry and manually querying related tables, you start with an entity and explore its neighborhood in the graph. Click on a user, see all the devices they've authenticated to, all the resources they've accessed, all the other users they've collaborated with. Click on a device, see all the users who've logged into it, all the servers it communicates with, all the processes running on it.
This exploration is interactive and visual. You're not writing queries and waiting for results. You're navigating the graph, following edges, expanding nodes, filtering by properties. The investigation flows naturally from entity to entity, guided by relationships.
When you find something suspicious, you can instantly assess the blast radius. Right-click on a compromised account, select "show blast radius," and see every resource that account could potentially access. Not theoretically, based on permissions listed in Active Directory. Actually, based on observed behavior and established relationships in your environment.
You can also work backward. Start with a sensitive resource and trace all the paths that lead to it. Who has access? What accounts have permissions? Which devices have connected? What are the potential attack paths an adversary could follow? The graph shows you the answers.
Let's make this concrete with a realistic attack scenario.
Monday morning, you get an alert: anomalous file access. A user in marketing accessed a folder on the finance file server containing budget documents. The user, call her Alice, doesn't normally interact with finance systems.
In a traditional SIEM, you'd start querying. Check Alice's recent authentication history. Look at file access logs. Search for related alerts. Each query takes time, and you're building context manually.
In a graph-based system, you open the incident and see the entities already connected: Alice (user), her workstation (device), the file server (asset), and the accessed files (data). The relationships are visible: Alice authenticated to her workstation, the workstation established a network connection to the file server, and the file server logged access to specific files.
But the graph shows more. You expand Alice's node and see something interesting. She authenticated to her workstation at 7:45 AM, which is normal. But there's another authentication edge showing a login from a different device at 2:30 AM. You click on that device. It's a server in the DMZ, internet-facing. Alice has never authenticated to that server before. New relationship.
You expand that server's node. It shows inbound connections from external IP addresses. One of those connections happened at 2:15 AM, fifteen minutes before Alice's account logged in from that server. You've found the entry point. The attacker compromised the DMZ server, then used it to authenticate with Alice's credentials.
Now you trace forward. After authenticating to Alice's workstation at 2:30 AM, what did the attacker do? The graph shows lateral movement. Connection to a file server in HR. Connection to a database server. Connection to the finance file server where the anomalous access triggered the alert.
You can see the entire attack path in one view. Compromise of DMZ server, credential theft, lateral movement through three internal systems, access to sensitive data. The relationships tell the story.
You can also immediately assess impact. Right-click on Alice's account, check blast radius. The graph shows every system Alice's account has access to, every file share, every application. That's your containment scope. You need to rotate Alice's credentials, isolate the compromised systems, and check logs for any other malicious activity using those credentials.
What took 30 minutes of manual querying and correlation in a traditional SIEM took five minutes of graph exploration. More importantly, you're confident you found the complete attack chain because the graph showed you all the relationships.
The real power of a unified security graph isn't just within SIEM use cases. It's the connective tissue between security operations, identity security, endpoint security, cloud security, and data security.
Microsoft's graph-based security model across Sentinel, Defender XDR, Entra, and Purview isn't just modeling entities within a single tool. It's pulling identity, endpoint, cloud, and data context into the same correlation layer.
That's platform doctrine, not a roadmap item. The unified portal, cross-domain alert correlation, and attack path analysis capabilities are already moving in this direction. This is also why attack path analysis and exposure management are becoming central to modern security operations, not separate reporting exercises.
This means you can start an investigation in Sentinel, follow a relationship into Defender XDR to examine endpoint behavior, pivot to Entra to check identity context, and end up in Purview to assess data impact. It's the same graph, accessible from different tools but representing a unified view of your security posture.
That convergence matters because attacks don't respect tool boundaries. When an analyst is investigating an incident, they shouldn't have to think about which console to switch to. The graph should show them all the relevant context regardless of which security domain the entities belong to.
Adopting graph-based analysis isn't just a technology change. It's a workflow change. Your analysts need to stop thinking in queries and start thinking in relationships.
That mental shift takes time. Analysts who've spent years mastering query languages need to learn graph exploration. Instead of asking "show me logs where this field matches that value," they need to ask "show me everything connected to this entity."
The good news is that graph-based investigation is often more intuitive, especially for junior analysts. Following relationships is closer to how humans naturally think about cause and effect. You don't need to be a query expert to understand "this user connected to this device which accessed this server which touched this data."
The operational impact shows up in mean time to resolution. Investigations that took 30 minutes compress to 10 minutes. Complex attack chains that required multiple analysts to piece together become visible to a single analyst in one view. False positives get triaged faster because the context is immediately available.
The shift from tables to relationships is not just an analyst productivity gain. It is a different operating model for the SOC.
More importantly, graph analysis enables questions that were practically impossible before. "Show me all the ways an attacker could reach this critical asset from any compromised endpoint." That's a graph traversal query that would have required hours of manual work in a tabular system. With a graph, it's a single query that runs in seconds.
As long as defenders are forced to investigate in tables, they will keep missing attacks that live in relationships.
The attackers are already thinking in graphs. The forest is already there. The question is whether your platform lets you see it.