Written by Robin Dadswell, Principal Consultant
When I’m talking to customers one subject is coming up repeatedly. Microsoft Sentinel – and there’s a lot of confusion. Is it being retired? Is it being absorbed into Defender? Do we need new licenses? I want to explain what’s happening, when, and what it means for you.
But before we get into the detail let’s start with some clarity. Microsoft Sentinel is not being retired. Its Security Information and Event Management (SIEM) and Security Orchestration, Automation, and Response (SOAR) capabilities remain fully supported. What is changing is where and how it is managed: Sentinel is moving from the Azure portal into the Microsoft Defender portal as part of Microsoft’s broader ‘unified security operations’ strategy.
For IT teams, SOC analysts, architects and governance leads, here’s what that means both operationally and technically.
Microsoft Sentinel and Defender: in a nutshell
First a quick explanation – please skip ahead to What is and isn’t changing if you’re already familiar with Sentinel and Defender.
Microsoft Defender is Microsoft’s broad threat protection platform. It’s a family of products with each focusing on different aspects of your environment. Such as Defender for Endpoint (laptops, servers), Identity (Active Directory), Cloud (cloud workloads), Office 365 (email and collaboration), and Cloud Apps (SaaS).
Defender sits close to the asset and actively flags or blocks threats. It’s protective and preventative.
Whereas Microsoft Sentinel is a Security Information and Event Management (SIEM) and Security Orchestration, Automation, and Response (SOAR) platform. It works across your environment taking data from Microsoft Defender, firewalls, identity providers, third-party security tools, and cloud platforms (e.g. Azure, and AWS). It collects security logs, correlates signals, detects suspicious patterns, generates incidents for investigation, and automates response workflows.
What is and isn’t changing in the Sentinel move
The major change is the management experience. Sentinel will be exclusively managed through the Microsoft Defender portal – with the Azure Portal being retired.
The aim is to provide a unified security operations experience with a single pane of glass for both SIEM and Extended Detection and Response (XDR). It ensures a consistent user interface for SIEM and XDR with native, cross domain, correlation of incident timeline and evidence.
What is NOT changing:
- Sentinel’s core SIEM functionality remains
- Azure Log Analytics will remain the underlying data platform
- KQL (Kusto Query Language) analytics rules continue to operate
- Sentinel and Defender Access Controls
- Automation playbooks continue to function
- Sentinel licensing remains separate from Defender (see later).
Timelines
- New Sentinel workspaces are already, automatically onboarded to the Defender portal
- July 2026 (a date you may have heard) was the target date for retiring the Azure portal
- 31 March 2027 is the extended deadline for when Sentinel will cease to be supported in the Azure portal.
What IS changing
Underneath the surface there are some noteworthy changes affecting correlation, alert logic, and data schemas. Let’s look at each of these in a bit more detail.
Correlation is more cohesive
Historically, Sentinel has relied on KQL-driven analytics rules, scheduled queries and Fusion detection. Whereas Defender performed its own correlation within Microsoft 365 security.
In the unified Defender portal alerts from Sentinel and Defender XDR both feed into a shared incident model. Sentinel’s legacy Fusion engine is disabled as part of the move to the Defender Portal at which point correlation is processed via the Defender XDR logic, this unifies incident creation in the same manner as other Defender Alerts enabling a single logic flow for all alert generations.
What does not change:
- Custom KQL detections will still run
- Log-based analytics will remain intact
- Workspace-level data architecture remains.
What does change:
- Incident grouping logic is expected to evolve
- Alerts may appear more consolidated
- Multi-signal correlation becomes more tightly integrated.
For most, this will be an enhancement. But you should check alert tuning and correlation during transition.
Unified dynamic alerts and incidents
Previously Defender products generated alerts, which Sentinel grouped into incidents. Now, Defender XDR generates the incidents with Sentinel analytics alerts feeding into the same incident – and correlation can occur before an analyst sees the case.
In practice, this could mean that incidents are differently grouped, that alert-to-incident mapping shifts, and that there’s less noise with better cross-product stitching.
While these aren’t disruptive changes, it’s worth making some checks after transition:
- Validate incident population behaviour
- Confirm escalation workflows still align
- Review automation triggers.
Table and data schema: evolution, not revolution
For table and data schema it’s more a case of incremental alignment, than structural change.
Rest assured that Sentinel’s data backbone remains Azure Log Analytics. Neither are tables, custom logs, and KQL queries disappearing. But Microsoft is gradually harmonising schemas between Sentinel log tables, Defender Advanced Hunting, and unified incident entities. This may produce greater normalisation of entity mapping, reduced duplication across alert tables, and closer alignment between hunting queries and SIEM queries.
So, things may not be exactly as you expect. Pay close attention to what is happening and validate schema references during the transition.
Why is Microsoft doing this?
The move reflects what’s happening across the industry, with security vendors consolidating SIEM and XDR into unified SecOps platforms.
Effective threat detection is increasingly reliant on visibility of identity signals, endpoint telemetry, cloud workloads, email, network logs, and behavioural analytics.
Microsoft is aligning its security offerings to provide:
- One portal
- One incident queue
- Integrated correlation and
- Shared investigation workflows.
Strategically, it strengthens Microsoft’s position as a full-spectrum security provider, enabling organisations to utilise a single pane of glass for SecOps activities.
Licensing is still separate
One of the biggest misconceptions is that Sentinel is being folded into a new Defender licence. This is not the case:
- Sentinel’s (ingestion-based) licensing remains separate
- Defender licensing remains separate
- Portal consolidation does NOT mean licence consolidation.
However, some threat intelligence features are being folded into Defender so it’s worth reviewing licensing, especially for those with Microsoft E5/A5 subscriptions.
What you need to do to migrate Sentinel
While this isn’t an emergency migration, it would be foolish to do nothing – these are changes that need managing properly.
Recommended actions:
- Plan to transition in good time
- Check your licensing (especially if on a E5/A5 subscription)
- Review RBAC alignment between Azure and Defender
- Test incident grouping behaviour in the unified portal
- Validate custom KQL queries and workbooks
- Update documentation and runbooks.
Handled correctly, you can have a smooth transition.
Consider also, whether this is an opportunity to formally review your configuration and settings against best practice.
In short
Sentinel isn’t disappearing and Defender isn’t ‘taking over’ – Microsoft is unifying its security stack.
If you’re already invested in Microsoft security this is an evolution that will improve future operations. For others, it reflects both the SIEM market’s consolidation around broader security platforms and Microsoft’s commitment to remaining relevant to your SecOps needs.
Find out how Cloud Direct can help you optimise Defender and Sentinel with a security assessment. Request a call with me through the form below.
