Iron Contributor

May 06, 2026

Identity Attack Graph in Microsoft Sentinel

Identity is now one of the most important attack surfaces in cloud security. In many real-world incidents, attackers do not rely only on malware or network movement. Instead, they abuse identities, permissions, role assignments, group memberships, service principals, and misconfigured access paths to move from an initial compromise to high-value resources.

This is why the new Identity Attack Graph in Microsoft Sentinel is an important capability. It helps security teams visualize how identities are connected to Azure resources and how an attacker could potentially move from one identity to another resource through permissions and relationships.

What is the Identity Attack Graph?

The Identity Attack Graph in Microsoft Sentinel provides a visual way to understand how identities, permissions, groups, and Azure resources are connected.

Instead of manually checking multiple portals, logs, and role assignments, the graph helps analysts understand relationships such as:

Which identities have access to specific Azure resources
Which users or service principals are over-privileged
Which groups provide indirect access to sensitive resources
Which identities may have a path to critical assets
What the potential blast radius of a compromised identity could be
How attackers could move laterally through identity and permission relationships

This is especially useful because identity risk is often not obvious when looking at a single user, group, or role assignment in isolation. The real risk usually appears when these relationships are connected together.

A user may not directly have access to a sensitive resource, but the user may be a member of a group that has access to another resource, which then has permissions that create a path toward a high-value asset.

The Identity Attack Graph helps expose these hidden relationships.

Why this matters

In many Azure environments, permissions grow over time. Users change roles, groups are reused, emergency access is granted, service principals are created, and temporary permissions are not always removed.

As a result, organizations often end up with:

Too many privileged identities
Unused or stale permissions
Service principals with excessive access
Guest users with unnecessary permissions
Groups that provide indirect access to sensitive resources
Subscription-level roles that are broader than required
Lack of visibility into who can reach critical assets

Traditional investigation usually requires analysts to move between several places, including Microsoft Entra ID, Azure RBAC, Azure Activity logs, Sentinel queries, Defender XDR, and Azure Resource Graph.

The Identity Attack Graph reduces this complexity by presenting identity relationships as a connected graph.

This makes it easier to answer practical security questions such as:

“What can this identity access?”
“What happens if this user is compromised?”
“Which identities have a path to critical resources?”
“Which access path should we remediate first?”
“Which permissions create the highest risk?”
“Why does this identity have access to this asset?”

Key use cases

The feature can support several important identity security and cloud security scenarios.

1. Attack path discovery

Security teams can use the graph to identify how an attacker could move from a compromised identity to a sensitive Azure resource.

This is useful during both proactive assessments and active incident response.

For example, if a user account is suspected to be compromised, the graph can help identify which resources may be reachable through that identity’s direct or indirect permissions.

2. Blast-radius analysis

When an identity is compromised, one of the first questions is:

What could the attacker access with this identity?

The Identity Attack Graph can help analysts understand the potential impact of a compromised user, group, service principal, or managed identity.

This can help with containment, prioritization, and communication with stakeholders.

3. Over-privileged identity detection

The graph can help identify identities that have more permissions than they need.

Include:

Users with Owner or Contributor access at subscription level
Service principals with broad permissions
Guest users with privileged access
Groups that grant access to sensitive resources
Identities that have access to multiple critical assets

This is useful for enforcing least privilege and reducing identity attack surface.

4. Privileged access review

IAM and cloud security teams can use the graph to support access reviews.

Instead of only reviewing a list of role assignments, teams can understand the real impact of those permissions.

This helps answer:

Is this role assignment still required?
Does this group create unnecessary risk?
Does this identity have access to critical resources?
Is this access direct or inherited?
Is this path expected or suspicious?

5. Incident response and threat hunting

For SOC teams, the graph can support investigations involving:

Suspicious sign-ins
Compromised users
Privilege escalation
Suspicious role assignments
Lateral movement
Service principal abuse
Unusual access to sensitive resources

The graph does not replace logs or hunting queries, but it gives analysts a faster way to understand relationships and prioritize what to investigate next.

Important prerequisites and setup notes

During my evaluation, there were a few important setup requirements that should be clearly highlighted.

Microsoft Sentinel permissions

The environment must already be onboarded to Microsoft Sentinel, and the user testing or configuring the feature must have the appropriate Microsoft Sentinel permissions.

The documented role requirement includes Microsoft Sentinel Contributor.

However, in my experience, this is not always enough for the full onboarding and validation experience.

Subscription-level Owner permission

One important prerequisite that should be clearly mentioned is that Owner permissions at the Azure subscription level may be required.

This is especially important during onboarding and activation, because the graph depends on access to Azure resource and permission relationships.

If the user does not have sufficient subscription-level permissions, some setup steps or visibility into resources and relationships may not work as expected.

Recommended permission note:

In addition to Microsoft Sentinel permissions, ensure that the user configuring the preview has Owner permissions at the subscription level for the subscriptions that should be represented in the graph.

This should be made very clear in the onboarding documentation to avoid confusion during deployment.

Required data connector: Azure Resource Graph

