Skip to main content

Security alerts, workflow automation and the Sentinel/XDR integration

Microsoft documentedDefender for Cloud · Source checked 2026-10-22 · Not yet verified in tenant · Sources: [1][2][3][4][5][6][7][8][9][10][11][12][13][14][15][16][17][18][19][20][21][22][23]

What it is​

A Defender for Cloud security alert is the output of a workload protection plan. Enable Defender for Servers, Storage, Key Vault, Containers or any other plan from the workload plans article and that plan starts producing detections for its resource type. Each alert names the affected resource, explains what was seen and gives remediation steps. Alerts live in the Azure portal for 90 days, even if the resource was deleted in the meantime.

An alert on its own is only half the story. Defender for Cloud correlates related alerts into security incidents, and since the Defender XDR integration went GA those same alerts and incidents also land in the Defender portal, where they correlate with MDE, MDI and MDO signals. If Sentinel is in the picture there is a third copy in the SecurityAlert table. This article is about the plumbing between those three places and the four knobs that control it: email notifications, suppression rules, workflow automation and continuous export.

It is not about tuning individual detections. The alert catalogue is in the alerts reference, split into 17 pages by resource type: Windows machines, Linux machines, DNS, Azure VM extensions, App Service, Containers, SQL Database and Synapse, open-source relational databases, Resource Manager, Storage, Cosmos DB, Azure network layer, Key Vault, DDoS Protection, Defender for APIs, AI workloads and deprecated alerts. Learn notes that some newer MDE and Defender Threat Intelligence alerts may show up before they are documented. For the general Defender for Cloud model see the overview.

Licensing and prerequisites​

  • Alerts need at least one Defender for Cloud workload plan on the subscription. Foundational CSPM alone produces recommendations, not alerts. Which alerts you get depends on which plans are on.
  • Email notifications: Security Admin, Subscription Owner or Contributor to configure. No extra cost.
  • Suppression rules: Security Admin or Owner to create and delete, Security Reader or Reader to view. Management group scope needs Azure Policy.
  • Workflow automation: Security Admin or Owner on the resource group, write permission on the target resource, Logic App Contributor to create or edit the logic app, Logic App Operator to run it. Consumption logic apps only. Logic Apps are billed separately.
  • Continuous export: Security Admin or Owner on the resource group plus write on the target. Event Hubs needs write on the Event Hubs policy. Log Analytics needs Microsoft.OperationsManagement/solutions/read if the SecurityCenterFree solution already exists on the workspace, otherwise Microsoft.OperationsManagement/solutions/action. Azure Policy deployment needs policy assignment rights.
  • Sentinel connector: read and write on the Sentinel workspace, Contributor or Owner on each subscription to connect it, Contributor or Security Admin for bi-directional sync, the SecurityInsights resource provider registered on every subscription, and at least one Defender plan per subscription. Sentinel bills on ingested volume.
  • Defender XDR integration: nothing to enable. Permissions are tenant-wide through Defender XDR Unified RBAC with the Defender for Cloud scope, or Global Administrator or Security Administrator without Unified RBAC.
  • Sample alerts: Subscription Contributor.

How it works​

Detection and severity​

Learn names four detection sources: behavioural analytics, per-deployment anomaly baselines, Microsoft threat intelligence, and continuous tuning from customer feedback. Severity encodes two confidences: how sure the detection is, and how malicious the intent is.

SeverityMeaningLearn example
HighHigh probability the resource is compromised. Investigate now.Mimikatz execution
MediumSuspicious, might be compromise. Medium confidence in the finding, medium to high in intent.Sign-in from an unusual location
LowPossibly benign, or a blocked attack. Low confidence in intent.Log clearing
InformationalNot actionable alone. Only useful inside an incident.

Most alerts carry a MITRE ATT&CK tactic, based on ATT&CK v9: PreAttack, Initial Access, Persistence, Privilege Escalation, Defense Evasion, Credential Access, Discovery, Lateral Movement, Execution, Collection, Command and Control, Exfiltration, Impact. The tactic shows as the kill chain intent in the alert pane and as Tactics in the SecurityAlert table.

Lifecycle​

An alert starts Active. The CLI and REST surface four state operations: activate, inprogress, resolve and dismiss. The portal exposes a Change status dropdown that works on one alert or a filtered bulk selection. Dismissed alerts leave the main list but stay queryable with a status filter. A suppression rule is just an automatic dismiss for alerts that match its conditions; deleting the rule does not re-open what it already dismissed. Learn does not document an SLA for status propagation inside Defender for Cloud. Sync to Sentinel and Defender XDR takes a few minutes.

