The move from the Azure portal to the Microsoft Defender portal is one of the most significant transformations yet for Microsoft Sentinel SIEM. By July 1, 2026, every Sentinel environment will make this leap. But this isn’t just a new coat of paint—it’s a re-architecture of how Security Operations Centers (SOCs) detect, investigate, and respond to threats. For many teams, the shift will feel different, even surprising. But within those surprises lie opportunities to run leaner, smarter, and more resilient operations. Here are six insights that will help you prepare your SOC to not only manage the change but thrive in it.
The migration landscape: what's at stake
|
This comprehensive guide distills the six most impactful changes every SOC needs to understand before making the switch. The migration represents a fundamental paradigm shift in how security operations are conducted, moving from the familiar Azure portal environment to the Defender portal—delivering new capabilities such as enhanced correlation, streamlined workflows, and continued innovation.
The stakes are high. With this shift, SOC teams must prepare not just for new interfaces, but for entirely new ways of thinking about incident management, automation, and security operations. To thrive in this new experience, organizations must recognize this migration as an opportunity to modernize their security operations, while those that treat it as a simple interface change may find themselves struggling with unexpected disruptions. |
|
Truth #1: You will gain a more comprehensive view of incidents
The Defender correlation engine automatically groups related alerts into a single incident and merges existing incidents it deems to be sufficiently alike based on shared entities, attack patterns, and timing. This process is designed to reduce noise and provide a more context-rich view of an attack, greatly benefiting the SOC by transforming scattered, benign signals into a complete incident view.
|
More comprehensive incidents We observed up to an 80% drop in Sentinel incident counts for early adopters of the unified SOC. |
Fewer duplications When Defender XDR merges one incident into another, the original "source incident" is automatically closed, given a Redirected tag, and disappears from the main queue. |
A shorter incident queue Analysts will enjoy fewer singleton alerts with the enhanced correlation engine. |
Leveraging the new correlation engine in Defender allows customers to transform signals into stories. With more comprehensive incidents and fewer singleton alerts, customers can connect the dots across their environment.
How the correlation engine decides
The Defender correlation engine uses sophisticated algorithms to determine which incidents should be merged. It analyzes multiple factors simultaneously to make these decisions, creating a more comprehensive view of security events.
- Shared entities (users, devices, IP addresses)
- Attack patterns and techniques
- Temporal proximity of events
- Contextual relationships between alerts
- Threat intelligence correlations
This automated correlation is designed to mirror the thought process of an experienced analyst who would naturally connect related security events. The engine operates at scale and speed that human analysts cannot match, processing thousands of potential correlations simultaneously.
Truth #2: Automation will level up
Think of this migration as a chance to strengthen the foundation of your Security Orchestration, Automation, and Response (SOAR) strategy.
The new unified schema encourages automation that’s more resilient and future-proof. By keying off stable fields like AnalyticsRuleName and tags, SOC teams gain precision and durability in their workflows—ensuring automation continues to work as correlation logic evolves.
Some playbooks and automations built in the Azure portal will need adjustment. Fields like IncidentDescription and IncidentProvider behave differently now, and titles aren’t always stable identifiers.
Adapting your automation rules and playbooks:
|
The Description field is gone Customers will need to update automations, playbooks and integrations that rely on the SecurityIncident table. This table no longer populates the Description field, which impacts rules that use dynamic content from KQL queries to populate descriptions. |
IncidentProvider property removed Since all incidents in the unified portal are considered to come from XDR, this property is now obsolete. Automation rules that use a condition like "Incident Provider equals Microsoft Sentinel" will need to be updated or removed entirely. |
Incident titles are unstable The Defender correlation engine may change an incident's title when it merges alerts or other incidents. Instead, use Analytics rule name or tags. |
Fixing Automation: The Action Plan
|
Audit existing automation Conduct a comprehensive review of all automation rules, SOAR playbooks, and integration scripts that interact with Sentinel incidents. Document dependencies on deprecated fields and identify potential failure points. |
Update field references Modify your rules to use more stable identifiers. Replace references to IncidentDescription and IncidentProvider with fields like AnalyticsRuleName and tags for conditions, ensuring more reliable automation execution. |
|
Implement granular control Use Analytics rule name as the recommended method for ensuring an automation rule only targets incidents generated from a specific Sentinel rule, preserving granular control over your workflows. |
Test and validate Thoroughly test updated automation in a staging environment before deployment. Create test scenarios that simulate the new correlation behaviors to ensure automation responds appropriately to merged incidents. |
Teams must move away from dependencies on dynamic content and toward predictable data points that will remain consistent even as the correlation engine modifies incident properties.
Truth #3: The correlation engine is in charge
The Defender correlation engine acts like an intelligent filter—connecting the dots between alerts at machine speed. You can’t turn it off, but you can work with it.
Some creative SOCs are already finding ways to guide its behavior, like routing test incidents separately to prevent unwanted merges. While it may feel like giving up some manual control, the payoff is big: an analyst’s effort shifts from sorting noise to validating signals.
In short, analysts spend less time as traffic cops and more time acting as investigators.
Rapid response with less configuration
With Defender’s advanced correlation algorithms handling incident grouping automatically, your security teams can confidently dedicate their attention to strategic decision-making and rapid incident response, rather than manual rule configuration.
Truth #4: Some familiar tools stay behind, but new ones await
A few Sentinel features you’ve grown used to—like Incident Tasks and manually created incidents—don’t carry over. Alerts that aren’t tied to incidents won’t appear in the Defender portal either.
It’s a shift, yes. But one that nudges SOCs toward leaner workflows and built-in consistency. Instead of juggling multiple tracking models, analysts can focus on cases that Defender elevates as truly significant.
|
Incident tasks The built-in checklist and workflow management feature used to standardize analyst actions within an incident is unavailable in the Defender portal. Teams must adopt alternative methods such as Cases for ensuring consistent investigation procedures. |
Alerts without incidents Analytics rules configured only to generate alerts (with createIncident set to false) will still write to the SecurityAlerts table. However, while the Advanced hunting query editor doesn’t recognize the SecurityAlerts table schema, you can still use the table in queries and analytics rules. |
|
Manually created incidents While incidents created manually or programmatically in Sentinel do not sync to the Defender portal, they remain fully manageable through API, ensuring specific workflows are handled separately. You can ingest the relevant events as custom logs and then create analytics rules to generate incidents from that data. |
Similar incidents feature Analysts will have access to a more advanced and integrated correlation engine that automatically merges related incidents from all sources. This built-in engine proactively groups threats by identifying common entities and attack behaviors, presenting a single, comprehensive incident rather than requiring manual investigation of separate alerts. |
Truth #5: Permissions grow more sophisticated
Operating in the Defender portal introduces a dual permissions model: your Azure Role-Based Access Control (RBAC) roles still apply, but you’ll also need Microsoft Entra ID or Defender Unified RBAC for high-level tasks.
This layered model means more careful planning up front, but it also opens the door for clearer separation of duties across teams—making it easier to scale SOC operations securely.
|
Additive permission model After connecting to the Defender portal, your existing Azure RBAC permissions are still honored and allow you to work with the Microsoft Sentinel features you already have access to. The new permissions are for accessing the Defender portal itself and performing high-level onboarding actions. |
Dual permission requirements Analysts and engineers need either global Microsoft Entra ID roles or roles from the new Microsoft Defender XDR Unified RBAC model to access and operate within the Defender portal. |
Elevated setup requirements Key actions like onboarding a workspace for the first time or changing the primary workspace require either Global Administrator or Security Administrator roles in Microsoft Entra ID. |
Permission planning matrix
|
User type |
Required permissions |
Access capabilities |
|
SOC Analyst |
Defender XDR role + existing Sentinel RBAC |
Incident investigation, alert triage, basic response actions |
|
SOC Manager |
Security Reader/Operator + Defender XDR roles |
Full operational access, reporting, dashboard configuration |
|
Security Engineer |
Contributor + Defender XDR Administrator |
Rule creation, automation management, advanced configuration |
|
Initial Setup Admin |
Global Admin or Security Admin |
Workspace onboarding, primary workspace designation |
|
MSSP Technician |
B2B Guest + appropriate Defender roles |
Customer tenant access via guest invitation model |
Planning permission transitions requires mapping current access patterns to the new dual-model requirements. Organizations should audit existing permissions, identify gaps, and develop migration plans that ensure continued access while meeting the new portal requirements.
Truth #6: Primary vs. secondary workspace divide
Not all workspaces are equal in the new model. The primary workspace is the one fully integrated with Defender . It’s where cross-signal correlation happens, enabling unified incidents that combine alerts across Defender and Microsoft Sentinel for a truly comprehensive view of threats. This forces a big but valuable decision: which workspace will anchor your organization’s most critical signals? Choosing wisely ensures you unlock the full power of cross-signal correlation, giving your SOC a panoramic view of complex threats.
|
Primary workspace This is the only workspace with alerts that can be correlated with Defender alerts and included together in unified incidents. It receives the full benefit of cross-signal correlation and advanced threat detection capabilities. |
Secondary workspaces Secondary workspaces often exist for compliance, regulatory, or business unit separation reasons. While their alerts are not correlated with XDR or or other workspaces, this design keeps them logically and operationally isolated. |
Selecting your primary workspace is a strategic step that unlocks the full potential of our unified SIEM and XDR correlation capabilities, empowering you with deeper insights and stronger threat detection across your critical data sources. While secondary workspaces remain fully operational, consolidating workspaces strategically allows your organization to maximize the advanced correlation and proactive defense that define the core value of the unified platform. Thoughtful workspace consolidation, balanced with compliance and cost considerations, positions your organization to get the absolute best out of your security investments.
Turning migration into momentum
The Defender portal migration isn’t just a deadline to meet—it’s an opportunity to re-engineer how your SOC operates. By anticipating these six shifts, you can move past disruption and toward a strategic advantage: fewer distractions, stronger automation, richer incident context, and a unified XDR-driven defense posture.
The future SOC isn’t just managing alerts—it’s mastering context. And the Defender portal is your launchpad.
More Information
Transition Your Microsoft Sentinel Environment to the Defender Portal | Microsoft Learn
Frequently asked questions about the unified security operations platform | Microsoft Community Hub
Microsoft Sentinel in the Microsoft Defender portal | Microsoft Learn
Microsoft