Detection and automation, reimagined

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

How analytics rules, playbooks, workbooks, and hunting evolve in Defender—and why the new toolbelt makes detection engineering faster, automation richer, and hunting genuinely cross-platform.

If you build detections for a living, the move to Defender is one of the most meaningful shifts to your workflow in years—and for most teams, it’s a welcome one. Your existing analytics rules don’t disappear. Your playbooks don’t need to be rewritten. Your workbooks continue to function exactly as they do today. What changes is the scope of what you can detect, automate, and investigate from a single experience.

That scope now includes endpoint, identity, email, cloud apps, and Sentinel data together—enabling analysts to query across data sources in a single KQL experience, investigate from one incident queue, and automate with richer response actions. Custom detections introduce near-real-time detections with native Defender response actions. Security Copilot can help generate playbooks from natural language prompts. Advanced hunting now spans Defender and Sentinel data together, dramatically expanding what hunters can pivot across. Conduct end-to-end threat hunting with hunts. The result isn’t a smaller toolset or a forced replacement of what exists today. It’s an expanded one.

In this post, we’ll walk through the major shifts across detection engineering, automation, hunting, workbooks, and case management—including where existing investments carry forward unchanged, where the experience improves, and how to choose the right tool for the right scenario moving forward.

What this post covers

• Detection: analytics rules and custom detections converge into a shared experience
• Automation : playbooks are enhanced
• Workbooks: same canvas, richer investigative context
• Hunting: from Sentinel-focused hunting to cross-platform advanced hunting
• Case management: investigations finally get a durable workspace
• A quick note on watchlists
• Persona implications, common misconceptions, and a practical “do this week” checklist

Detection: Analytics rules and custom detections converge

Detection engineering is more flexible in Defender.

Teams still have access to familiar scheduled analytics rules and SIEM-style detections and now gain access to custom detections—a faster, more modern detection model designed for Defender telemetry and near-real-time response.

Sentinel rule types:

• Scheduled query rules – traditional KQL-based detections that run on a schedule
• Microsoft security rules – Microsoft-managed detections for Defender services and other Microsoft security products
• Anomaly rules – ML-driven behavioral detections
• Threat intelligence rules – detections powered by indicator matching
• Custom detections – modern detections powered by advanced hunting queries with near-real-time execution and native response actions

One of the biggest architectural shifts is the retirement of the Fusion analytic rule in favor of the Defender correlation engine. Instead of managing Fusion separately, analysts now benefit from correlation directly within Defender incident processing.

At the same time, the rules experience becomes simpler. Defender surfaces both Sentinel analytics rules and custom detections together in a single rules view.

What changes after onboarding to Defender

Several important operational changes happen automatically:

• Fusion is replaced by the Defender correlation engine
• Microsoft incident creation rules tied to Defender products are no longer surfaced separately
• Related alerts are consolidated into richer incidents within Defender
• Analytics rules and custom detections appear together in one experience

This also changes how organizations should think about detections moving forward.

Historically, Microsoft security alerts often flowed into Sentinel as individual security alerts generated by Microsoft products. In Defender, those alerts are correlated natively into a single incident queue, reducing duplicate incidents and simplifying investigations.

Why custom detections matter long term

Custom detections unlock new capabilities for detection engineering in Defender. They provide:

• Faster, near-real-time streaming detections
• Built-in response actions
• Cross-platform visibility
• Cost efficiencies for Defender telemetry
• A streamlined authoring experience integrated with advanced hunting

As feature parity continues to improve, most organizations building new detections on Defender telemetry will likely standardize on custom detections moving forward.

That doesn’t mean analytics rules disappear. They remain critical for:

• Cross-vendor SIEM use cases
• Firewall and network telemetry
• OT environments
• SaaS and custom log scenarios
• Broad correlation across non-Defender sources

The outcome is practical flexibility: your existing analytics rules and detections keep running in one rule interface that spans both worlds, so you can reach for the best engine for the data source and use case you’re solving.

What changes after Defender onboarding

 

Transition considerations

• Once Fusion is automatically disabled, verify that XDR correlation is generating multi-stage incidents in Defender with alerts from several sources, and stop relying on Fusion-specific customizations or automation tied to Fusion incidents.
• The XDR Correlation engine is not limited to Defender and Sentinel data sources.
• Strengthen entity mappings (accounts, hosts, IPs) on your analytics rules to maximize correlation quality, and monitor post-transition incident volume for fewer, but richer, consolidated incidents.

When Defender connector is enabled in Sentinel (Azure portal), connector automatically replaces those rules and providing two-way integration. You can still use an automation rule with the product name that generated the alert.