Incidents are a separate object type in the same list. Filter by alert name Security incident detected on multiple resources to see only incidents. The same alert can be inside an incident and also appear standalone.

Three destinations​

Three paths carry an alert out of the Azure portal:

  1. Defender XDR: automatic. Every non-informational alert, including AWS and GCP alerts and alerts from internal and external providers, appears in the Defender portal alert queue with a cloud resource asset tagged Azure, Amazon or Google Cloud. Incidents are integrated too, with cloud resources on the attack story and Assets tab, and each VM gets an entity page. Status changes on Defender for Cloud alerts sync both ways. Status changes on MDE alerts raised on cloud resources do not sync in either direction; those alerts exist in both products but are owned by MDE. Advanced hunting gets CloudAuditEvents for ARM and KubeAudit control plane activity, CloudProcessEvents for process-level activity, and CloudStorageAggregatedEvents for storage access patterns. Defender for Cloud alerts and incidents also ride the Defender XDR public API, which Learn names as the simplest single export path for third-party tools. See XDR incidents and alerts.
  2. Sentinel connector: pulls alerts into the SecurityAlert table with ProductName == "Azure Security Center". Two connector flavours exist. Subscription-based (Legacy) is enabled per subscription. Tenant-based (Preview) collects from every subscription in the tenant and is built to line up with the Defender XDR incident integration. One-way status sync from Defender for Cloud to Sentinel is the default. Bi-directional sync adds the return trip: closing a Sentinel incident that contains the alert closes the original. Note the asymmetry Learn calls out: changing an alert's status never changes the status of a Sentinel incident that contains it. Cross-tenant subscriptions cannot be synced, even with Lighthouse. If Sentinel is onboarded to the Defender portal the tenant-based connector is not listed there because alerts already arrive through Defender XDR, but you should still install the Defender for Cloud solution from Content Hub for the content. See Sentinel data connectors.
  3. Continuous export: a Defender for Cloud automation that writes alerts and recommendations to a Log Analytics workspace or an Event Hub, in the same or another subscription or tenant. Streaming sends on every state change. Snapshots send the full current state once a week per subscription with IsSnapshot set. Log Analytics creates SecurityAlert and SecurityRecommendation tables. Records above 32 KB are dropped with a Data limit has been exceeded alert. Event Hub output is JSON and is the route to QRadar, Splunk, ArcSight, Sumo Logic, syslog and the rest. Learn calls continuous export the preferred export method. Tenant-wide export is an Azure Policy assignment at the root management group.

Workflow automation​

Workflow automation is the same Microsoft.Security/automations resource as continuous export, with a Logic App action instead of a workspace or Event Hub action. The scope is the subscription or a resource group under it. Sources are event types; rule sets filter them. All rules inside a rule set must match, and multiple rule sets are ORed.

Inside the logic app there are three Defender for Cloud triggers: When a Defender for Cloud Alert is created or triggered, which can be filtered by severity; When a Microsoft Defender for Cloud recommendation is created or triggered; and When a Defender for Cloud regulatory compliance assessment is created or triggered. The older trigger When a response to a Microsoft Defender for Cloud alert is triggered is not supported by workflow automation. A recommendation trigger breaks silently when that recommendation is deprecated or replaced; watch the release notes. The Add workflow automation dropdown only lists logic apps that already contain one of the supported connectors, so build the logic app first. You can also run a logic app by hand from any alert or recommendation with Trigger logic app. Raw event schemas for the generic HTTP connector are at https://aka.ms/ASCAutomationSchemas.

Configure​

Email notifications

  1. Defender for Cloud > Environment settings > subscription > Email notifications.
  2. Pick roles, type addresses (comma separated), or both. Default is subscription owners on High alerts and attack paths.
  3. Set the minimum alert severity and the minimum attack path risk level. Save.

Per address the service caps at four High, two Medium or one Low alert email a day, and one Critical attack path email per 30 minutes down to one Low per three hours. It is a nudge, not a feed.

Email notification settings on a subscription: roles, addresses, alert severity threshold and attack path risk threshold. Source: Microsoft Learn, CC BY 4.0.
Email notification settings on a subscription: roles, addresses, alert severity threshold and attack path risk threshold. Source: Microsoft Learn, CC BY 4.0. · captured 2026-10-22

