Anatomy of the change

Co-authored with Lizet Pena, Caroline Mutua, Alvin Kua and Marco Sudahl

Incidents, alerts, correlation, and data—what actually changes with the new platform, and why it works in your favor.

When you open Microsoft Sentinel in Microsoft Defender for the first time, the shift feels immediate: investigations are cleaner, workflows are more connected, and analysts can move through incidents with far less context switching.

Instead of pivoting between multiple queues, disconnected investigations, or duplicated alerts, SOC teams gain:

• One unified incident queue
• One attack story
• One place to investigate and respond
• One connected experience across Microsoft security signals

But the biggest improvements happen behind the scenes. The move from the Azure portal to Defender brings together incident correlation, alert handling, automation, and data investigation in ways that help SOC teams reduce manual work, improve visibility, and accelerate response.

This post breaks down the core changes, what remains familiar, and the practical steps teams can take now to prepare.

What we will cover

In this post we’ll guide you through some changes as you begin using Defender:

• A more connected incident experience
• Alerts and schemas evolve for easier investigations
• Your underlying data architecture stays intact
• Content hub and existing investments continue to work

We’ll also cover:

• What these changes mean for different SOC roles
• Common misconceptions
• A practical “do this week” checklist
• For a complete overview of the new experience, visit the Microsoft Defender portal overview on Microsoft Learn.

A more connected incident experience

Incidents are the center of security operations. This is where many teams will immediately notice the benefits of Defender.

In Defender:

• Correlation is no longer done by “Fusion” and now is managed through Defender’s correlation engine, creating alerts once across Defender and Sentinel data
• Correlation is richer and more connected
• Related activity is grouped together more effectively
• Analysts investigate through an attack story instead of isolated alerts

The result is a more streamlined investigation flow where one campaign or attack chain can be represented as a single incident instead of several disconnected records that must be manually stitched together.

Analysts gain access to:

• Attack story visualization
• Related assets and evidence
• Investigation timelines
• Correlated activities
• Cross-domain context
• Integrated hunting experiences

For organizations using Sentinel data lake and graph capabilities, analysts can also better visualize attack propagation paths and understand how activity may spread across environments. This helps reduce investigation time while improving clarity and confidence during triage.

Incident management – side by side

What remains the same

• Incident properties (title, description, severity, MITRE ATT&CK enterprise framework, tactics and techniques mapping) are preserved. Incidents still aggregate alerts and entities as evidence. Manual incident creation from hunting queries is still supported. Alerts and incidents can still be created by API or Logic App.
• The Microsoft Sentinel Responder role is the minimum least privilege role required by a SOC analyst to manage incidents, cases, tasks, threat intelligence, and automation rules related to incident management. This role maps to the security Operator in URBAC (Unified RBAC).

Correlation becomes more connected

One of the most important evolutions is the move from Fusion correlation to the Defender correlation engine.

This shift helps:

• Reduce duplicate incidents
• Improve multi-stage attack correlation
• Consolidate related activity into richer investigations
• Reduce manual merging work for analysts

The goal is simple: give analysts fewer, higher-quality incidents with more context attached.

Existing analytics rules continue to work, while newer custom detection experiences continue to evolve alongside them.

Microsoft Security alert rules are no longer displayed. With Sentinel in the Azure portal, security alerts are individual detections generated when Sentinel or integrated Microsoft security services identify suspicious or malicious activity in your environment. When Defender products are connected to Sentinel in the Azure Portal, their alerts flow into Sentinel as security alerts. These alerts are produced by Microsoft managed detection logic and surfaced in Sentinel for unified triage. After enabling Sentinel in Defender, analytic rules do not trigger alerts. These security alerts can be seen and queried on the SecurityAlert table; the analytic rules that previously triggered the security alerts in the Azure portal won’t be visible in Defender.

The custom detection rules blade in Defender displays both analytics rules and custom detections in a single view.

Why this lands well: One correlation engine instead of two means fewer duplicate incidents, fewer manual merges, and an investigation surface (attack story + blast radius) that’s richer than the legacy investigation graph it replaces.

Considerations for incidents and correlation

• Verify that any SOC automation closing or updating incidents using the Sentinel API is redirected to the Microsoft Graph security API.
• Incident IDs, AlertIDs and URLs will change (Defender uses its own identifiers).
• Incident names are auto generated by the Defender correlation engine and may differ from Sentinel analytics rule names. Update triage routing or SLA workflows that rely on the name of the incident. Customers can apply correlation exclusions at the analytic rule level or at the tenant level which will not affect the incident title and will then not merge alerts.
• Review any workflow that depends on Fusion-generated incidents, since Fusion is replaced by Defender correlation.
• In Defender, teams can use tags, saved queries, and custom hunting tables to capture and organize investigation context after a hunting exercise, providing flexible ways to carry forward important findings.

Alerts and schemas evolve for easier investigation

As Sentinel continues to evolve within Defender, incident management becomes more streamlined, connected, and cost-efficient. Instead of relying on separate “Microsoft security alerts” analytics rules to generate incidents from Defender workloads including endpoint, identity and cloud applications now are automatically correlated by the Defender engine into a unified incident queue.

This new approach helps eliminate duplicate incidents and gives security teams a cleaner, more consolidated investigation experience by bringing related alerts together into a single incident. It also enables organizations to modernize their operations by shifting from alert-level automation to incident-centric workflows, while taking advantage of Defender-native automation capabilities.

