Skip to main content
Microsoft keeps a Defender XDR incident and its Microsoft Sentinel counterpart synchronised, and presents them to you as one “parallel incident”. ContraForce reads both APIs, so without a rule that same real-world incident arrives twice under two different vendor IDs. ContraForce resolves this per incident: it keeps the incident on the side it originated and discards the mirror. No configuration is required, and there is no toggle to set.
Deduplication only applies to a workspace with both the Microsoft Defender XDR and Microsoft Sentinel detection modules connected. See Detection module state.

​
How ContraForce decides

Both systems label the origin of an incident, and ContraForce reads those labels directly. There is no cross-API lookup, no correlation database, and no dependence on which copy arrives first. That last row is deliberate. An unreadable label, an unfamiliar provider, or a provider call that fails all mean “show the incident”. A duplicate is a visible annoyance; a discarded incident is silent data loss.

​
The providerName values you will see

​
The three forwarding scenarios

The Defender XDR data connector in Microsoft Sentinel has Connect incidents & alerts enabled, so Defender incidents are pushed into Sentinel.Those forwarded copies carry providerName of Microsoft 365 Defender.
  • Kept: the Defender XDR incident, attributed to Defender.
  • Discarded: the Sentinel copy.
  • Unaffected: incidents created natively in Sentinel, which carry Azure Sentinel and are never mirrors.
In the portal, an incident that originated in Defender shows Microsoft Defender XDR as its source, even though a copy also exists in your Sentinel workspace.
Forwarding in both directions at once is common, not exceptional. A workspace onboarded to the Defender portal will typically show Sentinel-origin incidents in Defender and Defender-origin incidents in Sentinel. Because the rule is applied per incident, each one is resolved on its own evidence and the correct copy survives in both directions simultaneously.

​
Detection module state

Deduplication is only safe when ContraForce actually reads both systems. Before discarding a mirror, ContraForce checks that the counterpart detection module is connected and enabled on the workspace.
Disabling one of the two detection modules changes deduplication behaviour immediately. A workspace that was discarding mirrors will start keeping them, because the counterpart is no longer being read. Incident volume in the queue will rise accordingly. This is correct: it is better to show a duplicate than to hide the only copy.

​
Downstream effects

The decision is made once, at ingestion, before any other processing occurs. A discarded mirror never becomes an incident in ContraForce, so it creates no state anywhere downstream.
If your incident counts fell when this behaviour was introduced, that is the duplication being removed. The count now reflects distinct real-world incidents. Historical aggregates computed before the change still include the duplicates and are not retroactively corrected.
Deduplication is applied when listing incidents, not when fetching one. A direct link to a mirrored incident still opens and displays it. This is intentional: a link shared in a ticket, an email, or a chat message continues to resolve rather than returning “not found”.

​
What this replaced

Earlier versions of ContraForce offered a per-workspace toggle to suppress an entire source. That approach was withdrawn because it cannot be made correct:
  • A workspace commonly forwards in both directions, so there is no single source that is safely redundant.
  • Suppressing Microsoft Sentinel discards incidents that never reach Defender at all, including any created manually, through the API, by a playbook, or in a secondary workspace.
The toggle no longer exists and no action is required. Any previously configured value is ignored.

​
Troubleshooting

Confirm both detection modules are connected and enabled on the workspace. With only one connected, ContraForce keeps every incident by design.If both are connected, check the providerName on the Sentinel incident. A value other than the three listed above is not recognised as a mirror and the incident is kept deliberately, so that an unfamiliar label never causes data loss.
Attribution follows origin, not arrival. An incident created by a Sentinel analytic rule is attributed to Sentinel even when it also appears in the Defender portal, and an incident created by Defender is attributed to Defender even when it also appears in your Sentinel workspace.
Deduplication never removes the last copy, so a missing incident is unlikely to be caused by it. Check the time filter first: the incident list filters on incident creation time, while the Microsoft Defender portal displays last activity time. An older incident with recent activity appears recent in Defender and falls outside a short creation-time window in ContraForce.