EDR Telemetry Guide: What Endpoint Data You Get and How to Detect With It

Most detection teams write rules against EDR data without knowing exactly which events their sensor records, which it filters away, and how long the raw events survive. EDR telemetry is the stream of process, file, registry, network, module, script and sensor-health events that an endpoint detection and response agent sends to its backend, separate from the alerts the vendor generates on top of it. This guide is about using that raw stream: auditing what your sensor really collects, getting the data out, understanding the EDR event model, writing detections that survive tuning and upgrades, and proving coverage with tests. It is for detection engineers, threat hunters and SOC leads. Native operating system sources such as Sysmon, Windows auditing and auditd are covered in the Endpoint Telemetry Guide; this page goes deeper on the EDR side.

Key takeaways

• Telemetry is not alerts. Vendor alerts are one consumer of the event stream; your own detections, hunts and investigations need the raw events, so treat raw access as a requirement, not a bonus.
• Audit the sensor, not the datasheet. Build a telemetry inventory per operating system from your own test events, because sensors aggregate, sample or drop high-volume event types and behaviour differs between Windows, Linux and macOS.
• Join on the sensor's own identifiers. Process GUIDs, parent GUIDs and logon IDs make process trees reliable; process IDs alone are reused and break correlation.
• Write behaviour, then map the fields. Express detections in a neutral form (Sigma categories, OCSF or ECS fields), then translate to the EDR query language, so rules survive a platform change.
• Silence is a signal. Sensor health events (agent stop, uninstall, errors, missed keep-alives) are telemetry too; alert on them, because attackers target the sensor before they act (ATT&CK T1685 Disable or Modify Tools).

What EDR telemetry is and how it differs from other endpoint data

An EDR sensor collects from the same operating system facilities a native tool would use, then adds its own enrichment, correlation and response. On Windows, sensors combine kernel callbacks with Event Tracing for Windows (ETW), where providers emit events into sessions that consumers read in real time. On macOS, security products use Apple's Endpoint Security framework, a C API whose clients either authorise pending events or receive notifications of events that already occurred, such as process executions, forks and file system mounts; it requires the com.apple.developer.endpoint-security.client entitlement and exists from macOS 10.15. On Linux, many sensors attach eBPF programs to system calls, tracepoints, kprobes and uprobes; programs pass the kernel verifier before they load.

What the sensor does next decides what you can detect:

• Enrichment: hashes, signer and publisher, file reputation, user and logon session, integrity level, and full process lineage are attached at collection time, which native logs usually lack.
• Filtering and aggregation: to control bandwidth, sensors may drop repetitive events, summarise network connections or image loads, or send some event types only when a related behaviour fires. The raw table you query may therefore be a sample of what happened.
• Retention: console retention is set by the product and licence. Investigations that start months after initial access need the raw events exported to storage you control. See the Log Management and Retention Guide.
• Loss: Microsoft documents that ETW events are lost when a real-time consumer cannot keep up, when an event exceeds 64 KB or when a log disk is too slow. Every sensor has an equivalent failure mode, so dropped-event counters belong in your health monitoring.

The open-source EDR Telemetry project compares the telemetry features of EDR products and agents such as Sysmon. It states that its data reflects telemetry only, not detection or prevention capability, and it scores features as Yes, Partially, Via EnablingTelemetry or Via EventLogs. Its category list is a useful neutral checklist for your own audit, independent of any product.

The telemetry categories to inventory

The table below uses the EDR Telemetry project's Windows and Linux categories, with the ATT&CK v20 data component that each one feeds and example techniques that depend on it. Mark each row for your sensor as collected, collected with conditions (sampled, off by default, needs a policy), or not collected, based on your own test results.

ATT&CK v20 retired the old data source objects (for example DS0009 Process is deprecated) and now links data components to detection strategies and platform-specific analytics. Use the strategies as a requirements list: DET0363, Detection of Credential Dumping from LSASS Memory via Access and Dump Sequence, needs Process Access, Process Creation and File Creation on Windows; DET0508, Behavioral Detection of Process Injection Across Platforms, needs Process Access, Process Creation, Module Load and OS API Execution on Windows. If your inventory shows a gap in any of those components, the strategy cannot be fully implemented on that platform, whatever the rule says.

Getting the raw data out

Detection engineering on EDR data happens in one of three places, and most mature teams use more than one.

