Microsoft announced on the 1st of July 2025 that the Microsoft Sentinel Azure Portal UI will be deprecated at the 1st of July 2026, and all requests will be redirected to the Security Portal instead. This means that all Microsoft Sentinel customers have 1 year time to transition to the Defender portal and change their processes.

Even though the technical switch is very easy to do, I had a lot of challenges to be able to switch to the Defender Portal during the last year. A lot of issues and bugs are already solved by now, but there are still some caveats and nuanced that you need to take into account when switching. In the first part you can read the challenges I personally struggled with, and in the second part you can find other challenges and nuances documented in the Learn pages.

This blogpost will only cover the challenges of the change, and not how to perform the change itself. For information on how to transition, you can use the below learning page:

Connect Microsoft Sentinel to the Microsoft Defender portal - Unified security operations

Learn how to connect your Microsoft Sentinel environment to the Defender portal to unify your security operations.

Microsoft Learnbatamig

This was strangely enough one of the biggest blockers for us before we could move to the Defender XDR portal with Microsoft Sentinel. In Microsoft Sentinel there is a feature where you can base your alert description on dynamic parameters of your KQL query:

With Microsoft Sentinel, the incident description was always the same as one of the alert descriptions, making it possible to use the incident description for further processing in your SOAR.

Once you connect Microsoft Sentinel with Defender XDR, the incident description is not populated anymore when a dynamic alert description is used. You can easily see this when querying the SecurityIncident table:

Somewhere in the beginning of 2025, Microsoft came with a 'fix' that allowed for the Incident Description to be populated again based on the dynamic alert description. Sadly enough, this was only a UI fix in the Defender XDR portal rather then a fix in the incident properties itself. You can see an example below where the incident description is surfaced in Defender XDR:

While you can see that this fix was not provided in the Azure Portal Microsoft Sentinel UI, nor in the SecurityIncident table:

So what if you rely on the incident description in your SOAR engine? Unfortunately you for now on have to rely on the alert description instead, since only the alerts will have the dynamic alert descriptions. Depending on how your SOAR engine works, this might be an easy or a more hard change to perform. If you are using Azure Logic Apps with the Incident created trigger, it is fairly easy to change to alert description since the alerts with their description are present in the incident object you receive in the Logic App via the alerts property:

If you however use the Azure REST API, you need to perform an extra API call to get all the alerts related to the incident:

Incidents - List Alerts - REST API (Azure Sentinel)

Learn more about Sentinel service - Gets all alerts for an incident.

Microsoft Learnkexugit

Once Microsoft Sentinel is integrated with the Defender XDR portal, all alerts and incidents generated via Microsoft Sentinel Analytic rules are correlated with the Defender XDR alerts and incidents via the Defender XDR 'black-box' correlation engine. In this correlation engine, there are multiple scenario's:

• An alert is 'unique' enough in the environment to trigger a new incident creation
• An alert relates enough to other alerts, for the new alert to be added to and existing incident of the already existing alerts
• Two existing incidents are correlated together because they are strongly alike

In practice, I did not encounter issues in the first two scenario's when alerts are merged in existing incidents. This was in fact something that always existed. But now that incidents of analytic rules can be merged together as well, this is something you need to take into account when you are syncing your incidents to external ITSM tools.

Lets take the follow scenario:

1. Let's say that incident number 1 is created at a certain time, and this incident is being synced to you ITSM tool.
2. 10 minutes later a second incident is created and is also being synced to your ITSM tool.
3. Again 10 minutes later, the correlation engine decides that these incidents are very much alike, and merges one incident into the other.

