Frequently Asked Questions
Common questions about the EDR Telemetry Project and their answers.
EDR telemetry refers to the data collected and transmitted by Endpoint Detection and Response (EDR) products and tools. These products are designed to monitor, detect, and respond to potential threats and suspicious activities on endpoints such as computers, servers, and other devices within a network.
The EDR Telemetry Project aims to:
- Compare and evaluate telemetry capabilities across different EDR products
- Help security practitioners make informed decisions about EDR tools
- Encourage EDR vendors to be more transparent about their telemetry features
- Provide a comprehensive reference for EDR telemetry capabilities
The data is collected through:
- Direct testing in controlled environments
- Documentation review from vendors
- Community contributions and verification
- Continuous updates and validation
You can contribute by:
- Submitting telemetry data for EDR products
- Verifying existing data
- Reporting discrepancies or updates
- Joining our Discord community
Visit our Contribution page for more details.
The data is updated regularly as new information becomes available. We encourage the community to help keep the information current. You can also search on Github Pull Requests/commits for the EDR you are interested in to find the last updated date.
We use the following symbols in our telemetry tables:
- ✅ - Feature is fully implemented
- ❌ - Feature is not implemented
- ⚠️ - Feature is partially implemented
- ❓ - Information is pending or unverified
- 🪵 - Collected via Windows Event Logs
- 🎚️ - Available through additional telemetry settings
No. Scores reflect telemetry availability and exposed visibility under the project methodology. They do not measure prevention efficacy, detection efficacy, product quality, managed service quality, or SOC maturity.
See the methodology page for the full scope statement.
Valid telemetry must directly represent the tested system action, be automatically collected in real time or near-real time, be exposed to the customer for search or investigation, and be backed by evidence. Live query, manual collection, historical backfill, and backend-only conclusions do not count as scoring telemetry.
Alerts and correlated signals can be useful, but they are not substitutes for raw or near-raw event records. The project scores the telemetry that analysts can inspect, pivot on, and use for hunting, not only a product conclusion.
Partially means some related telemetry exists, but one or more full-credit criteria fail. Common reasons include missing required fields, conditional visibility, limited subset coverage, inconsistent generation, incomplete events, or related-but-not-direct action representation.
A status change needs enough evidence for reviewers to recheck the claim: test or action executed, expected telemetry, observed raw events or documented absence, query or search used, source/table/index, time window, observed and missing fields, screenshot or raw export, and rationale for the requested status.
Contribution requirements are summarized on the contribution page.
No or absence findings should document the search window, sources searched, queries or search terms, covered time range, endpoint identifiers, and any relevant vendor table or index guidance consulted. A vague claim that another source exists is not enough without enough detail to perform a targeted recheck.
Transparency indicators show how we validated the telemetry data for each vendor. These icons appear next to vendor names in the telemetry tables and scores page:
Validation was performed with direct, independent access to the product. The vendor granted us access to their platform without an NDA and with full permission to publish our findings.
Validation was performed by a verified, independent community member with direct product access. These contributors have confirmed access to the EDR and submitted evidence of telemetry capabilities.
Validation was based on evidence provided by the vendor (such as documentation, screenshots, raw logs, or a combination of these), without direct access to the product for independent verification.
Validation was performed under an NDA or other terms that may limit what can be disclosed. While we had access to the product, certain restrictions apply to our findings.
We have reached out to the vendor or are about to reach out and are awaiting a response regarding access to their platform for independent validation.
Still have questions? We're here to help!