Decision guidance: if you run one endpoint product and fewer than a few thousand endpoints, start with console detections and add export only for the categories you must keep longer (process creation, network, persistence, sensor health). If you already run a SIEM or data lake with identity and cloud logs, stream process, network and persistence events in full and keep high-volume categories such as file opens and image loads in the console, querying them on demand. Whichever model you choose, write down the retention of each category in the inventory, because "we have the data" is only true for the window you can still query. See the SIEM Guide.

Understanding the EDR event model

Detections fail more often on joins and field semantics than on logic. Check these properties for your sensor before writing rules.

• Unique process identifiers: operating systems reuse process IDs, so sensors issue their own unique identifier per process instance (Sysmon calls it ProcessGuid, with ParentProcessGuid for the parent). Join process, network, file and registry events on that identifier and the host ID, never on PID alone.
• Actor and target: process access, injection and termination events have two processes. OCSF Process Activity models this with an actor and a target process and activity IDs 1 Launch, 2 Terminate, 3 Open, 4 Inject and 5 Set User ID; it also notes that Windows security products cannot always identify the actor when one process terminates another. Know which field is which in your schema.
• Parent versus creator: spoofed parent processes and processes launched through services, WMI or the task scheduler make the immediate parent misleading. Use full lineage (grandparent and beyond) and the logon session, not just the parent image.
• Command line fidelity: confirm whether command lines are truncated at a fixed length and whether the sensor records the full script block for PowerShell, or only the launcher command.
• Time: distinguish the event time on the endpoint from the ingestion time in the backend. Offline laptops can deliver hours of events late; detections with short look-back windows must use event time.
• Signer and hash enrichment: know when the sensor calculates hashes (on execution, on write, or lazily) and whether unsigned or newly seen binaries are flagged, because many high-value rules depend on prevalence and signature.

Mapping to neutral schemas

Translating vendor fields into a neutral schema lets one rule run against several sources. The table shows the same behaviours in three widely used open schemas.

Sigma field names follow Sysmon (Image, CommandLine, ParentImage, ParentCommandLine, IntegrityLevel, LogonId, Hashes), so a vendor mapping file from those names to your EDR fields is the core asset of a portable rule set. See the OCSF Guide and the Sysmon Guide.

Writing detections on EDR telemetry

EDR data supports richer logic than single-event matching. Use the D3FEND analysis techniques as a vocabulary for what each rule does: Process Spawn Analysis (D3-PSA), Process Lineage Analysis (D3-PLA) and System Call Analysis (D3-SCA).

• Lineage rules (D3-PLA): an office application, browser or mail client spawning a script interpreter (T1059.001, T1059.003), or a web server process spawning a shell. These rely on complete process creation and reliable parent identifiers.
• Access-and-artefact sequences: DET0363 pairs a handle open to lsass.exe with suspicious access rights and a dump file written shortly after by the same process. Join the Process Access and File Creation events on the process identifier within a short window. See the Credential Dumping Guide.
• Persistence-with-context: a new service (T1543.003) or scheduled task (T1053.005) is common; one whose binary sits in a user-writable path, is unsigned, and was written to disk minutes earlier by a process that also made an outbound connection is not.
• Prevalence and first-seen: combine hash or signer prevalence across the fleet with process creation. A binary seen on one host, run by a service account, is a strong pivot for System Binary Proxy Execution (T1218) and masquerading (T1036) hunts. See the Living off the Land Guide.
• Sensor health: agent stop or uninstall outside a change window, a keep-alive gap on a host that still authenticates to the domain, or a new driver load followed by sensor errors. Treat these as high-severity detections in their own right. See the Bring Your Own Vulnerable Driver and EDR Killers Guide.

Keep each rule in version control with its required data components, the sensor setting it depends on, and a test that should trigger it. See the Detection as Code Guide.

Where identity fits

EDR telemetry is full of credentials. Command lines carry passwords, API keys and connection strings passed as arguments, and script block content captures tokens embedded in scripts. Microsoft warns, for the native equivalent, that once command lines are logged anyone who can read the events can read those arguments. Apply the same thinking to the EDR backend and every export destination: restrict raw-event search to named analyst roles, mask or hash known secret patterns in the export pipeline where your tools allow it, and turn a secret found in telemetry into a rotation ticket. The same data is also your best view of non-human identities on endpoints: service accounts launching processes interactively, scheduled tasks running as privileged accounts, and automation tools reading credential stores. Protect EDR administrator and API credentials as privileged access, since they can disable sensors fleet-wide and run commands on every host. See the Securing the EDR and XDR platform itself page and the EDR Guide.

