Microsoft Sentinel and Defender: ITSM Integrations Explained

One of the main changes and advantages of onboarding Microsoft Sentinel to the Defender portal is the fact that alerts are automatically correlated into single incidents. Alert correlation will kick in when we have enough evidence that multiple alerts are related. This has great benefits, as it can quickly unveil multi-stage attacks that otherwise could look like unrelated harmless alerts. It also helps reduce the amount of incidents by merging those that are related.

However, each organization has its own internal processes, teams, etc., so transitioning to this new way of working can be challenging. Furthermore, for organizations that use external ITSM tools to manage their incidents and alerts this means the logic in the incident synchronization must be considered before onboarding Microsoft Sentinel on Defender. This is critical as you will need to make sure that updates on incidents due to correlation are properly reflected on your tool.

In this article, we will review the most relevant fields in the Azure management API and in the Microsoft security graph API. If you are building a new integration, we recommend transitioning to the Microsoft Graph security API. However, if you have an existing integration relying on the Microsoft Sentinel REST APIs, you can simply update what you have.

If you are using ServiceNow as your ITSM tool, we recommend using this out-of-the-box app provided by ServiceNow. It relies on the Azure Management API: Microsoft Sentinel - ServiceNow Store. The latest version includes improvements that take care of the correlation logic.

If you are using a different ITSM tool with an out-of-the-box integration, we recommend checking whether the latest version available already covers this change in the logic. Otherwise, if you wish to update or create your own integration logic, we are providing some guidance below.

How does the correlation logic affect incidents

Understanding how the correlation logic affects incidents and when it kicks in is the first step. We recommend reading our official documentation, which explains different scenarios for Incident correlation and merging. However, below we will describe in more detail how correlation affects incidents, bearing in mind how this can influence synchronization with external ITSM systems. Since correlation will automatically move alerts and close incidents, you need to understand how this works and check if your synchronization logic need modifications.

When two or more alerts are identified as related, they are aggregated into a single incident. This can happen in two ways:

• Existing incidents: Alerts from different incidents may be moved into a new or existing “target” incident. The original (“source”) incidents will lose those alerts and will be automatically closed. On Defender, any references to the ”source” incident will be redirected to the “target” incident. On Microsoft Sentinel on Azure, you will still see the old incident, although it will be closed, it will contain the tag “redirected” and it will contain a link to the “target” incident.
• New alerts: Alerts that are not yet part of any incident may be directly added to the “target” incident. Please keep in mind that Sentinel alerts that are triggered without an incident (which is possible through the Sentinel analytic rules settings) will not be considered for correlation. In other words, when Sentinel alerts are correlated to a target incident, there will always be a “source” incident which will be closed.

We recommend reading about the criteria for merging incidents is, as well as specific scenarios when incidents aren't merged. 

Using the Microsoft Sentinel REST APIs

If you have an existing integration based on the Microsoft Sentinel REST APIs, these are the relevant endpoints:

• Get all incidents Incidents - List - REST API (Azure Sentinel) | Microsoft Learn
• Get a specific incident Incidents - Get - REST API (Azure Sentinel) | Microsoft Learn
• Get all alerts for a specific incident Incidents - List Alerts - REST API (Azure Sentinel) | Microsoft Learn

What we observe in most organizations with external ITSM systems is that they generally synchronize incidents only, not alerts; and their analysts go to Microsoft Sentinel to view the alerts and other details, hunt, etc. Therefore, we will focus on the endpoint to get all incidents, which is probably the endpoint you are using today.

Let us have a look at the payload for an incident that has been closed due to redirection:

These are the relevant fields for you:

• id: Resource ID of the incident on Azure, now closed
• name: the incident GUID on Azure
• title: The source incident title (now closed, the new incident will probably have a different name)
• status: it will always be closed in this scenario
• labelName: It will always be redirected in this scenario, this tag is automatically added to incidents closed by automatic alert correlation
• ncidentNumber: the incident number of the source incident in Azure
• alertCount: this will always be zero in this scenario, as the incident was emptied and alerts were transferred to the target incident
• providerIncidentUrl: The url of the target incident on Defender where you can find the transferred alerts
• providerName: Once you onboard your Microsoft Sentinel workspace to Defender, this field will always be Microsoft XDR, as all incidents (also Sentinel incidents) are created on Defender
• providerIncidentId: the target incident ID on Defender

