What is XDR Telemetry?

XDR Telemetry is:

XDR telemetry is the data collected by different security products. Every security layer or product has different types of activity data. An XDR platform uses telemetry to detect and hunt for unknown threats and assist in root cause analysis.

Telemetry type by security layer

Security products collect data regarding a variety of different events that occur within a business day.  These events vary from user-accessed file information to registry modification on a device. Example of the types of data collected include but are not limited to: 

Network Events

  • Traffic flow patterns
  • Perimeter and lateral connections made
  • Suspicious traffic behaviors
  • TLS (formerly SSL) fingerprints (JA3)

Cloud workloads

  • Configuration changes
  • New/changed instances
  • User account activity
  • Processes
  • Executed commands
  • Network connections
  • Files created/accessed
  • Registry modifications


  • Message metadata (external + internal email)
  • Attachment metadata
  • External links
  • User activity (e.g., logins)


  • Processes
  • Executed commands
  • Network connections
  • Files created/accessed
  • Registry modifications

How collected telemetry makes a difference

The capability to collect telemetry is not new or unique. What differentiates XDR platforms is which data is collected and what is done with it.

An XDR platform built primarily on its own native security stack has the advantage of having a deep understanding of the data and can therefore collect exactly what is needed to optimize analytical models for correlated detection, in-depth investigation, and threat hunting.

Vendors who are primarily focused on pulling data from third-party products start with less understanding of the associated data. Likely they are not getting the type and depth of telemetry needed to understand the full context of the issues. Most will look at alert data that does not provide related activity data (e.g., telemetry, metadata, NetFlow) to run analytics to drive actionable insight.

How telemetry is structured and stored is as important as what telemetry is collected. Depending on the activity data, different databases and schemas are more appropriate at optimizing how the data is captured, queried, and used. Selecting the most efficient structure of the data lake build based on data characteristics enables it to serve the data usage best. For instance, for network data, a graph database might be the most efficient, but for endpoint data, Elasticsearch might be preferable. Having various data lake structures set up for different telemetry can make a significant difference in leveraging the data’s  efficiency and effectiveness for detection, correlation, and search. Trying to fit the data within a single, common schema means losing a depth of capability.

XDR telemetry vs. SIEM alerts

SIEM aggregates logs and alerts well; however, it is not as efficient at connecting multiple alerts identified with the same incident. This would require evaluating its root telemetry across security layers.

Leveraging telemetry, XDR alerts can consider not only alert information but other critical activities in order to identify suspicious or malicious activity. For example, PowerShell activity on its own may not result in a SIEM alert, but XDR can look at that alongside other endpoint activities, and when considered together, identify it as part of a core event.

By running detections models on the collected telemetry, an XDR platform can identify and send fewer, higher-confidence alerts to the SIEM, reducing the amount of triage effort required by security analysts.

XDR Security Topics