Source: CD's readiness notes Sentinel-Readiness/Data Connector - M365D.md (free vs paid tables, bi-directional sync, the "duplicated incidents" checklist question), rebuilt as a lab story and cross-checked against Microsoft Learn on 2026-10-28. Lab names only; screens are drawings.

Monday morning at Contoso. The SOC queue shows two High incidents, same device LAB-WIN11-01, same minute, same title "Suspicious PowerShell command line". An analyst closes one as a duplicate. Ten minutes later it is back, reopened, because the other portal still considers it Active.

The same week a Defender for Cloud incident arrives with no entities and no alerts in it, just a title. And a hunting rule written against DeviceProcessEvents has been silent for a month. Not because nothing happened: the table was never switched on.

Three symptoms, one cause: the Defender XDR connector was turned on next to the old per-product connectors, and nobody read the checkbox.

It happened for real: Target, 2013

Duplicates sound like a tidiness problem. They are not. A queue full of copies is how a real alert gets closed or ignored, and the best-known example is Target's breach during the 2013 holiday season.

What happened

Date (2013) Event
Autumn Attackers get into Target's network with credentials stolen from an HVAC contractor.
Mid-November to early December They move from the vendor area to the payment systems and install malware on the checkout terminals.
30 November onwards Target's malware detection tool raises urgent alerts on the malware. According to the US Senate staff report, citing Bloomberg Businessweek, the alerts reached the security team and nobody acted on them.
Mid-December The US Justice Department tells Target about the breach.
19 December Target announces it.

Why it worked

  • Door 1, a vendor account with too much reach. The contractor's credentials led to a network that also held the payment systems. The Senate report notes that two-factor authentication was not required for all vendors.
  • Door 2, alerts that nobody acted on. The tool did its job. The process around it did not: the warnings sat in a queue with everything else.
  • Door 3, automatic removal turned off. The same report says the tool could have removed the malware by itself, and that option was off.

What it cost

Who What they lost
About 40 million card holders Card numbers stolen at checkout
Up to 70 million customers Names, addresses, phone numbers, email addresses
Target A total breach cost of 202 million USD (company figure, 2017), including an 18.5 million USD settlement with 47 states and Washington, D.C.
Leadership The CIO resigned in March 2014; the CEO resigned in May 2014

The same doors in a Microsoft tenant

  • Door 2, the alert lost in the noise: this whole post. One attack, one incident, synced both ways, so a "closed as duplicate" can never hide the real one. Then the check below: high-severity incidents that nobody has picked up.
  • Door 3, the tool that could have acted: Defender XDR automatic attack disruption contains a device or disables a user during an attack without waiting for an analyst. Check it is not excluded for your critical devices.
  • Door 1, the vendor account: Conditional Access for guests and external users, with MFA and access only to the apps they need. 
// High-severity incidents still New after an hour (nobody picked them up) SecurityIncident | where TimeGenerated > ago(7d) | summarize arg_max(TimeGenerated, *) by IncidentNumber | where Severity == "High" and Status == "New" | where CreatedTime < ago(1h) | project IncidentNumber, Title, CreatedTime, Owner = tostring(Owner.assignedTo)

Run it as a scheduled analytics rule every 30 minutes, and send the result to the SOC lead, not to the same queue.

TL;DR

  • Problem: Defender XDR already builds incidents from Defender for Endpoint, Identity, Office 365 and Cloud Apps alerts. If Sentinel also builds incidents from the same alerts (Microsoft incident creation rules, per-product connectors), you get two incidents per attack, and the two do not agree.
  • Who it hurts: analysts (double triage, reopened tickets), the SOC manager (MTTR and incident counts are wrong), the CISO (one real Defender for Cloud incident arrives empty), and the budget (events tables cost money whether or not anyone queries them).
  • Fix: one connector for all Defender products, Turn off all Microsoft incident creation rules ticked, per-product connectors left disconnected, Defender for Cloud connector on so those incidents are not empty, and only the events tables you have rules for.
  • Cost: incidents and alerts are free. Raw device events are billed per GB. For a 200-device lab that is about $650 to $800 a month at pay-as-you-go, less with the Microsoft 365 E5 data grant.
  • Prove it: one incident per Defender XDR incident ID, status changes in either portal within a minute, Defender for Cloud incidents with entities.

Table of contents

  • It happened for real: Target, 2013
  • 1. The problem
  • 2. Who gets hurt
  • 3. Cost and value
  • 4. How to fix it
  • 5. Prove it
  • Gotchas
  • Checklist
  • What changed recently
  • Sources
  • News sources

1. The problem