Suppression rule

  1. Defender for Cloud > Security alerts > Suppression rules > Create new suppression rule. Or open an alert, Take action > Suppress similar alerts > Create suppression rule, which pre-fills the alert type.
  2. Scope: subscription(s). Alert types: All or Custom. Add entity conditions to narrow to specific resources or values.
  3. Name (2 to 50 characters, letters, numbers, dash, underscore), reason, optional comment, expiry (Custom date or None). Simulate to see what it would have dismissed. Apply.

A rule only lists alert types that have fired at least once in the scope. Management groups need Azure Policy.

Creating a rule from an alert's Take action tab. Source: Microsoft Learn, CC BY 4.0.
Creating a rule from an alert's Take action tab. Source: Microsoft Learn, CC BY 4.0. · captured 2026-10-22

Triage an alert

Security alerts > pick an alert. The side pane gives severity, status, time, description, affected resource and MITRE intent. View full details opens the Alert details tab (IPs, files, processes) and the Take action tab with Inspect resource context, Mitigate the threat, Prevent future attacks, Trigger automated response and Suppress similar alerts. When done, Change status > Dismissed, and answer Was this useful. Bulk: filter, tick, Change status.

Take action tab on an alert. Source: Microsoft Learn, CC BY 4.0.
Take action tab on an alert. Source: Microsoft Learn, CC BY 4.0. · captured 2026-10-22

Workflow automation

  1. Build the consumption logic app first: Logic Apps > Add > Review + create. Open the designer and start from one of the three Defender for Cloud triggers. Give the logic app the connections it needs (Teams, Outlook, ServiceNow and so on need their own credentials).
  2. Defender for Cloud > Workflow automation > Add workflow automation.
  3. Name, description, subscription, resource group. Trigger conditions: data type (alert, recommendation, regulatory compliance), then filters such as alert name contains SQL or severity.
  4. Actions > Refresh > pick the logic app. Create.
Add workflow automation blade: trigger conditions and the logic app picker. Source: Microsoft Learn, CC BY 4.0.
Add workflow automation blade: trigger conditions and the logic app picker. Source: Microsoft Learn, CC BY 4.0. · captured 2026-10-22
Trigger logic app by hand from a recommendation. The same button exists on alerts. Source: Microsoft Learn, CC BY 4.0.
Trigger logic app by hand from a recommendation. The same button exists on alerts. Source: Microsoft Learn, CC BY 4.0. · captured 2026-10-22

At scale, assign the DeployIfNotExist policies at a management group: Deploy Workflow Automation for Microsoft Defender for Cloud alerts f1525828-9a90-4fcf-be48-268cdd02361e, recommendations 73d6ab6c-2475-4850-afd6-43795f3492ef, regulatory compliance 509122b9-ddd9-47ba-a5f1-d0dac20be63c. Add a remediation task to cover existing subscriptions.

Continuous export

  1. Defender for Cloud > Environment settings > subscription > Continuous export.
  2. Pick the tab for Event Hub or Log Analytics workspace.
  3. Tick the data types. For alerts add a severity filter if you want. Set Include security findings to Yes if you want vulnerability sub-assessments under the five supported recommendations (SQL databases, SQL servers on machines, container registry images, machines, system updates).
  4. Export frequency: Streaming, Snapshots, or both.
  5. Export target: subscription, then the Event Hub namespace, hub and policy, or the workspace. Save.
Continuous export options: data types, frequency and target. Source: Microsoft Learn, CC BY 4.0.
Continuous export options: data types, frequency and target. Source: Microsoft Learn, CC BY 4.0. · captured 2026-10-22

Policy IDs for management group deployment: Event Hubs cdfcce10-4578-4ecd-9703-530938e4abcb, Log Analytics ffb6f416-7bd2-4488-8828-56585fef2be9.

Sentinel connector (Azure portal Sentinel)

  1. Sentinel > Content hub > install Microsoft Defender for Cloud (3.0.0 or later).
  2. Configuration > Data connectors > Tenant-based Microsoft Defender for Cloud (Preview) > Open connector page. Use Subscription-based (Legacy) only if you have a reason.
  3. Toggle Status on for each subscription, or tick several and Connect. Set Bi-directional sync to Enabled per subscription if you want Sentinel closes to flow back.
  4. Check the Microsoft Defender plans column. Blank means no plans and no alerts; Some enabled offers Enable all.
  5. Under Create incidents, Enabled turns on the built-in Microsoft Security analytics rule. Leave it off if Defender XDR incident integration is on, see below.