Why this lands well: Two detection models, one rules view. You don’t pick a side, instead you reach for the right tool: custom detections for Defender-native signals with near-real-time response and analytics rules for cross-vendor SIEM use cases. The convergence is on the roadmap, not a forced cutover.

Custom detections versus analytics rules

 

When custom detections fit best

• Your detection is based on Defender signals (endpoint/identity/email/cloud)
• You want faster detections and built-in XDR response actions
• You operate primarily in Defender
• Recommended as the default detection across Defender and Sentinel signals

When Sentinel analytics rules fit best

• You need non-Defender data (firewalls, SaaS, OT, custom logs)
• You need cross-source/cross-vendor KQL correlation in SIEM
• You’re building classic SIEM use cases

Automation and SOAR: playbooks enhanced, not retired

In Azure Sentinel (legacy portal), playbooks are logic apps that automate response actions, typically triggered by automation rules on incident or alert creation. This provides robust SOAR (Security Orchestration, Automation, and Response) capabilities but requires analysts to manage playbook triggers and execution from the Azure interface.

Defender changes: In Defender, playbook usage is enhanced and slightly redefined ( Generate playbooks using AI in Microsoft Sentinel | Microsoft Learn).

Comparison

 

Key transition considerations

• Review and adjust automation rules
• Leverage built-in actions
• Playbook testing
• Slight delay in automation (up to ~5-10 minutes between incident creation and automation rule execution)
• Dual automation strategy

Summary

All existing playbooks continue to run on Azure logic apps infrastructure (the playbook definition itself is not migrated). Defender surfaces these playbooks and allows triggering them, but you’ll still design and edit playbooks in the Azure portal’s logic apps designer—the available playbook triggers and actions are unchanged. No rewrites are required, but you should adapt how and when playbook triggers and actions are invoked to align with the new unified incident model. Playbooks remain a core part of your SOAR toolkit, and are now enhanced by on-demand usage and upcoming AI integration.

Why this lands well: Zero playbook migration. Your SOAR investment carries forward exactly as it is, and the new built-in Defender response actions (device isolation, user containment, attack disruption) cover the most common containment scenarios out of the box, so your custom playbooks can focus on the orchestration and cross-tool workflows that truly need them.

Workbooks: same canvas, better surroundings

Workbooks provide interactive visualizations and dashboards for investigation, monitoring, and reporting across Microsoft Sentinel data. With the move to Defender, workbooks remain a core analysis asset, while the surrounding experience improves through tighter integration with unified incidents, hunting, and cross‑product visibility.

Comparison

 

Key considerations

• No migration is required
• Azure remains the source of truth
• Stronger investigative flow
• Not replaced by Copilot
• Consistent access model
• Optional broader sharing

Best practices

• Standardize key workbooks
• Design for pivoting
• Reuse, don’t duplicate
• Pair with hunting
• Review periodically

Why this lands well: Zero workbook migration. Every dashboard, every visualization, every reporting layer you’ve built keeps working and gets better surroundings: discoverable from incidents, paired with hunting, contextualized by unified entities.

Hunting: from focused Sentinel to cross-platform advanced hunting

Hunting and advanced hunting both support threat detection and investigation, but they differ in scope and use. Hunting in Microsoft Sentinel focuses on Sentinel logs and is best for hypothesis-driven KQL investigations within Sentinel. Retention of the data used for hunting follows Sentinel log settings. Advanced hunting in Microsoft Defender provides a unified experience across Sentinel and Defender XDR data, enabling cross-platform queries, real-time remediation, and automation. Defender data is typically retained for 30 days, with longer retention available through Sentinel data lake. In short, hunting is best for focused Sentinel investigations, while advanced hunting is built for broader, cross-platform analysis and response.

What changes

• Sentinel queries and functions become view-only in Defender (can execute but not edit directly)
• Editing requires returning to Azure portal during transition period
• Major advantage: Advanced hunting in Defender allows querying across both Sentinel tables and Defender XDR tables in a single query
• Query history shows all queries run across both data sources

Advanced hunting benefits

• Cross-platform hunting: Single KQL query spans endpoint (Defender for Endpoint), email (Defender for Office 365), identity (Defender for Identity), and Sentinel data sources
• Unified schema: All tables accessible in one query editor with schema browser
• Saved Sentinel queries available: Your existing hunting queries remain accessible
• Custom detections: Convert hunting queries into detection rules (Defender XDR custom detections for Defender tables; Sentinel analytics rules for Sentinel tables)

Comparison

 

