A useful security alert marks the beginning of an investigation. However, the analyst still needs to determine what was executed, which user or admin account was used, which system was affected, what changes occurred, and whether the activity continued elsewhere. This assessment examines the extent to which an EDR, XDR or SIEM platform can support this process with evidence from controlled attacks.
We compare the information available on the tested platform with an independent record of the actual activity. Although detection, telemetry, correlation and response are examined together, they answer different questions. For example, an alert may identify malicious activity while leaving the process history incomplete. Similarly, a blocked action may stop an attack while providing little context for the investigation.
The result describes validated visibility and its limitations. This information is intended for Security Operations Centre (SOC) analysts, incident responders and teams selecting or operating a security platform.
The assessment covers endpoint detection and response (EDR), extended detection and response (XDR), and security information and event management (SIEM) platforms within the tested deployment. Evidence may come from endpoint sensors, integrated security services or ingested logs. The report identifies the product components and data sources that contributed to the result.
For SIEM and XDR platforms, we assess how connected data sources help analysts understand attacks and link related events. The assessment covers the integrations and capabilities used during testing. Additional features described by the vendor are only included if they can be verified in the tested environment.
“2026.Q4” identifies this methodology release. Each test edition records the release used, together with the tested product version and technical scope. A later methodology release does not retrospectively change an earlier result.
Scenarios reproduce defined attacker objectives within a controlled environment. These objectives may involve operating-system utilities, interpreters, scripts, remote administration mechanisms, persistence, and network communication and activity spanning several hosts. The aim is to create an investigation with a known technical history that an analyst can verify, including relationships.
A scenario may cover several stages of an intrusion but does not need to include all stages. We define the intended activity and relevant evidence before execution. During execution, we verify which actions succeeded, which were attempted and which were prevented. An intended action is never treated as an observed event merely because it appears in the scenario plan.
In Phase 1 we examine how the product links and correlates telemetry throughout a controlled attack scenario. Where technically possible, automatic prevention and response mechanisms that would otherwise interrupt execution are either disabled or adjusted, enabling the tester to trace the relationships between processes, events, and attack stages including activity across hosts, where applicable. Any restrictions affecting execution are documented.
This phase is not rated and does not contribute to certification. The tester uses its findings internally and subsequently provides them as technical feedback, identifying gaps, missing relationships, and other problems with telemetry correlation. The final assessment and certification decision are based exclusively on evidence from Phase 2.
Phase 2 involves running the relevant scenarios with the tested protection and response capabilities enabled. The assessment examines both the observed intervention and the evidence left for the analyst. Depending on the product and scope, this can include execution blocking, process termination, quarantine, remediation or endpoint isolation. Distinguishable evidence includes a response request, a product-reported action and an independently confirmed outcome.
Prevention protection can alter the sequence of events. Once an action has been blocked, subsequent activity may never occur. The Phase 2 timeline therefore records the point of intervention and any subsequent verified activity. The absence of telemetry for an action that did not execute does not constitute a visibility failure in itself.
We examine the evidence from each Phase 2 scenario against the applicable assessment parameters. The final rating for each parameter reflects the findings across all scenarios that test that capability, including the completeness of the evidence and the impact of any gaps on the analyst’s investigation.
The scale describes the quality of the visibility and context available to the analyst. A blocked attack can still support a Full rating when the executed activity and the point of intervention are sufficiently documented. Stages that did not occur because of the block are not treated as missing telemetry, but they cannot demonstrate capabilities that were not exercised.
The final evaluation is carried out after Phase 2, based exclusively on the evidence gathered during that phase. The assessed parameters and certification requirements are defined for each methodology release. For release 2026.Q4, the assessment covers up to 14 parameters.
These ratings apply to the parameters examined in each Phase 2 scenario. Activity that did not occur because it was prevented is recorded separately and is not rated as None. The final rating for each parameter considers the findings across all applicable Phase 2 scenarios.
The decision is based exclusively on Phase 2 results. Strong results in other parameters do not compensate for an unmet mandatory requirement.
Ground Truth is the reference we define before the test. It describes the planned attack activity, expected artifacts and relationships between attack stages. It is established independently of the tested product and provides the basis for checking its telemetry. Depending on the scenario, it covers host and user context, process relationships, commands, file and registry changes, persistence artifacts, network activity and transitions between hosts.
During the test, we collect separate execution evidence to confirm which actions actually occurred, their timing and where protection interrupted the scenario. Then we compare the product telemetry with the confirmed activity, using Ground Truth as the reference. Planned actions that did not occur are not treated as missing telemetry. Exact commands and technical artifacts remain in the internal test documentation and public reports describe their role without disclosing the execution procedure.
The report identifies the methodology release, product version and tested environment. It includes findings from both phases. Phase 1 findings provide technical feedback and do not affect final ratings or certification. Each parameter rating is based exclusively on Phase 2 evidence and includes a brief explanation of the findings and any relevant gaps in telemetry or correlation.
Product and test infrastructure configurations are publicly documented. We retain the evidence supporting our findings but do not disclose detailed attack procedures or exact commands. Payloads may appear in screenshots where relevant to a finding.
The methodology may be updated as attack techniques and product capabilities change. Each report identifies the methodology release used, including the applicable assessment parameters and certification requirements.
We invite security vendors to participate in the EDR-XDR Visibility & Correlation Assessment and independently validate their solutions in real-world attack scenarios. Contact us to learn more about testing, certification, and cooperation opportunities.
Vendors can participate directly in the Advanced In-The-Wild Malware Test or obtain a Certification-Only Package for a product independently tested by AVLab. Paid participation provides access to extended technical services, test data, and custom configuration options, while result review and verification remain available to all tested vendors.
Commercial use of AVLab certificates, certification badges, and award materials by independently tested vendors requires either Paid Assessment Participation or a Certification-Only Package. Independently tested vendors without either option may be listed in AVLab results and certification records but are not granted the right to use AVLab certification materials in their own marketing or communications.