Implementing an EDR telemetry programme

1. Inventory per platform. For Windows, Linux and macOS separately, record each category from the table above as collected, conditional or absent, with the policy setting that controls it and its retention in the console.
2. Validate with tests, not documentation. In a lab or pilot ring, run benign, ATT&CK-mapped tests (the open-source Atomic Red Team library is one such set) and confirm which events arrive, how quickly, and with which fields. Record any sampling or aggregation you observe.
3. Close gaps by policy first. Many categories are off by default or controlled by a sensor policy. Enable them on a pilot group, measure volume and endpoint performance, then widen. Roll back by reverting the policy for the pilot group if CPU, disk or network impact exceeds the agreed threshold.
4. Fill the rest with native sources. Where the sensor does not collect a category you need, add a native source (Sysmon, Windows auditing, auditd) and forward it to the same place. See the Endpoint Telemetry Guide.
5. Decide the access model. Choose console, stream or both per category, set retention, and document the field mapping to your neutral schema.
6. Migrate detections. Port rules to the neutral form, deploy in alert-only mode for two to four weeks, tune exclusions with documented reasons, then promote. See the EDR Tuning and Exclusions Management Guide.
7. Re-test on change. Re-run the validation set after every sensor upgrade, policy change and operating system feature update, because each can change what is collected.

Detection and measurement

• Telemetry coverage: percentage of required data components collected per platform, from the inventory. Target full coverage of the components used by your priority detection strategies.
• Sensor coverage and health: percentage of managed endpoints with a sensor reporting in the last 24 hours, and the count of hosts with dropped-event or error states.
• Validation pass rate: share of validation tests whose expected events arrived with the expected fields, per platform and sensor version.
• Ingestion latency: median and 95th percentile delay between event time and searchable time, for console and exported data.
• Detection test coverage: percentage of production rules with an automated test that fired in the last quarter.
• Retention fit: searchable days per category compared with your investigation and regulatory requirement.

Framework mapping

Common failure patterns

• Assuming the table is complete: rules query a network or image load table that the sensor populates only partially, so a quiet result is read as "nothing happened".
• Joining on PID: correlations across process, file and network events break when process IDs are reused, producing both misses and false links.
• Rules tied to vendor field names: a platform migration forces a rewrite of every detection because no neutral form or mapping file exists. See the EDR and XDR platform migration playbook.
• Broad exclusions: a performance exclusion for a directory or process also removes its telemetry, creating a blind spot that attackers can use.
• No alert on silence: sensors stopped by tampering or failed upgrades go unnoticed for weeks because only vendor alerts are monitored.
• Secrets left in exports: raw command lines streamed to a data lake with broad read access expose credentials to everyone who can search it.

Practitioner checklist

• Build a per-platform telemetry inventory with collection status, controlling policy and retention for each category.
• Validate the inventory with ATT&CK-mapped tests in a pilot ring and record sampling or aggregation behaviour.
• Map each priority ATT&CK detection strategy to the data components it needs and flag gaps.
• Decide console, stream or both for each category and set retention to match investigation needs.
• Join events on the sensor's unique process and host identifiers, never on PID alone.
• Keep detections in a neutral form with a field mapping file and an automated test per rule.
• Alert on agent stop, uninstall, errors and keep-alive gaps as high-severity detections.
• Restrict raw telemetry search, mask secrets in exports and rotate any credential found in command lines.
• Re-run validation after every sensor upgrade, policy change and operating system feature update.

Standards and references

• MITRE ATT&CK: OS Credential Dumping: LSASS Memory
• NIST: SP 800-53 Rev. 5
• OCSF: Open Cybersecurity Schema Framework schema
• SigmaHQ: Sigma Taxonomy
• Elastic: ECS event.category allowed values
• Microsoft: About Event Tracing
• Apple: Endpoint Security framework
• EDR Telemetry project: telemetry feature comparison

Related NHI Mgmt Group resources: Endpoint Telemetry Guide · Detection Engineering Guide · EDR Evasion and Defence Guide · EDR and XDR Buyer's Guide