Defender for Cloud connector page in Sentinel: per-subscription status, bi-directional sync and plan coverage. Source: Microsoft Learn, CC BY 4.0.
Defender for Cloud connector page in Sentinel: per-subscription status, bi-directional sync and plan coverage. Source: Microsoft Learn, CC BY 4.0. · captured 2026-10-22

Defender XDR incident integration, no duplicates

If the Microsoft Defender XDR connector in Sentinel has incident integration on, Defender for Cloud incidents arrive through it. Learn's sequence: enable the tenant-based connector so the incidents carry alerts and entities, disconnect the subscription-based (Legacy) connector, and disable every Scheduled or Microsoft Security analytics rule that creates incidents from Defender for Cloud alerts. For alert types you do not want as incidents, close them on arrival with an automation rule or tune them in the Defender portal. With several workspaces in the Defender portal, correlated incidents stream to the primary workspace.

Sample alerts

Security alerts > Sample alerts > subscription > plans > Create sample alerts. They appear within minutes, reference simulated resources, and flow through email, automation, export and Sentinel like real ones. Use them to test the whole chain before a real incident does.

Sample alerts dialog: pick the subscription and the plans to simulate. Source: Microsoft Learn, CC BY 4.0.
Sample alerts dialog: pick the subscription and the plans to simulate. Source: Microsoft Learn, CC BY 4.0. · captured 2026-10-22

Verify​

  • Create sample alerts for the plans you own. Within minutes you should see them in Security alerts, in the Defender portal alert queue (non-informational only), in email if the severity clears the threshold, in Logic App run history, and in SecurityAlert in both the Sentinel workspace and the continuous export workspace.
  • For a real detection on a VM, run the Learn EICAR test: Windows elevated command prompt with the documented powershell.exe -NoExit ... line that downloads invoice.exe from 127.0.0.1, or curl -O https://secure.eicar.org/eicar.com.txt on Linux. Alert within about 10 minutes. App Service: browse to /This_Will_Generate_ASC_Alert on the site, allow 1.5 to 4 hours. Storage and Key Vault: access a SAS URL or the vault through Tor.
  • Defender for Cloud > Workflow automation shows each automation with its status. Logic app run history shows the trigger payload.
  • Event Hub: namespace > Metrics for incoming messages, or Capture to read the JSON.
  • Sentinel connector page shows Connected per subscription and the last data received time.
// 1. Defender for Cloud alerts in the last 7 days by severity and product component
SecurityAlert
| where TimeGenerated > ago(7d)
| where ProductName == "Azure Security Center"
| summarize Count = count() by AlertSeverity, ProductComponentName
| order by Count desc
// 2. Who is noisy: top alert names and the resources behind them
SecurityAlert
| where TimeGenerated > ago(30d) and ProductName == "Azure Security Center"
| summarize Alerts = count(), Resources = dcount(CompromisedEntity), Sample = any(CompromisedEntity) by AlertName
| top 20 by Alerts
// 3. MITRE tactic spread, useful before building suppression rules
SecurityAlert
| where TimeGenerated > ago(30d) and ProductName == "Azure Security Center"
| mv-expand Tactic = todynamic(Tactics)
| summarize count() by tostring(Tactic), AlertSeverity
| order by count_ desc
// 4. Status sync check: alerts still New in the workspace but older than a day
SecurityAlert
| where ProductName == "Azure Security Center"
| summarize arg_max(TimeGenerated, *) by SystemAlertId
| where Status == "New" and TimeGenerated < ago(1d)
| project TimeGenerated, AlertName, AlertSeverity, CompromisedEntity, Status
// 5. Duplicate detection across connectors: same SystemAlertId arriving more than once
SecurityAlert
| where TimeGenerated > ago(7d) and ProductName == "Azure Security Center"
| summarize Copies = count(), Sources = make_set(SourceSystem) by SystemAlertId, AlertName
| where Copies > 1

TODO: confirm in the dev tenant that Status and SourceSystem behave as assumed in queries 4 and 5. Learn documents the ProductName filter only.

Troubleshoot​

