# EDR Telemetry scores what an agent logs, not what it blocks > EDR Telemetry weighs endpoint agent coverage on a six-value scale that puts Via EnablingTelemetry on par with a native Yes, and a Pending Response on par with No. Useful for vendor shortlists, misleading for detection quality. **tsale/EDR-Telemetry** — This project aims to compare and evaluate the telemetry of various EDR products. - Repository: https://github.com/tsale/EDR-Telemetry - Website: https://edr-telemetry.com - Stars: 2,002 · Forks: 199 - Language: Python - License: NOASSERTION - Published: 2026-10-14 · Updated: 2026-10-14 · Language: en - Canonical page: https://hysenlabs.com/projects/tsale-edr-telemetry ## Comparing what endpoint agents log, before buying EDR Telemetry exists to answer one narrow question: which telemetry events does each endpoint product actually produce. The project describes itself as an effort to compare and evaluate the telemetry of various EDR products, and its comparison set covers endpoint agents such as Sysmon alongside commercial EDR suites. Its audience is the practitioner doing vendor selection or hunting a coverage gap, not an analyst writing detection logic. The boundaries are stated plainly. A disclaimer in the README says the data reflects only the telemetry capabilities of each product, not their detection or prevention capabilities. Read that as a limit on the evidence rather than as marketing modesty: a product logging full process-creation events with command line and hashes scores well here, while a vendor shipping competent detection rules on top of thinner logging can score poorly, and nothing in the dataset records that second fact. ## Three JSON files per platform feed a Python scoring script The repository's primary language is Python, and its top level shows the shape of the pipeline. EDR_telem_windows.json, EDR_telem_macOS.json and EDR_telem_linux.json hold per-platform records, and partially_value_explanations_windows.json, partially_value_explanations_macOS.json and partially_value_explanations_linux.json record why a feature earned a partial mark. A separate mitre_att&ck_mappings.json ties features to ATT&CK, sitting beside directories named scripts/, config/, data/, Tools/, telemetry_stats/, tests/, docs/ and images/. What each record holds is a single product's feature status for one platform, scored by an evaluation script that assigns scores based on feature implementation. Those directories are named but never documented. No entry point, no argument list, no dependency file, and no explanation of how config/ differs from data/ appears anywhere in the project, so a reader who wants to reproduce a score locally has no documented path to it. ## Six weights where two different halves share 0.5 The scale is printed in full. Yes scores 1.0, Partially 0.5, Via EnablingTelemetry 1.0, Via EventLogs 0.5, No 0.0 and Pending Response 0.0. Two choices hide inside those six numbers. Delivery route is weighted. A feature credited as Via EnablingTelemetry keeps the full 1.0 of a natively implemented one, so shipping a capability behind a documented policy switch costs a vendor nothing, while the same feature read out of EventLogs takes 0.5. Configuration state therefore never reduces a score for a capability the product does emit. Then there is the collision. Partially and Via EventLogs land on the same 0.5 for unrelated reasons: one describes how completely a vendor implements an event, the other describes where the data surfaces. No published formula lets a reader separate those cases in a finished score, and the complete breakdown is pushed out to the scores page on edr-telemetry.com instead of being kept in the repository. ## An unanswered vendor counts as a missing capability Pending Response is the entry most worth arguing about, and it is easy to miss because it carries no marker of its own. It scores 0.0, exactly what an outright No scores, so any ranking built on these weights counts a vendor who never answered the questionnaire as a vendor who confirmed the feature is absent. A low score can mean three different things: the product does not emit the event, the product emits it in a form the comparison did not credit, or nobody replied. Only the first says anything about the product. The per-platform partially_value_explanations files exist to record why a partial was granted, and the top level of the repository shows no matching file that separates unanswered entries from confirmed absences. ## No install command, the data arrives as repository JSON Expecting a package install or a container image will not go well here. The README documents no installation step, no package name, no command line and no configuration sample; what it offers instead is a route to finished results. The comparison table, the scores breakdown and the FAQ live on edr-telemetry.com, while the repository keeps the underlying per-platform JSON for reading, diffing or forking. A first real use is unglamorous. Open EDR_telem_windows.json for a Windows estate, or its macOS or Linux counterpart, confirm the products you already run appear in it, and look at how their features are graded. Then open the matching partially_value_explanations file for that platform before quoting any number, because a 0.0 may record silence rather than a missing feature. The default branch is main. ## A Telemetry-Generator named in tags, absent from the README The tags tell a different story from the README. The last push was on 2026-09-28, and tag v0.5, titled Telemetry-Generator v0.5: verified driver unload candidates and Driver Modification, landed the same day. Earlier, v0.4 on 2026-09-23 was self-contained Windows generator scripts, while v0.3 on 2026-04-22 was Windows Generator Improvements + macOS and Linux Added. So the project carries a generator component with its own version line and its own sequence of behaviour changes, and none of it reaches the README, which still opens with a logo, four badges and a bulleted list of key features. Nothing in the documentation says what the generator runs against, whether it needs a lab host, or how its output feeds the three per-platform JSON files. A reader hunting the comparison data finds a table; a reader hunting the production method finds silence. ## The wrong tool when detection quality is the question The clearest failure mode is misuse: treating a high score as evidence that a product will catch what it logs. Telemetry breadth tells you what you can build detections on. It says nothing about whether a vendor's own rules fire, and no column in the dataset records that. The terms are the second limit, and they are not the permissive ones. GitHub's licence field reports Other, a custom licence GitHub cannot classify, while the README names Creative Commons Attribution-NonCommercial 4.0 International, whose NonCommercial clause permits sharing and adaptation with attribution but blocks commercial reuse without the author's permission. Teams folding this comparison into procurement papers or vendor contracts need to clear the NonCommercial clause with the author before relying on it. ## Agent-first evidence instead of vendor-by-vendor scoring There is another route to the same answer, and the README gestures at it by placing Sysmon among the endpoint agents in the comparison. Instead of grading a vendor on declared feature status, install one agent on hosts you control and read what it writes. The evidence then belongs to your own environment, captured at the moment of the test, and it answers the narrow question of what a product emits on this kernel, this configuration and this workload. Detect.fyi hosts the blog post the README points to for background on the project. The trade-off is scale: a vendor-by-vendor scorecard covers products you have never deployed and costs nothing to read, while agent-first evidence covers one product on one fleet and costs a lab host plus a test cycle. Mistake the two and the error is easy, because a 1.0 in the table is not a finding on your network until you have produced the event yourself. ## Conclusion Adopt EDR Telemetry when you are choosing between endpoint agents and want one comparable view of what each logs, and read its numbers as vendor-reported status rather than verified behaviour. Do not adopt it to judge detection quality, because the dataset covers telemetry only. Before quoting any score, open the matching partially_value_explanations file for that platform, confirm the vendor answered at all, and check whether a 0.0 records silence or a genuinely absent event, then install one agent on a host you control and go looking for that telemetry yourself. ## FAQ ### What does EDR Telemetry compare? It scores which telemetry events each EDR product and endpoint agent produces, across Windows, macOS and Linux. The per-platform records sit in three JSON files at the repository root, and the rendered comparison lives on edr-telemetry.com. ### How does the EDR Telemetry scoring system work? Yes scores 1.0, Partially 0.5, Via EnablingTelemetry 1.0, Via EventLogs 0.5, No 0.0 and Pending Response 0.0. The complete breakdown is published on the scores page of the project's website. ### Does EDR Telemetry measure how well an EDR product detects malware? No. The README states that the data reflects only the telemetry capabilities of each product, not their detection or prevention capabilities. ## Sources - [Issues](https://github.com/tsale/EDR-Telemetry/issues) - [Project website](https://edr-telemetry.com) - [README](https://github.com/tsale/EDR-Telemetry/blob/main/README.md) - [Releases](https://github.com/tsale/EDR-Telemetry/releases) - [tsale/EDR-Telemetry on GitHub](https://github.com/tsale/EDR-Telemetry) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/tsale-edr-telemetry