Updates you could make

A logic you could implement is to have an automation rule that detects when an incident is updated with the tag “Redirected”:

 

This should trigger a logic app that calls your ITSM system:

• On your ITSM system, make sure you are mapping the providerIncidentUrl (link to Defender), this is important for two reasons:
  • The link on the ITSM system should take your analysts to Defender, as it contains all the details of the incident and the alerts
  • The API only references the url of the target incident on Defender. Since you probably want to update the target incident on your ITSM system, you will need to find the “providerIncidentUrl” on your system.
• Close the source incident on the ITSM system
• Update the source incident on the ITSM system with a description/comment with a link to the providerIncidentUrl (which is the URL of the target incident)
• On the target incident (providerIncidentUrl) on the ITSM system, add a description/comment mentioning the incident absorbed the alerts from the former incident
• Potentially increase severity of your target incident on the ITSM system
• Other more complex logics could include updating the owner.

Important!

• Bear in mind that Incident provider is no longer a condition you can select on Defender because, once you onboard Microsoft Sentinel to Defender, the incident provider is always Microsoft Defender XDR. If you use this condition today, please change it to Alert product names instead (if you wish to make a distinction between different alert providers)
• The incident title is no longer predictable, as incident names can change through merging. If you use incident title as a condition, please change it to Analytic rule name and select the analytic rule that should trigger the automation.
  • You can use mariocuomo​ 's script, which generates a report with a list of all automation rules that contain either of these conditions, so you can update them before transitioned to Defender: mariocuomo/Sentinel-Transition-To-Defender-Helper-Script: This repository contains an helper script that I developed to assist Sentinel customer to adopt Sentinel in Defender.

While other changes should not affect you in this logic, we recommend reading Configure automation rules and playbooks in Defender to understand what else changes.

Using the Microsoft Graph security API

If you are building a new integration, or if your previous integration needs multiple updates, we recommend creating your integration based on the Microsoft Graph security API.

This is the API endpoint in the Microsoft security graph API to get your incidents: https://graph.microsoft.com/beta/security/incidents

If you want to get alerts under your incidents as well, please use this endpoint to get incidents and corresponding alerts: https://graph.microsoft.com/beta/security/incidents?$expand=alerts

Important! Please note that alerts triggered by Sentinel analytic rules where an incident is not created are not visible on Defender, although they will be visible on the SecurityAlert table (either on the Microsoft Sentinel Azure portal, or on Defender in Advanced Hunting). This means that the Microsoft Graph security APIs cannot be used yet to submit your alerts to an ITSM system. If you wish to send alerts to an ITSM system, please use the Microsoft Sentinel REST APIs.

Now, let’s have a look at the API response for an incident that was redirected:

 

 

These are the relevant fields for you:

• id: The id of the source incident on Defender
• status: it will always be “redirected” in this scenario.
• incidentWebUrl: this is the url of the source incident on Defender, now redirected
• redirectIncidentId: the ID of the target incident on Defender
• lastModifiedBy: In this scenario you will always see Microsoft 365 Defender-AlertCorrelation

As you probably noticed, in the Graph API you will not find Azure Sentinel fields.

What would my logic look like

Assuming you are using the Microsoft Graph security API, you are already streaming your Defender incidents to your ITSM system. If you want to update your logic to close source incidents where alerts have been transferred to a target incident, your logic could look like this:

• Run a logic app every few minutes to check for incidents that changed the status to “redirected”. You can do it through such an API call: https://graph.microsoft.com/v1.0/security/incidents?$filter=status eq 'redirected' and lastUpdateDateTime ge 2025-09-03T11:15:00Z (add the correct timestamp here)
• Now, you can find those incidents on your ITSM system and update them:
  • Close them on the ITSM system
  • Add a description or comment with the new incident (redirectIncidentId)
  • You could make more changes, like going to the target incident on your ITSM system and detail there that your incident has absorbed alerts from a source incident.
• Remember you can add tags to your incidents on Defender too, such as the incident ID on your ITSM system. This will make synchronization easier. You can refer to the field “customTags” for this purpose.

Special thanks to my colleagues NChristis​, sagiyagen365​ and BenjiSec​ for reviewing and contributing to this article!