Think of two receptionists at the same front desk, each with their own visitor book. Every visitor is written down twice. When one receptionist marks a visitor "left", the other book still says "in the building". Nobody is lying; there are just two books.

In Sentinel the two books are:

  1. Defender XDR's own incident engine. It correlates alerts from all Defender products into one incident and sends that incident to Sentinel through the Microsoft Defender XDR connector. These incidents stay in sync both ways: close it in Sentinel and it closes in the Defender portal, and the other way round.
  2. Microsoft incident creation rules in Sentinel (Analytics, rule type "Microsoft security"), fed by the old per-product connectors (Defender for Endpoint, Identity, Office 365, Cloud Apps). These make a separate Sentinel incident per alert and do not sync with the Defender portal.

Run both and every Defender alert becomes two incidents. Close the wrong one and the synced one comes back. That is the Monday morning queue.

Two paths from one alert: the XDR incident and the incident creation rule

The other two symptoms come from the same connector page:

  • The XDR connector also brings Defender for Cloud incidents, but their alerts and entities only arrive if the Defender for Cloud connector is enabled too. Otherwise the incident is a title with nothing inside.
  • The connector's Events section is opt-in per table. No tick on DeviceProcessEvents means no rows, and a scheduled rule on that table returns nothing forever, without an error.

2. Who gets hurt

Who What they lose
Analysts Two tickets per attack, one of them reopening itself. Comments and classification written on the wrong copy are lost.
SOC manager Incident counts, MTTR and "closed as duplicate" statistics are fiction; so is the staffing argument built on them.
CISO / risk owner A Defender for Cloud incident about an exposed storage account arrives empty and is closed as noise.
Budget owner Events tables ticked "to be safe" bill per GB. Rules that need them were never written, or were written and silently get nothing.
The product "Sentinel duplicates everything" becomes the story, when the connector page already has the fix as a recommended checkbox.

3. Cost and value

Prices are USD list, pay-as-you-go, checked 2026-10-28; your region and agreement differ.

What is free. SecurityIncident and SecurityAlert from the XDR connector are not billed. My notes had this table already; Learn still agrees. So the fix for duplicates, empty incidents and sync costs nothing.

What is billed. The advanced hunting events tables (DeviceProcessEvents, DeviceNetworkEvents, DeviceLogonEvents, DeviceFileEvents, DeviceEvents, ...) are analytics-tier data at about $4.30 per GB in East US (up to about $5.59 in the most expensive US region); commitment tiers start at 50 GB a day and save up to 52%.

Lab example, 200 Windows devices, three tables ticked (process, network, logon):

Item Estimate
Volume about 30 MB per device per day = 6 GB/day
Pay-as-you-go 6 GB × $4.30 × 30 = about $775 a month
With Microsoft 365 E5 data grant (5 MB per user per day, covers Microsoft 365 advanced hunting data) 200 users × 5 MB = 1 GB/day free → 5 GB billed = about $645 a month
All ten tables ticked "to be safe" 2 to 3 times that, with no extra rules to use it

What the duplicates cost. 40 Defender incidents a week doubled is 40 extra triages × 10 minutes = about 7 hours a week, about 28 analyst hours a month, plus the reopened-ticket loop.

Value of the fix. Zero licence, zero ingestion: one checkbox and one disconnected connector return the 28 hours. The events tables are the only real spend, so switch on exactly the ones your rules read.

How others do it. Any SIEM that pulls both the Defender alerts API and the incidents API has the same doubling; Splunk's Microsoft Defender add-ons let you pick one input for the same reason. The problem is not the product, it is two books on one desk.

4. How to fix it

Lab: workspace law-contoso-sec, Defender XDR tenant for contoso.com, 200 devices in Defender for Endpoint, Defender for Cloud on sub-lab-prod.

Step 1: one connector. Content hub → install Microsoft Defender XDR solution → Data connectors → Microsoft Defender XDR → Open connector page. Under Connect incidents and alerts, tick Turn off all Microsoft incident creation rules for these products. Recommended and then Connect incidents & alerts. The checkbox disappears once connected, so do it now; afterwards you disable the rules by hand under Analytics.

Connector page with the incident creation rules checkbox

Step 2: leave the per-product connectors alone. When the XDR connector is on, Sentinel disconnects the Defender for Endpoint, Identity, Office 365 and Cloud Apps connectors in the background. They may still look connected on the gallery page; no data flows through them. Do not reconnect them. If you kept a "Microsoft security" analytics rule for any of these products, disable it (Analytics → filter rule type Microsoft security).