Beyond operational simplicity, this model can also help optimize costs. Since alert data is available without requiring additional log analytics ingestion, organizations can be more selective about ingesting raw logs and focus instead on scenarios where deeper investigations, long-term retention, or compliance requirements make it necessary.

Key transition actions

To transition effectively organizations should first retire legacy “Microsoft incident creation rules” analytics rules and rely on the individual Defender connectors for alert ingestion. Automation strategies should then be reviewed and adjusted, as incident handling shifts from multiple alert-driven records to a single, correlated incident model—often requiring incident-level workflows.

The integration also introduces bi-directional incident synchronization between Sentinel and Defender, enabling consistent state management across both environments, although the operational focus should move to Defender. Additionally, the new alert schema separates alert metadata and evidence. Organizations are encouraged to adopt the AlertInfo and AlertEvidence tables in place of the legacy SecurityAlert schema (supported in Advance Hunting) to support richer investigation scenarios.

Field-level differences – alert metadata

 

The key shift here is naming normalization standardized across Defender signals.

Field-level differences – entity/evidence modeling

 

The key shift here is denormalized JSON pivoting to strongly typed columns for easier joins, filters, and aggregations.

Querying differences – before and after

Azure (classic):

SecurityAlert | extend Entities = parse_json(Entities) | mv -expand Entities | where Entities.Type == "account"

Defender (recommended):

AlertInfo | join AlertEvidence on AlertId | where EntityType == "Account"

By leveraging the unified Microsoft Defender connector, your SOC gains efficiency (no double handling of the same threat), clarity (one incident is just one campaign or attack chain), and potential cost savings.

Why this lands well: The new schema isn’t a migration tax, it’s a query model that’s easier to write against, easier to teach new analysts, and avoids the JSON parsing Sentinel detection engineers have previously managed.

Your underlying data architecture stays intact

In this process, you can be assured that your log analytics workspace, retention settings, data export, and governance controls all carry forward.

 

Note on data lake availability: Microsoft Sentinel data lake is not yet available in every Azure region. Check current region coverage on Microsoft Learn before planning onboarding: Geographical availability and data residency in Microsoft Sentinel. Your data lake is provisioned in the same region as your primary Sentinel workspace.

Content hub and existing investments continue to work

Content Hub remains the mechanism for discovering and deploying solution packages (connectors, analytics rules, workbooks, playbooks) for Sentinel. Over 450+ solution templates from Microsoft, partners, and community contributors are available in the Sentinel solutions catalog.

Transition considerations

• Content hub is fully available in Defender. There is no need to switch back to the Azure portal for content management.
• Repositories (CI/CD for Sentinel content) and Community continue to function in Defender.
• No changes to content update mechanisms. Solutions continue to receive updates through Content Hub as before.

What this means for each persona

 

Clearing up common misconceptions

• “Fusion still runs in the background.”
  It does not. Fusion is replaced by the Defender correlation engine on the primary workspace.
• “My Sentinel data has to migrate.”
  It does not. The log analytics workspace is unchanged. Storage, retention, and per-table settings carry forward.
• “I lose my existing analytics rules.”
  Sentinel analytics rules continue to function and are visible in the unified custom detection rules blade alongside custom detections. The roadmap converges them only when custom detections reach full parity.
• “Incident IDs will stay the same, so my tickets won’t break.”
  Incident IDs and URLs change in Defender. Update any external ticketing or webhook integration.
• “My Content Hub solutions need to be re-installed.”
  They don’t. Content Hub is still available in Defender. Solutions, repositories, and community all continue to work.

Get started

• Designate your primary Sentinel workspace and document the decision. Only the primary receives Defender incidents/alerts and gets XDR correlation.
• Inventory automations that update or close incidents through the Sentinel API. Mark them for re-pointing to the Microsoft Graph security API.
• Identify external systems keyed on incident IDs, URLs, or incident names. Flag for update.
• Pilot one new hunting query using AlertInfo + AlertEvidence to build team familiarity with the new schema.
• Confirm Content Hub solutions and repositories pipelines are visible and operational from Defender.
• If long-term retention is on your roadmap, confirm your primary workspace region is supported by the data lake before planning onboarding: Geographical availability and data residency.

Continue the series

All six parts of this series are published together. Each one stands alone—pick the angle that matters most to you or read them in order.

Part 1 – Beyond a portal move: The strategic shift to Defender

Why the transition matters at the architecture and program level—the executive framing, the deadline, and the analyst validation.

Part 3 – Detection and automation, reimagined

How analytics rules evolve into custom detections, the shift from alert-driven to incident-driven SOAR, and how hunting changes.

Part 4 – The governance shift: RBAC, URBAC, data Lake, and MSSP

The move from Azure RBAC to URBAC, the data lake operating model, and multi -tenant patterns.

Part 5 – Your readiness playbook: Adoption helper, costs, APIs, and the checklist

A practical plan: the Defender adoption helper, cost reality, API strategy, and the migration checklist.

Part 6 – The AI-first SOC: Copilot, UEBA, threat intelligence, and SOC optimization

The destination: how Security Copilot, UEBA, threat intelligence, and SOC optimization combine into a fundamentally different operating model.