Why this lands well: One KQL query, four detection surfaces. Threat hunters now span endpoint, identity, email, cloud apps, and Sentinel in a single query—with real-time response actions one click away. Saved Sentinel queries carry forward; the canvas just got bigger.

From incident-centric to case-centric investigation

The detection, automation, and hunting shifts we just walked through all converge on the same question: once the SOC has a richer set of incidents, cross-platform hunts, and automated containment running, where does the longer-form investigative work actually live? In the Azure portal, the incident has always been the top of the work stack—there was nowhere above it to organize a multi-week campaign investigation, a proactive hunt, or an IoC chase across many incidents. Teams reached for OneNote pages, email threads, and external tickets. Defender closes that gap with a new primitive: the case.

Case management in Defender is a native, security-focused workspace for SecOps work that spans multiple incidents—including multi-incident campaigns, threat hunting, IoC and threat-actor tracking, and detection-tuning backlogs.

Cases are only available in Defender and require a Sentinel workspace connection. See Manage security operations cases natively in Microsoft Defender.

Comparison

Service limits

• 100,000 cases per tenant
• 500 GB of attachments per tenant
• 100 linked incidents per case
• See Microsoft Sentinel service limits for the full set of platform limits

Transition considerations

• Develop guidelines for when analysts should create a case (e.g., multi-incident campaigns or proactive threat hunts)
• If you currently use external ticketing systems (ServiceNow, JIRA) for multi-incident tracking, determine how cases complement or integrate with them

Why this lands well: Investigations finally have a home above the incident. Multi-incident campaigns, hunts, and IoC chases stop living in OneNote pages and external tickets, and start living next to the security data—with their own status, tasks, comments, and audit trail. Nothing about your existing incident workflow changes; cases simply give you a durable layer for the work that used to fall between the cracks.

A quick note on watchlists

Not everything in this transition is changing—and that’s a feature, not an oversight. Watchlists are a good example: a primitive that was already doing its job well, and that simply carries forward unchanged into the unified experience.

No changes. Watchlists remain an Azure Sentinel feature for semi-static, custom lookup tables.

 

Transition considerations

• Watchlists can be accessed under the configuration section as well as through watchlist queries alongside Defender XDR data
• You can upload a watchlist created from a CSV or other source

Why this lands well: Your existing watchlists keep working, your existing KQL keeps working, and the surrounding context just got richer—the same lookup table now joins against Defender entities and incidents alongside Sentinel data. Zero migration, broader reach.

What this means for each persona

Clearing up common misconceptions

• “My analytics rules will be deleted.”
  No analytics rules deleted. Sentinel analytics rules continue to function and appear in the unified custom detection rules blade alongside custom detections.
• “I have to rewrite my playbooks.”
  No rewrite required. All existing playbooks continue to run on Azure Logic Apps. Defender surfaces and triggers them; authoring still happens in Azure.
• “Custom detections fully replace analytics rules today.”
  Not yet. Microsoft is converging them only when custom detections reach full parity.
• “My workbooks need to be re-created in Defender.”
  No need. Same workbooks, same storage, no duplication. Authoring stays in Azure; consumption improves in Defender.
• “Fusion is still running quietly.”
  It is not. Fusion is replaced by the Defender correlation engine. Verify XDR correlation is generating multi-stage incidents and retire any Fusion-tied customizations.
• “Advanced Hunting and Hunting are the same thing.”
  They’re complementary. Hunting is focused on Sentinel while advanced hunting spans Sentinel + Defender XDR with real-time response actions.

Do this week

• Inventory analytics rules by source: Rules targeting Defender data (candidates for custom detections), rules targeting non-Defender (stay as analytics rules), rules targeting firewalls/SaaS without native detections (Sentinel).
• Confirm strong entity mappings (accounts, hosts, IPs) on your active analytics rules—these drive XDR correlation quality.
• Pilot one custom detection on Defender data with a built-in response action (e.g., device isolation) end to end.
• Review your automation rules: which key on incident name, which key on analytic rule name, which trigger playbooks. Plan the dual-automation period.
• Validate that all existing playbooks remain triggerable from the unified incident queue.
• Run one advanced hunting query that joins Defender XDR tables with Sentinel tables—a small “aha” for the team.
• If you use Security Copilot, enable the embedded experience and the Microsoft Sentinel integration to surface incident summaries and guided response.

Continue the series

All six parts of this series publish close 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 2 – Anatomy of the change: Incidents, alerts, correlation, and data

The component-level mechanics: how the XDR correlation engine replaces Fusion, why incidents are no longer alert-centric, and what changes (and doesn’t) in your data architecture.

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.