EDR Eligibility Criteria
Understanding which solutions qualify for comparison in the EDR Telemetry Project
Core Requirements
For an EDR solution to be included in our comparison, it must meet these basic requirements:
- Provide real-time or near real-time event collection
- Offer automated telemetry collection without manual intervention
- Include out-of-the-box telemetry capabilities
- Function as a dedicated endpoint detection and response solution
- Collect direct telemetry events rather than inferred activities (See detailed explanation below)
EDR Telemetry Definition
In this project, EDR Telemetry refers to data or events that are:
✓ Included
✗ Not Included
- Live querying of artifacts
- Access to artifacts on a system
- Signals or detections based on correlation
- Additional modules or integrations
Telemetry Events vs. Inferred Activity
Each telemetry event must represent a distinct and independent system action, captured directly rather than inferred:
✓ Direct Telemetry
Explicit event recording of service creation through Windows Service Control Manager
✗ Inferred Activity
Assuming service creation by detecting new registry keys under HKLM\SYSTEM\CurrentControlSet\services
Solutions Not Currently Meeting Criteria
Important Note
The exclusion of a product from this comparison does not reflect on its overall quality or effectiveness. Each solution listed below may excel in its intended use case and could be the ideal choice depending on your specific environment, security requirements, and operational needs.
Our eligibility criteria are specifically designed for comparing traditional EDR telemetry capabilities and should not be the sole factor in evaluating security solutions for your organization.
The following solutions are not included in our comparison due to specific limitations in meeting our eligibility criteria:
- Lacks continuous real-time telemetry streaming capabilities of traditional EDR solutions
- Focuses on periodic scanning and threat hunting rather than continuous monitoring
- Designed for point-in-time forensics and incident response rather than real-time detection
- Relies on manual VQL queries for artifact collection
- No continuous automated telemetry stream
- Better suited for incident response than continuous monitoring
- Designed for point-in-time queries
- Lacks native event streaming capability
- Requires additional tooling for continuous monitoring
- Lacks direct access to raw telemetry data for customer analysis and investigation
- Managed threat hunting platform rather than traditional EDR
- Limited endpoint telemetry visibility for customers
- Lacks direct access to raw telemetry data for customer analysis and investigation
- Requires additional modules and licensing for basic EDR capabilities
- Limited endpoint telemetry visibility in base product
- Primarily focuses on forensic endpoint visibility rather than real-time telemetry ingestion
- Uses polling-based architecture instead of continuous event streaming, leading to potential telemetry gaps
- Lacks continuous real-time process creation, file modification, and script execution monitoring
- Does not provide open access to detailed raw telemetry data
- Telemetry data is aggregated, limiting granular event-level visibility
- Functions as a threat detection engine rather than a complete EDR solution
- Relies on log ingestion and rule-based detection instead of real-time telemetry collection
- Does not stream telemetry data to a centralized location for real-time analysis and monitoring
- Relies on external tools (Sysmon, OSQuery) for basic endpoint telemetry collection
- Functions primarily as a log aggregator rather than direct telemetry collector
- Lacks native real-time event streaming capabilities for endpoint activities
- No ability to search logs unless an alert fires
- No continuous event ingestion for full system visibility
- Functions more like an NGAV than a true EDR