Forum Discussion
MicrosoftObserved Automation Discrepancies
Hi Team ... I want to know the logic behind the Defender XDR Automation Engine . How it works ?
I have observed Defender XDR Automation Engine Behavior contrary to expectations of identical incident and automation handling in both environments, discrepancies were observed. Specifically, incidents with high-severity alerts were automatically closed by Defender XDR's automation engine before reaching their SOC for review, raising concerns among clients and colleagues. Automation rules are clearly logged in the activity log, whereas actions performed by Microsoft Defender XDR are less transparent .
A high-severity alert related to a phishing incident was closed by Defender XDR's automation, resulting in the associated incident being closed and removed from SOC review. Wherein the automation was not triggered by our own rules, but by Microsoft's Defender XDR, and sought clarification on the underlying logic.
1 Reply
There have been discussions around high-severity incidents being automatically closed by Microsoft Defender XDR without custom automation rules triggering the action. It is important to clarify how this behavior actually works.
Microsoft Defender XDR does not rely solely on user-defined automation rules. It operates on a multi-layered automated investigation framework driven by:
- Automated Investigation and Response (AIR)
- Cross-domain signal correlation (Endpoint, Identity, Email, Cloud Apps)
- Machine learning–based confidence scoring
- Threat intelligence enrichment
- Entity-level remediation validation
When a high-severity alert is generated (for example, phishing), the system initiates an automated investigation workflow. During this process, Defender evaluates:
- Whether the malicious artifact was successfully remediated (e.g., email quarantined, URL blocked).
- Whether any user account shows compromise indicators.
- Whether lateral movement or follow-up activity occurred.
- Whether affected entities remain in a risky state.
If the investigation determines with high confidence that:
- The threat has been fully contained,
- No impacted entities remain exposed,
- No further suspicious signals are correlated,
the Automated Investigation engine can mark the alert as resolved and automatically close the associated incident.
This behavior is not triggered by custom automation rules, but by built-in AIR logic. Therefore:
- Custom automation rules appear explicitly in activity logs.
- AIR-driven closures are reflected as investigation actions rather than rule-based automation.
This can create the perception of reduced transparency, especially in SOC models where high-severity incidents are expected to require mandatory analyst review.
It is also important to understand that incident severity does not override AIR decision logic. Severity reflects potential impact at detection time, whereas automated closure is based on post-investigation confidence and remediation validation.
Differences between environments — even when configurations appear identical — may result from:
- Variations in telemetry depth
- Licensing differences (Plan 1 vs Plan 2 capabilities)
- Differences in remediation permissions
- Entity behavior context
- Signal correlation variance
Defender XDR prioritizes containment confidence over manual workflow routing. From the platform’s perspective, a fully remediated, non-impacting threat does not require continued incident lifecycle status.
In SOC-driven environments, governance expectations may differ from Microsoft’s automation philosophy, and tuning response settings or limiting automated remediation permissions may be required to align operational models.
Understanding this distinction is critical when designing SOC workflows around Defender XDR.
