Skip to content

Sentinel and Microsoft Defender Integration

Atlanta, USA

GitHub Cloud2BR OSS - Learning Hub

Last updated: 2026-07-27

References

Back to the documentation hub

Microsoft Defender extended detection and response (XDR) provides specialized detections and response across Microsoft security workloads. Sentinel extends that capability with third-party data, custom analytics, long-term data strategy, and security orchestration, automation, and response (SOAR). Integrate them from a defined incident and telemetry architecture, not simply because both products are available.

Decide what belongs where

Need Preferred starting point
Native endpoint, email, identity, or cloud-app investigation Defender XDR
Cross-source correlation with firewall, custom app, or multicloud logs Sentinel
Native Defender containment action Defender XDR or workload portal
Multi-system orchestration, information technology service management (ITSM), or custom API response Sentinel playbook
Long-term query or compliance requirement Sentinel workspace design

Prevent duplicate operations

Choose the primary incident queue for every use case and document what synchronizes, who assigns incidents, which portal responders use, and how status changes are reconciled. Do not create a Sentinel analytic rule that merely repeats a native Defender detection unless it adds a distinct cross-source condition.

Configure the Defender integration

  1. Confirm the tenant, licensing, role assignments, and supported workloads for the Microsoft Defender extended detection and response (XDR) integration.
  2. In Microsoft Sentinel, open the Microsoft Defender XDR integration in the relevant data connector or content-management experience.
  3. Connect using an account with the required Sentinel and Defender permissions, then select the supported incident and alert synchronization options.
  4. Define the primary incident queue and document which team owns assignment, status changes, comments, containment, and closure.
  5. Enable one approved Defender workload or pilot scope, then confirm entities, severity, and incident correlation arrive only once.
  6. Disable or tune duplicate Sentinel analytics and automation rules before expanding the integration to production workloads.

Validation pattern

  1. Connect the supported Defender integration and confirm current prerequisites.
  2. Generate an approved test alert from the underlying Defender workload.
  3. Verify the alert and incident arrive once in the selected primary queue with expected entities and severity.
  4. Verify ownership, status, comments, and automation do not create loops.
  5. Test native containment and any Sentinel playbook separately with approvals.

Business example

Defender for Endpoint detects a malicious process, while Sentinel adds firewall and custom-application logs that show the device reached a sensitive backend. The security operations center (SOC) works the incident in the agreed primary queue, uses Defender to isolate the device, and uses a Sentinel playbook to create a network review ticket. The team disables a redundant Sentinel rule that had created a second incident from the same endpoint alert.