Step 3: Defender for Cloud. Enable the Microsoft Defender for Cloud connector (the tenant-based one) so the Defender for Cloud incidents that arrive via XDR carry their alerts and entities. Do not add a Microsoft incident creation rule for it; the XDR incident is already the incident.

Step 4: events, on purpose. Back on the XDR connector page, under Connect events, tick only the tables that a rule or hunt reads. In the lab: DeviceProcessEvents, DeviceNetworkEvents, DeviceLogonEvents. Apply changes. Each table you add is per-GB money.

Events tables: free incidents and alerts, paid device events

Step 5: automation that survives sync. An automation rule that closes incidents must set a classification; "closed" with no reason syncs to the Defender portal as Not set → Undetermined. If two incidents are merged on the Defender side, Sentinel closes one with the tag redirected; teach analysts that tag before they ask why incidents vanish.

5. Prove it

  1. One incident per Defender incident: 
SecurityIncident | where TimeGenerated > ago(7d) | summarize arg_max(TimeGenerated, *) by IncidentNumber | summarize n = count(), providers = make_set(ProviderName) by tostring(ProviderIncidentUrl), Title | where n > 1

Zero rows. Before the fix, each pair shows one Microsoft XDR and one Azure Sentinel provider for the same Defender incident URL.

  1. Close an incident in the Defender portal with True positive; Sentinel shows Closed / True Positive / Suspicious activity on refresh, within a minute.
  2. A Defender for Cloud incident in Sentinel has entities (the resource) and at least one alert.
  3. DeviceProcessEvents | where TimeGenerated > ago(1h) | count is greater than zero and the scheduled rule that reads it fires on a test powershell -enc run on LAB-WIN11-01.

Before and after: the incident queue

Gotchas

  • The checkbox is a one-time offer. It is shown only before you connect. After that, disable Microsoft security rules yourself.
  • Per-product connectors look alive. The gallery still shows "Connected"; it is cosmetic. Reconnecting them brings the duplicates back.
  • Alert schema changes. Alerts arriving via XDR have a slightly different SecurityAlert shape (provider, extended properties) than the standalone connectors. Queries and workbooks written against the old shape need a check.
  • 150 alerts. A Sentinel incident holds at most 150 alerts; a bigger XDR incident shows "150+" and a link to the full set in the Defender portal.
  • TVM tables are not ingested. DeviceTvm* tables appear in the schema and return nothing. Query vulnerabilities in Defender advanced hunting, or export them yourself.
  • Status mapping is not 1:1. Active in Defender becomes New in Sentinel; Not set becomes Undetermined. Build reports on the Sentinel values.
  • Comments sync one way per comment. New comments cross over; edits do not.
  • Defender portal onboarding. If the workspace is onboarded to the Defender portal, the XDR connector is turned on for you and Microsoft incident creation rules are not supported at all. Same end state, one less step.

Checklist

  • [ ] Microsoft Defender XDR solution installed, connector connected with the incident creation rules checkbox ticked
  • [ ] No enabled "Microsoft security" analytics rules for Defender XDR products
  • [ ] Per-product Defender connectors not reconnected
  • [ ] Defender for Cloud connector enabled, no incident creation rule for it
  • [ ] Only the events tables a rule reads are ticked; cost estimated per table
  • [ ] Automation rules set a classification when closing
  • [ ] Duplicate query returns zero; sync test passes both ways
  • [ ] Analysts know the redirected tag and the "150+" link

What changed recently

Checked against Microsoft Learn on 2026-10-28:

  • My notes call it the Microsoft 365 Defender connector; it is Microsoft Defender XDR now, same connector, same free/paid table split (connector page updated 2026-07-02).
  • The connector page now says plainly that the per-product connectors are disconnected in the background when XDR is connected, and that they still appear connected. My notes only asked the question.
  • The Turn off all Microsoft incident creation rules checkbox is the documented way to avoid duplicates (integration page updated 2026-06-17); the status and classification mapping table on that page is what step 5 relies on.
  • Defender for Cloud incidents via XDR need the Defender for Cloud connector or they arrive empty. Not in my notes at all.
  • DeviceFileCertificateInfo joined the list of available events tables; the DeviceTvm* tables are explicitly not ingested.
  • Sentinel in the Azure portal retires after 31 March 2027; in the Defender portal the connector is automatic and Microsoft incident creation rules are not supported.

Sources

News sources

Cheat sheet: one connector, one incident, pay only for events you read

Thanks for reading! I'm Cuong, and on CD Security Lab I rebuild real Microsoft security cases in a safe lab and explain them simply. Follow along:

Got a question about your own tenant? Drop it in the comments.