SymptomLikely causeFix
Alert in Defender for Cloud, nothing in SentinelSubscription not connected, no Defender plan on it, SecurityInsights provider not registered, or subscription is in another tenantConnector page: toggle the subscription on, check the Defender plans column, register the provider. Cross-tenant does not work, even with Lighthouse
Alert in Sentinel but the incident has no alerts or entitiesIncidents arrive via Defender XDR but the legacy connector does not cover that subscriptionSwitch to the tenant-based connector
Two incidents for one Defender for Cloud attackDefender XDR incident integration on, plus the Create incidents rule or a custom analytics rule still active, or both connectors enabledDisable the Microsoft Security and Scheduled rules for Defender for Cloud, disconnect the legacy connector, keep tenant-based
Alert closed in Sentinel, still Active in Defender for CloudBi-directional sync off, or you closed the alert instead of the incidentEnable bi-directional sync per subscription. Only closing the incident closes the source alert. Allow a few minutes
Alert dismissed in Defender for Cloud, Sentinel incident still openBy design. Alert status never changes incident statusAutomation rule in Sentinel keyed on alert status, or close the incident by hand
MDE alert on an Azure VM shows different status in the two portalsBy design. MDE alerts on cloud resources do not sync statusTreat the Defender portal as the source of truth for MDE alerts
Informational alert missing in Defender portalBy design. Informational alerts are not integratedQuery it in Azure portal or SecurityAlert
Logic App never runsTrigger is the unsupported legacy response trigger, logic app is Standard not Consumption, the recommendation in the trigger was deprecated, or the automation scope is a different subscriptionRebuild on one of the three supported triggers in a consumption app, check release notes, check scope. Test with Trigger logic app from an alert
Logic App missing from the Add workflow automation dropdownIt has no Defender for Cloud connector trigger yetAdd the trigger in the designer, Save, come back and Refresh
Continuous export shows no dataExport just created with streaming only and nothing has changed; target in another subscription without write permission; Event Hub policy lacks SendEnable snapshots or create sample alerts; grant the role on the target; fix the policy
Data limit has been exceeded alertA record over 32 KBLearn offers no workaround. Reduce exported data types or accept the drop
Recommendation workflow stopped weeks agoRecommendation deprecated or replacedUpdate the trigger to the new recommendation key
No email on a High alertThreshold or role mismatch, or daily cap of four High emails per address already hitCheck Email notifications on that subscription. Caps are per address per day
Suppression rule does not list the alert typeThat type has never fired in the scopeRules only cover types seen at least once. Create it from the alert once it fires
Agentless alert persists after fixing the agent-based oneAgentless result waits for the next scanWait for the next scan cycle

Gotchas and limits​

  • The two Sentinel connectors and the Defender XDR connector are three different pipes into the same SecurityAlert table. Pick tenant-based plus XDR incident integration and turn the rest off. Anything else gets you duplicate incidents, as Learn and every practitioner test in the last two years confirm.
  • Once Sentinel is onboarded to the Defender portal the Defender for Cloud connector disappears from that portal's data connector list. The alerts still arrive through Defender XDR. Do not go hunting for a missing connector.
  • Tenant-based connector is still Preview at source check. Subscription-based is labelled Legacy and Learn says not recommended.
  • The Defender XDR view is tenant-wide. There is no per-subscription scoping of visibility, only the alert subscription ID filter in the queues. Factor this into Unified RBAC design for multi-team tenants.
  • Email caps are per address. Four High alert emails a day is the ceiling, so email is a wake-up call, not a workflow. Route the workflow through Logic Apps or Sentinel.
  • Workflow automation is consumption Logic Apps only. Standard logic apps are not an option.
  • Continuous export with streaming only is silent until something changes. Turn on snapshots or fire sample alerts when you need to prove the pipe.
  • Snapshot records carry IsSnapshot. Filter them out in alert counts or you double count once a week.
  • Deleting a suppression rule does not reactivate alerts. Simulate first, set an expiry, and review the Dismissed filter periodically.
  • Learn documents only Dismiss as a value for Set-AzSecurityAlert -ActionType. The CLI documents all four states. Prefer az security alert update for scripted triage until the cmdlet page is updated.

Further reading​

The best hands-on duplicate testing (Managed Sentinel and BlueVoyant, March 2024, and Jakub Fras on continuous export at scale, February 2025) predates the window.

My notes​

TODO: Sohail's notes after verification.

Changelog​

DateChangeSource
2026-10-22Drafted from Learn, with Learn images and diagrams[1]