According to the documentation (https://learn.microsoft.com/en-us/defender-xdr/alerts-incidents-correlation#details-of-the-merge-process), the source incident is now automatically closed and all references are redirected to the destination incident, which eventually means that the source incident is not longer 'relevant' while it is still a distinct open incident in your ITSM tool.

Because of this, there is a discrepancy between your ITSM Tool and the Defender XDR portal.

The question you can ask yourself is, 'how bad is this?'. If a SOC analyst goes to Incident 2 that is closed, it will be automatically redirected to incident 1 if using the Defender XDR portal. If you currently still use the Azure Portal, you get a banner:

This means that the SOC Analyst will automatically research the correct incident. If they then start investigating incident 2 in their ITSM tool, they will get back to the same incident as before in Defender XDR seeing that the incident is already resolved. Depending on the procedures you use to investigate incidents, this might cause little or a lot of time loss. If you want to fix this behavior, you can find below how.

To fix the above issue, we need to sync the status of the incidents when an incident correlation is happening.

Even though this might seem as an easy fix, I learned that it is really not that easy. First of all, we need some kind of 'trigger' that starts an automation process when an incident is updated. This is something you can achieve with an Automation Rule and Playbook in Sentinel:

But when this Playbook is triggered, the incident object you receive does not include any object that tells you if the incident has been merged with another incident or not.

So I decided to reverse engineer the Security.Insights API a bit. And what I found is that when you use the Incidents - List API call (https://learn.microsoft.com/en-us/rest/api/securityinsights/incidents/list?view=rest-securityinsights-2025-06-01&tabs=HTTP) with the specific API version 2024-10-01-preview (API Version that is not publicly documented), you receive an incident objects that gives you the new Incident ID of the merger that happened:

But if you use any API version later then 2024-10-01 (even the preview versions), these properties are not surfaced anymore.

This makes me believe that at some point in time Microsoft was thinking to add this in the incident properties, but suddenly decided not to do it. Why? I have no idea.

But I didn't stop there! Next to the security.insights API, you can also use the Graph API to get incidents (https://learn.microsoft.com/en-us/graph/api/security-incident-get?view=graph-rest-1.0&tabs=http). So the first thing I did was searching for an incident that has been merged in Microsoft Sentinel (because that is the only UI where you can see a redirected incident, for the coming year at least 😉).

But to request an incident via the Graph API I need the Defender XDR Incident ID (yes the Incident ID in Microsoft Sentinel is not the same ID as the Incident ID in Defender XDR), so I had to search for the Defender XDR ID using KQL.

SecurityIncident
|summarize arg_max(FirstActivityTime,ProviderIncidentId,IncidentNumber) by tostring(AlertIds)
|project ProviderIncidentId, AlertIds=todynamic(AlertIds),IncidentNumber
| mv-expand AlertIds to typeof(string)
|project ProviderIncidentId, AlertIds,IncidentNumber
| where IncidentNumber == "3460"

With the Defender XDR Incident ID I could now query the Graph API and see if I can find the the new Incident ID to where this one has been merged. Only to see that I got a response that the Incident does not exist (via Graph Explorer) 😒:

I tried the same using the Graph Command Line tools, which also returned the same error (yes I had the correct permissions):

After banging my head against my desk, I noticed that both of these tests were using delegated permissions. So I decided to create a custom application, add the SecurityIncident.Read.All Application permissions to the app, and authenticate using client-credential flow:

After doing this, I was able to successfully retrieve the merged incident where we can see the redirectIncidentId we can use to find the incident where this one was merged to:

If you do not really care what the new incident ID is, you can also just rely on the redirected status that is automatically being added to an incident when it is being merged with another one.

To conclude the fix, I suggest to use an automation rules and Logic app triggering on 'incident update', which eventually uses the providerIncidentId of the incoming object to query the Graph API for that incident and look for the status and redirectIncidentId. When you found a redirected incident, you can then call the API of your ITSM tool to close the ticket related to the current incident, and merge the ticket with the ticket related to the redirected incident.

This issue is again related to the incident correlation engine as we spoke about in the previous case, but is now dedicated to specific incident which you never want to be merged. A lot of organizations use rules with specific tags which they push in the production environment for testing purposes. Let's say that you created a new detection rule but want to verify in the environment if that rule does not generate to much false positives. Of course you do not want incidents related to that rule being merged with other incidents, because that merger process might trigger a higher severity resulting in production impact.

Currently, the Defender XDR platform does not allow you to specify which analytic rules or custom detections need to be excluded from this incident merger logic. Because of this, we need to create some workarounds ourself.

Before we can understand the workaround, we need to understand the incident correlation logic. According to the Microsoft documentation, these are the scenario's when incident merger will never happen:

This means that the easiest workaround is automatically closing all testing rule incidents via an automation rule. If your testing rule always start with [TEST RULE] for example, you could use the following automation rule:

One very big caveat here, is that if your analytic rule uses alert grouping as shown below, this alert grouping will not work anymore. This because alert grouping also do not group alerts into a single incident when the incident is already closed:

This might result in a very high amount of incidents for a specific analytic rule which you previously didn't expect. If you want to fix this issue, we found that the only solution to this is not to auto close the incident to prevent mergers, but use automatic incident assignment instead. For these incident assignments it is important to note that the incidents are not being merged if there are two 'different people' assigned. But after testing we learned that even if you assign a user to one incident, that incident can still be merged with incidents that are unassigned! To fix this, we need to make sure that the [TEST RULE] incidents are assigned to one dummy user, and all other incidents are assigned to another dummy user.

Since all of the above are workarounds and a lot of organizations have this issue, I feel that we desperately need a native feature in Defender where we can choose which analytic rules and custom detections need to be excluded from the correlation engine.

Once you transition to the Defender XDR portal, all the people who are working with Microsoft Sentinel suddenly need Entra ID or Defender XDR roles as well. This because Microsoft Sentinel is an Azure resource and therefore uses the Azure RBAC, but Defender XDR has it own custom roles or need to be accessed via Entra ID roles.

Since the permission models are so big for both Entra ID, Defender XDR, Microsoft Sentinel and Log Analytics I will not go deep into the permissions since this can be a blogpost dedicated to this subject. The key factor here is that you need to give your analysts and engineers the appropriate roles via Defender XDR URBAC or Entra ID before they can use the Defender Portal. I find the following URBAC learn page the best one to map the different permissions to more general roles, which can help in designing your access architecture.

Map Microsoft Defender XDR Unified role-based access control (RBAC) permissions - Microsoft Defender XDR

Compare permissions and access to Microsoft Defender XDR Security portal experiences using role-based access control (RBAC)

Microsoft Learndenisebmsft

Even though I didn't encounter other significant challenges, there might be others you stumble across when connecting Microsoft Sentinel to Defender XDR. Therefore it is really recommended to look at the Microsoft documentation, and check all the things that change we you enable the connection:

Transition Your Microsoft Sentinel Environment to the Defender Portal

Move Microsoft Sentinel operations from the Azure portal to the Microsoft Defender portal.

Microsoft Learnbatamig