# Preserve source-event identifiers in aggregated Defender detection queries

> How should an aggregated custom detection query retain the event context needed for its alert?

- Canonical URL: https://update.dsesecurity.com/updates/dse-20260917-053-preserve-source-event-identifiers-in-aggregated-defender-detection-queries/
- Publisher: Detection Systems & Engineering (DSE Security)
- Author: DSE Security Editorial Team
- Published: 2026-09-17T16:34:07+00:00
- Modified: 2026-09-17T16:38:44+00:00
- Last reviewed by DSE: 2026-09-17
- Resource type: Guide
- DSE priority: Information
- Topics: Cybersecurity, IT
- Reading time: 1 minutes

## What you need to know

How should an aggregated custom detection query retain the event context needed for its alert?

## Potentially affected

Use this review when converting a Microsoft Defender hunting query into a custom detection, especially after adding aggregation or a projection. Name the source table and intended affected asset before reviewing the output.

## DSE recommendation

DSE recommends reviewing the query output as an alert contract.

## Article

## Source facts

For Defender for Endpoint tables, Microsoft recommends returning DeviceId and ReportId so alerts carry the correct device-group scope and can build the process tree. For other Defender tables, Timestamp and ReportId should come from the same event to preserve original-event identification and enrichment. Microsoft illustrates retaining the latest event’s timestamp and report identifier when summarizing by an entity. [Microsoft Learn](https://learn.microsoft.com/en-us/defender-xdr/custom-detection-rules).

## Applicability

Use this review when converting a Microsoft Defender hunting query into a custom detection, especially after adding aggregation or a projection. Name the source table and intended affected asset before reviewing the output.

## DSE recommendation

DSE recommends reviewing the query output as an alert contract. For each aggregation, document which original event represents the result and keep its identifiers together. Have the detection owner inspect sample result rows before enabling automated response, paying particular attention to groups containing several events.

## Verification

Run a controlled query against known test events and trace each returned identifier back to its source event. Inspect the resulting alert’s asset scope and available event context in an approved detection test. Record missing enrichment as a failed acceptance item rather than accepting the query merely because it returns rows.

## Official references

[Microsoft Learn: Create custom detection rules in Microsoft Defender XDR](https://learn.microsoft.com/en-us/defender-xdr/custom-detection-rules). Source reviewed September 17, 2026.

## Primary reference

- Name: Create custom detection rules in Microsoft Defender XDR - Microsoft Defender XDR | Microsoft Learn
- Authority: Microsoft Learn
- URL: https://learn.microsoft.com/en-us/defender-xdr/custom-detection-rules
- Source publication date: Not stated by the source

## Citation and use

Preferred citation: “Preserve source-event identifiers in aggregated Defender detection queries,” DSE Security, https://update.dsesecurity.com/updates/dse-20260917-053-preserve-source-event-identifiers-in-aggregated-defender-detection-queries/
Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/
Usage and citation policy: https://update.dsesecurity.com/usage/
Copyright © 2026 Detection Systems & Engineering. All rights reserved.