Another very important setup step is the Azure Resource Graph data connector.

The Azure Resource Graph connector must be:

Installed manually

Activated manually

Connected to the relevant Sentinel workspace

This is a key point. The connector is not automatically enabled just because the Identity Attack Graph feature is available.

Without this connector, Sentinel may not have the required Azure resource relationship data needed to build a useful graph.

Why Azure Resource Graph is important

Azure Resource Graph provides visibility across Azure resources, subscriptions, and relationships. For an identity attack graph, this data is essential.

The graph needs to understand not only identities, but also the resources those identities can reach.

This may include:

Subscriptions
Resource groups
Storage accounts
Key Vaults
Virtual machines
Managed identities
Role assignments
Resource relationships
Resource hierarchy
Critical assets

Without Azure Resource Graph data, the attack graph may not provide the full picture of how identities connect to Azure resources.

For this reason, I believe the onboarding instructions should explicitly state:

The Azure Resource Graph data connector must be manually installed and activated before using the Identity Attack Graph.

Recommended onboarding checklist

Before using the Identity Attack Graph, I would recommend validating the following:

Requirement

Recommendation

Microsoft Sentinel workspace

Ensure the workspace is active and accessible

Sentinel role

Microsoft Sentinel Contributor or equivalent access

Subscription permissions

Owner permissions at subscription level

Azure Resource Graph connector

Manually install and activate the connector

Azure RBAC visibility

Ensure access to relevant role assignments

Microsoft Entra ID visibility

Ensure identity and group data is available

Resource visibility

Validate that relevant subscriptions and resources are visible

Data freshness

Allow enough time for data collection and graph population

This checklist can help avoid issues where the feature appears available but does not show the expected relationships.

How the Identity Attack Graph improves investigation

Before using a graph-based approach, an analyst often needs to manually collect and correlate data from multiple sources.

A typical investigation may include:

Checking the user in Microsoft Entra ID
Reviewing group memberships
Reviewing Azure RBAC assignments
Checking subscription-level access
Looking at resource-level permissions
Reviewing PIM activations
Searching Sentinel logs
Running KQL queries
Checking Azure Activity logs
Validating access with cloud or IAM teams

This process can be time-consuming.

The Identity Attack Graph helps reduce this effort by showing relationships visually. This allows the analyst to understand the possible path faster and decide where to focus.

For example, instead of manually asking:

“Does this user have access to this resource through any group, role, or inherited permission?”

The graph can help show the relationship directly.

This is valuable because many risky permissions are indirect. The user may not have direct access, but may inherit access through a group, role assignment, nested relationship, or service principal path.

Where validation is still needed

Although the graph provides strong visibility, I would still validate findings before taking remediation action.

This is especially important because removing access can affect business operations or production systems.

I would still validate with:

Microsoft Sentinel KQL queries
Microsoft Entra sign-in logs
Microsoft Entra audit logs
Azure Activity logs
Azure RBAC role assignments
PIM activation history
Defender XDR signals
Defender for Cloud recommendations
Azure Resource Graph queries
IAM team input
Cloud platform team input
Application owner confirmation

The graph is very useful for discovery and prioritization, but final remediation decisions should still be validated.

GQL and graph-based investigation

One of the interesting aspects of this feature is the use of graph-based thinking.

Security teams are already familiar with query languages such as KQL for log analytics. However, graph investigation is different.

KQL is excellent for searching and analyzing events over time, such as sign-ins, alerts, audit logs, and activity logs.

Graph Query Language, or GQL, is designed for querying connected data. Instead of only asking what happened at a specific time, graph queries help answer how entities are connected.

In identity security, this is very powerful because the risk often exists in the relationship between objects.

Graph entities include:

Users
Groups
Service principals
Managed identities
Roles
Subscriptions
Resource groups
Azure resources
Permissions
Sessions
Attack paths

Graph relationships include:

User is member of group
Group has role assignment
Identity has access to resource
Service principal owns application
Managed identity can access Key Vault
User can escalate privilege
Identity can reach critical asset

This allows analysts to ask more relationship-focused questions, such as:

Which identities can reach this resource?
What is the shortest path from this user to a critical asset?
Which groups create privileged access?
Which service principals have paths to sensitive resources?
Which identities have indirect access through nested relationships?
Which attack paths include subscription Owner or Contributor permissions?

KQL vs GQL: why both are useful

KQL and GQL serve different but complementary purposes.

Area

KQL

GQL / Graph Querying

Main purpose

Analyze logs and events

Analyze relationships and paths

Best for

Time-based investigation

Connected identity/resource investigation

question

“Did this user sign in from a risky location?”

“What resources can this user reach?”

Data model

Tables

Nodes and edges

Common use

Detection, hunting, analytics

Attack path discovery, relationship mapping

Strength

Event correlation

Path discovery

In practice, security teams need both.

KQL can identify a suspicious sign-in.
The Identity Attack Graph can show what the compromised identity could access.
KQL can then be used again to validate whether the attacker interacted with those resources.

This creates a strong workflow between event-based detection and relationship-based investigation.