Endpoint Prevention & Response (EPR) Test 2025

Endpoint Protection Products (EPP), Endpoint Detection and Response (EDR), and Extended Detection and Response (XDR) solutions are vital components of enterprise security, providing defences against targeted threats such as advanced persistent threats (APTs). AV-Comparatives’ Endpoint Prevention and Response (EPR) Test is designed to evaluate the effectiveness of these solutions in countering complex, multi-stage attacks that can impact an organization’s entire infrastructure. In this report, we refer to all EPP, EDR, XDR, and similar products collectively as “EPR” solutions for simplicity.

Beyond securing individual endpoints, these systems are expected to analyse attack origins, tactics, and objectives, enabling security teams to contain threats, remediate affected systems, and prevent future incidents. AV-Comparatives’ Endpoint Prevention and Response Test remains the industry’s most comprehensive evaluation of such solutions. This year’s test covered 12 products, each subjected to 50 targeted attack scenarios simulating real-world threats across three critical phases: Endpoint Compromise and Foothold, Internal Propagation, and Asset Breach.

Each product was evaluated on whether it automatically blocked the attack (active response) or provided actionable intelligence for manual intervention (passive response). If an attack was not blocked in one phase, the scenario continued to the next. The test also noted each product’s ability to take remedial action and collect indicators of compromise in an accessible way.

To provide a meaningful comparison, we developed the Enterprise EPR CyberRisk Quadrant™, which considers not only breach prevention effectiveness but also cost-effectiveness, operational accuracy, and workflow efficiency. The model is based on a hypothetical enterprise with 5,000 client PCs over a five-year period. As part of our ongoing efforts to enhance the quadrant, several refinements were introduced in 2025 to reflect evolving enterprise needs and threat realities.

CyberRisk Quadrant Key Metrics- based on 5000 clients

Explanation of the EPR CyberRisk Quadrant

The quadrant displays two levels: Certified and Not Certified. Earning the Certified status reflects a high level of performance across all key areas and confirms that the product meets the rigorous standards of our evaluation. Certification is not easily achieved and remains a strong indicator of quality, reliability, and effectiveness. This streamlined presentation provides clarity while preserving the significance and prestige of being Certified.

Certified
Certified products offer an exceptional return on investment, resulting in a significantly reduced total cost of ownership (TCO). Their remarkable technical capabilities, coupled with bug-free performance, keep costs in check. These products consistently excel in prevention, detection, response, and reporting, while also delivering optimal workflow features for system administrators and operations.

Not certified
Products with a combined Active and Passive Response of less than 92%, and/or other costs that made the TCO too high, are not certified. When a product reaches five full breaches, it is automatically disqualified (not certified) and we stop testing it further, as it would be outside of the quadrant.

Which product is right for my enterprise?
The fact that a product is shown here in the highest area of the quadrant does not necessarily mean that it is the best product for your enterprise needs. Products in lower areas of the quadrant could have features that make them well suited to your particular environment. However, we are unable to recommend the use of products that have not been certified.

Placement of the dots
The vendor ‘dot’ placement on the Y axis of the quadrant was driven by how good the active response or passive response capabilities were. This score will also have an influence on the X axis; a product with a high active response rate will have a lower TCO, as the response costs are smaller. Furthermore, products that stop an attack in an earlier phase will also incur fewer costs. Other factors in the TCO calculation include purchase price, operational accuracy, and workflow delays caused by e.g. sandbox analysis.

EPR CyberRisk Quadrant Overview

The CyberRisk Quadrant factors in the effectiveness of each product at preventing breaches, the calculated savings resulting from this, the purchase costs of the product, and the product’s (in)accuracy costs.

One of the significant problems caused by a security breach is the financial cost incurred by the targeted organisation. According to IBM, the average cost of a breach in 2025 was USD 4.4 million. Therefore, purchasing an effective EPR product that minimises the negative impact of an attack can be a good investment. If a company stands to lose around USD 5 million if an attack is successful, then spending even USD 2 million on security measures makes good financial sense, aside from any other considerations.

In this section, we assess the overall costs of deploying the tested security products alongside their effectiveness in preventing security breaches. This allows us to evaluate how strong a financial investment each product represents. Based on IBM’s estimate of USD 4.4 million as the average cost of a data breach, we calculate the potential cost savings an organization could achieve by deploying each of the tested EPR products. The results show that all tested products provide meaningful protection, with their combined active and passive response capabilities preventing the vast majority of attacks. However, some products clearly outperform others. The more effective a solution is at preventing breaches, the lower the organization’s expected costs for incident response and remediation.

The graphic below outlines the formula used to arrive at the total cost of ownership for a product, which includes the following factors. Firstly, there is the price paid to the product’s vendor for the product and associated service and support charges. Next come any costs associated with over-blocking/over-reporting caused by the product, which are defined as Operational Accuracy costs below. These cases have to be investigated and remediated. In 2015, the Ponemon’s Institute estimated that companies waste roughly USD 1.3 million per year due to inaccurate or erroneous intelligence. To allow for inflation over the last ten years, a reasonable estimate for 2025 would be USD 1.76 million. This has been factored in as the added yearly cost that you can expect to pay for a product failing our operational-accuracy validation this year. Costs arising from imperfect Operational Accuracy are penalised, and costs due to workflow delays are also taken into account. Hence, if a user is operationally impacted by e.g. a product’s features, policies or behaviour, this will be reflected in the EPR CyberRisk quadrant as well.

Next come the costs associated with breaches, whereby a product that could theoretically block 100% of attacks would have zero breach costs here, whilst a product that did not block any attacks would incur the full cost of a breach.

The breach cost of each product per scenario was calculated, based on the ability of the EPR product to actively and passively respond at the time of execution. The procedure we used for calculating breach costs in 2025 is given below:

Active Response in Phase 1
If there was active response (i.e. the attack was successfully stopped automatically and reported) in Phase 1, then 0% of the total breach cost was added for the scenario. In case of a silent block without reporting, 12.5% of the total breach costs are added.

Only Passive Response in Phase 1
If there was NO active response in Phase 1, but the product showcased passive response capabilities in Phase 1, then only 12.5% of the total breach cost was added for the scenario.

Active Response in Phase 2
If there was active response in Phase 2, then 25% of the total breach cost was added for the scenario. In case of a silent block without reporting, 35% of the total breach costs are added.

Only Passive Response in Phase 2
If there was NO active response in Phase 2, but the product showcased passive response capabilities in Phase 2, then 50% of the total breach cost was added for the scenario.

Active Response in Phase 3
If there was active response in Phase 3, then 75% of the total breach cost was added for the scenario. In case of a silent block without reporting, 85% of the total breach costs are added.

Only Passive Response in Phase 3
If there was NO active response in Phase 3, but the product showcased passive response capabilities in Phase 3, then 95% of the total breach cost was added for the scenario.

No Active or Passive Response in any of the three Phases / Full Breach
If there was NO active or passive response for the scenario, then 100% of the total breach cost was added for the scenario.

To calculate the X-axis in the EPR CyberRisk Quadrant, we used the list price of the product, operational accuracy (such as false positives/over-blocking/over-reporting) costs, workflow-delay costs, and the breach- cost savings. Scores shown on the X axis of the Quadrant are calculated as follows. For active response, we take the cumulative response scores for phases 1, 2 and 3, and find the average of these. We then do the same with the cumulative passive response scores for phases 1, 2 and 3. Finally, we take the average of these two scores to provide the overall response score. We are steadfast in our commitment to ensuring the utmost relevance of the metrics used in this evaluation. We considered feedback from enterprises, and took this into account where appropriate. This iterative approach ensures that our assessment process continually adapts to the ever-changing enterprise landscape. EPR systems aim to prevent threats where this is possible, or provide effective detection/response capabilities where it isn’t. Endpoint products that offer a high prevention rate incur fewer costs, since there is no operational overhead required to respond to and remediate the effects of an attack. Furthermore, EPR products that provide a high detection rate (visibility and forensic detail) will realize savings, because the product provides the information needed to investigate the attack.

Active Response (Prevention): An active response stops the attack automatically, and reports it.

Passive Response (Detection): A passive response does not stop the attack, but reports suspicious activity.

Product costs are based on list prices in USD provided by vendors at the time of testing (summer 2025). The actual cost to end users might be lower, depending on different factors. In general, pricing may vary based on factors like volume discounts, negotiated discounts, geographic location, distribution channel, and partner margins.

The EPR Cost incorporates the product costs for 5,000 clients, based on a 5-year contract.

Total EPR Cost Structure

Please note that each product has its own particular features and advantages. We suggest that readers consider each product in detail, rather than looking at these list prices alone. Some products might have additional / different features and services that make them particularly suitable for some organisations.

Operational-Accuracy and Workflow-Delay Costs

Costs arising from imperfect operational accuracy and workflow delays are calculated as follows.

Costs arising from imperfect operational accuracy

Operational accuracy testing was performed by simulating a typical user activity in the enterprise environment. This included opening clean files of different types (such as executables, scripts, documents with macros) and browsing to different clean websites. Furthermore, different administrator-friendly tools and scripts were also executed in the test environment to ensure that productivity was not affected by the respective product configuration used for the test. To assess operational accuracy, each product is tested with a battery of clean scenarios. Over-blocking or over-reporting of such scenarios means that a product reaches high prevention and detection rates, but also causes increased costs. Where legitimate programs/actions are blocked, the system administrator will have to investigate, restore/reactivate any blocked programs etc, and take steps to prevent it happening again. The principle of “The boy who cried wolf” may also apply; the greater the number of false alerts, the more difficult it becomes to recognise a genuine alert.

Products are then assigned to one of five Groups (None, Low, Moderate, High, and Very High, whereby lower is better), according to the number of affected scenarios. These are shown in the table below.

Multiplying factors for Operational Accuracy costs

The costs arising from imperfect Operational Accuracy are worked out using Cost Units of USD 1.76 million. The number of Cost Units a product is deemed to have caused is calculated using a Multiplying Factor. This varies according to the Group, and also whether the scenario was affected by an Active Response (action blocked), or by a Passive Response (action not blocked, but detection alert shown in the console). The Multiplying Factor for an erroneous Passive Response is always three-quarters of that of an erroneous Active Response, because less time and effort is required to resolve the problem.

How this works in practice is best explained by looking at the table above. Products in the “None” Group have a Multiplying Factor of 0 for both Active and Passive Responses, therefore Operational Accuracy costs are zero. Products in the “Low” Group (1 affected scenario) have a Multiplying Factor of 1 for erroneous Active Responses, but only 0.75 for an erroneous Passive Response. Hence, a product with one erroneous Active Response incurs one Cost Unit, while a product with one erroneous Passive Responses only incurs 0.75 Cost Units. If a product had 2 affected scenarios, one being an Active Response, the other a Passive Response, it would incur 8.75 Cost Units (5 for the Active Response, and 3.75 for the Passive Response).

Products that exhibit significant bugs or malfunctions during testing incur an additional penalty factor of 12. We are pleased to report that no such issues were observed in this year’s test.

Costs arising from workflow delays

Some EPR products will cause delays in the user’s workflow because they e.g. stop the execution of a previously unknown file and send it to the vendor’s online sandbox for further analysis. Due to this behaviour, execution is stalled, and the user is not able to proceed till the analysis comes back from the sandbox. We noted the delay caused by such analysis, for both scenarios (clean and malicious). Where a product caused significant delays when analysing a scenario, this was penalised. The analysis time for each product was calculated as follows. For clean scenarios, we took the longest observed delay for any one scenario. So, for example, a product with two delays – of 2 minutes and 10 minutes respectively – for clean scenarios would have a recorded time of 10 minutes. For malicious scenarios, we took the average of all the delays. So, a product with two delays – of 2 minutes and 10 minutes respectively – for malicious scenarios, would have a recorded time of 6 minutes. Products are then assigned to one of five Workflow Delay Groups (None, Low, Moderate, High and Very High), depending on how long the respective delay is. These are shown in the table below.

Multiplying factors for Workflow Delay costs

The costs of these delays are calculated using the same Cost Units as for operational accuracy. Again, there is a multiplying factor, which varies according to the Workflow Delay Group. Products in the Low Workflow Delay Group have a Multiplying Factor of 0.5, hence incurring costs of 1 Cost Unit; products in the Very High Workflow Delay Group have a Multiplying Factor of 10, thus incurring costs of 10 Cost Units. Products in the latter category would be disqualified from certification, due to the excessive costs incurred.

Results
The costs arising from imperfect Operational Accuracy and Workflow Delays are shown below:

Combined results table for Operational Accuracy and Workflow Delays

In this section, we provide an overview of the products’ features and some of the associated services provided by their respective vendors. Please note that in each case, these refer only to the specific product, tier and configuration used in our test. A different product/tier from the same vendor may have a different feature set. On the following pages we describe the General features, Product Response, Management and Reporting, IOC Integration features, Support features, Support features and then provide a feature list showing which products support these features.

General features

This section looks at general features such as phishing protection, web access control, device control, interface languages, and supported operating systems.

Central Management and Reporting

Management workflow is a top differentiator for enterprise security products. If a product is difficult to manage, it will not be used efficiently. The intuitiveness of a product’s management interface is a good determiner of how useful the product will be. Minutes saved per activity can translate into days and even weeks over the course of a year.

Product Response Mechanism

EPR products will use their response mechanisms to deal with the intrusions that have occurred inside the protected environment. At a minimum, an EPR product is expected to allow the correlation of endpoints, processes and network communications, as well as the correlation of external IOCs with the internal environment. EDR capabilities were tested and examined by using the detection and response capabilities of the product. We were able to examine the events that correlated with the various steps that attacker took while attempting to breach the environment.

The EPR product should enable complete visibility of the malicious artifacts/operations that make up the attack chain, making any response-based activities easy to complete. This means that where any form of intended remediation mechanism is available in the product (Response Enablement), this mechanism is shown below. Please note that the capabilities shown below only apply to the specific product/version used in this test. A vendor might offer additional features as an add-on or in another product.

Management: Threat Visibility, System Visibility, and Data Sharing

The ability to provide threat context is a key component of an EPR product. This visibility can be critical when organizations are deciding whether to either supplement an existing technology or replace it. The management console can be deployed as physical appliance, virtual appliance, or cloud-based appliance. A full trail of audit logs is available in the management console. Communication between the agent and management console is done via SSL. The following tables provide information on the applicable capabilities of each of the tested products.

EPR Product Reporting Capabilities

An EPR platform should have the ability to unify data, that is to say, bring together information from disparate sources, and present it all within its own UI as a coherent picture of the situation. Technical integration with the operating system and third-party applications (Syslog, SIEM or via API) is an important part of this. An EPR system should be able to offer response options appropriate to the organization.

IOC Integration: This is to identify the digital footprint by means of which the malicious activity on an endpoint/network can be identified. We will examine this use case by looking at the EPR product’s ability to use external IOCs including Yara signatures or threat intelligence feeds etc. as shown in the table below.

Support features

Free, basic human support for deployment: This means real-time communication with a member of the support staff, who will talk you through the deployment process and can provide immediate answers to any basic questions you have. Of course, many vendors will provide user manuals, videos and premium (paid-for) deployment support services instead/in addition.

Professionally assisted training: This includes any form of interactive training with an instructor. A few vendors include professional training as part of the license fee paid for 5,000 clients, while others charge additionally for it. Some other vendors might only offer videos and other online material for self-training.

In the dynamic field of cybersecurity, IT security professionals need a deep understanding of antivirus (AV/EPP) and endpoint detection and response (EDR) systems, which are crucial for comprehensive defence strategies. One key aspect is understanding how different AV and EDR systems implement essential technologies. The following information offers a high-level overview of these technologies, highlighting their importance in the ever-changing cybersecurity landscape. These technologies encompass the Anti-Malware Scan Interface (AMSI), User-Mode Hooking, Callbacks, and Kernel Drivers.

1. Antimalware Scan Interface (AMSI): AMSI in Windows is an API set designed for enhanced malware detection. Integrated into components such as PowerShell, Windows Script Host, and .NET, it intercepts scripts post-deobfuscation at runtime. AMSI communicates directly with the system’s antimalware solution, forwarding content for analysis. As an interface, it’s agnostic to the specific antimalware vendor. Its integration ensures real-time threat detection, even for dynamically executed content.
2. User-Mode Hooking: User-mode hooking intercepts function calls in application-level processes in Windows. By overwriting a function’s start, calls are redirected to a custom function. For instance, an EDR might hook CreateFileW in kernel32.dll, redirecting it to its own DLL. When an application uses CreateFileW, it’s first processed by the EDR’s function, allowing real-time monitoring or restrictions before proceeding with the original call.
3. Kernel Callbacks: EPP/EDR solutions leverage kernel callback routines for deep system monitoring. These routines notify registered callbacks when specific OS events occur. By tapping into these events, EPPs/EDRs observe real-time system behaviour. For instance, an EPP/EDR might monitor process creation events. When a new process starts, the callback inspects its details and origin. This allows the EPP/EDR to quickly detect, assess, and respond to potential threats.
4. Kernel Drivers: EPP/EDR solutions employ kernel drivers to deeply integrate with the operating system for advanced threat mitigation. Minifilter drivers, part of the Windows Filter Manager, allow EPP/EDR tools to monitor, modify, or block operations on files and data streams. This is crucial for real-time scanning and access restrictions. ELAM (Early Launch Anti-Malware) drivers, on the other hand, start early during the boot process, ensuring that only legitimate, signed drivers are loaded, thereby preventing rootkits or bootkits from compromising the system. Collectively, these drivers ensure comprehensive protection from boot-up to system operation.

This information equips IT security professionals with valuable insights for making informed decisions about cybersecurity solutions. Whether you need a comprehensive understanding or a quick reference, these insights empower you to navigate the complex world of IT security effectively.

It’s important to note that these are just some of the technologies employed in modern cybersecurity, and others may also be included in the arsenal of IT security professionals. The absence or presence of a certain technology does not necessarily mean that a product is worse or better. The effectiveness of a cybersecurity strategy depends on its holistic approach and adaptability to evolving threats. The listed data was verified and provided by the vendors.

In business environments, and with business products in general, it is usual for products to be configured by the system administrator, in accordance with vendor’s guidelines. Therefore, we asked vendors to request us to implement any changes they wanted to the default configuration of their respective products. Results presented in this test were only accomplished by applying the respective product configurations as described here.

The configurations were applied together with the engineers of the respective vendors during setup. This configuration is typical in enterprises, which have their own teams of security staff looking after their defences. It is common for products of this kind that vendor experts assist companies on the deployment and configuration best suited for the type of enterprise.

Below we have listed relevant non-default settings (i.e. settings used by the vendor for this test).

Bitdefender: “Advanced Threat Control”, “Advanced Anti-Exploit”, “Firewall”, “Network Content Control”, “Network Attack Defense”, “Kernel-API Monitoring”  and “EDR Sensor” were enabled. “Scan mode” was set to “Local Scan”. “Relay Servers” and “Default Update Servers” were deleted. “Update Ring” was set to “Fast Ring”. “On-access Scanning” for archives bigger than 100MB was enabled with depth 16. “AMSI” setting and “Report analysis results to AMSI” were enabled. “Ransomware Mitigation” and “Email Traffic Scan” were activated. “HyperDetect” was enabled and set to “Block” (for network) and to “Disinfect” (for files). “Protection Level” was set to “Normal” for all settings on “HyperDetect”. “Scan SSL” and “Sandbox Analyzer” were enabled and set to “Monitoring”. In the “Network Protection” section, additional process were added for the “Intercept Encrypted Traffic”, namely “wscript.exe”,”cscript.exe”   “powershell.exe”, and “pwsh.exe”.

Check Point: In “Web & Files Protection” and “Behavioural Protection” everything was set on “Prevent”. In the “Advanced Settings”, “File remediation” was set to “Quarantine” and “Terminate”. “Anti-Exploit Mode” was set to “Prevent”. In “Analysis & Remediation”, the “Protection mode” was set to “Always”, “Enable Threat Hunting” was set to “On”, and “Attack Remediation” was set to “Medium & High”. All settings were set to “Connected Mode”.

CrowdStrike: Everything enabled and set to maximum, i.e. “Extra Aggressive”. “On Write Script File Visibility” and “Unknown detection-related executable analysis” enabled. “On-demand Scans” and “Unknown executables analysis” enabled. “Early adopter sensor builds” enabled. “Redacted HTTP detection details” disabled. “Extended user mode data visibility” set to “Aggressive”. “Identity Protection” was enabled; In “Next-Gen SIEM” a workflow was created to contain devices and add them to watchlist when the identity was compromised with the “Severity” greater than or equal to “Low”. “Authentication traffic inspection” was enabled.

Elastic: MalwareScore (“windows.advanced.malware.threshold”) set to “aggressive”. 

ESET: All “Real-Time & Machine Learning Protection”, “Potentially Unwanted Applications”, “Potentially Unsafe Applications” and “Suspicious Applications” settings were set to “Aggressive”. “Runtime packers” and “Advanced heuristics” enabled for “ThreatSense”. In “Cloud-based Protection”, “LiveGuard”, “LiveGrid Feedback System” and “LiveGrid Reputation System” were set to “On”. The “Detection threshold” for “LiveGuard” was set to “Suspicious”, the “Proactive protection” was set to “Block execution until receiving the analysis result” and the “Maximum wait time for the analysis result” was set to “5 min”. “Automatic submission of suspicious samples” enabled for all file types. In “ESET Inspect”, all detection rules and exclusions were enabled, except the “optional” ones.

Fortinet: “Execution Prevention”, “Exfiltration Prevention”, “Ransomware Prevention” were enabled and everything set to “Block”, with exception of “Sandbox Analysis”, “Unconfirmed File Detected”, “Debugged Process”, “Networks Scanning Attempt Detected”, “Partially Mapped”, “Protected System Configuration”, and “Stack Tampering”, which were set to “Log”. “Default Playbook” was enabled.

G Data: “BEAST Behavior Monitoring” set to “Halt program and move to quarantine”. “G DATA WebProtection” add-on installed and activated. “Malware Information Initiative” enabled.

Kaspersky: “Kaspersky Security Network (KSN)” was enabled. “Adaptive Anomaly Control” was disabled. The sandbox feature was not enabled.

Palo Alto Networks:  Under “Agent settings”, “On-Write File Examination” was enabled. Under “Malware Profile”, “Portable Executable and DLL examination”, “Behavioural Threat Protection” and “Ransomware Protection” were set to “Quarantine”. “Treat Grayware as Malware” was enabled. “PowerShell Script Files”, “VB Scripts Examination”, “ASP & ASPX Files” were set to “Block”.

VIPRE: “IDS” enabled and set to “Block With Notify”. “Firewall” enabled. “AMSI” enabled and set to “Block and disinfect”. “Incompatible Software Handling” disabled.

Vendor A – B: Non-default settings were used.

Endpoint Prevention Response vs MITRE ATT&CK Framework

This EPR product report is a comprehensive validation of features, product efficacy and other relevant metrics to guide your risk assessment. A total of 50 scenarios were executed against real-world enterprise use-cases. These scenarios comprised several prevention and detection workflows operating under normal operational environments by different user personas. The results for the validation can be efficiently and effectively mapped to the MITRE ATT&CK® Platform (© 2015-2025, The MITRE Corporation. MITRE ATT&CK and ATT&CK are registered trademarks of The MITRE Corporation.) and NIST platform, so that it becomes easier to operationalize the risk regarding a specific endpoint.

Enterprise EPR Workflow Overview

AV-Comparatives has developed an industry-changing paradigm shift by defining a real-world EPR methodology reflecting the everyday reality of enterprise use cases and workflows to be used for mapping the kill-chain visibility to the MITRE ATT&CK framework.

As illustrated in the graphic on the next page, we moved away from “atomic” testing, i.e. tests that only look at a particular component of the ATT&CK framework, and instead evaluated the EPR products from the context of the entire attack kill-chain, with workflows interconnecting at every stage from the initial execution to final data exfiltration/sabotage.

Please refer to the following article to learn about the differences between the AV-Comparatives EPR Test and the MITRE ATT&CK Engenuity Test.

EPR Testing Workflow

The graphic below provides a simplified overview of the test procedure used:

Enterprise EPR Workflow Overview

Prevention (Active Response)

The best way to respond to any threat is by preventing and effectively reporting on it as soon as possible. AV-Comparatives defines prevention as an automated, active response that kicks in 24/7, 365 days a year, without the need for human intervention, but with quantifiable metrics and reporting data points that can be leveraged for effective analysis.

An EPR product should be able to initially identify and prevent a threat on a compromised machine. The incident should be detected, identified, correlated, and remediated from a single pane of glass (centralized management system) through an effective passive response strategy (partially/fully automated) ideally in real time. Furthermore, the system administrator should be able classify and triage a threat based on the data collection and analysis, and be able to close out a response using the EPR product with a specific workflow.

An active response, as defined in this test, is an effective response strategy that provides detection with effective prevention and reporting capabilities. This should all be done in an automated way with no manual intervention. This can be done through a multitude of technologies and mechanisms, for example: signature-based models, behaviour-based models, ML-based models, transaction rollbacks, isolation-based mechanisms, and so forth. This definition is technology-agnostic because it focuses on the outcomes of the various system-administrator workflows and scenarios, and not on the technology used to prevent, detect or respond to it.

Detection (Passive Response)

Passive response, as defined in this test, is a set of response mechanisms offered by the product with cohesive detection, correlation, reporting and actionable capabilities. Once an attacker is already inside the enterprise environment, traditional response mechanisms kick in, for example IOC and IOA correlation, external threat intel and hunting. AV-Comparatives defines these response mechanisms as Passive Response. The precondition for passive response is the detection of a potential threat by EPR products.

EPR products are typically expected to prevent initial and ongoing attacks without having to triage, while offering active response and reporting capabilities. If the attack is missed or not prevented, EPR products should then be able to assess and respond to attacks, thus providing lesser burden on resources (human/automation) and providing better ROI in the long run.

The range of available response capabilities of an EPR product is extremely important for organizations that need to review threats/compromises in multiple machines across multiple locations. An EPR product should be able to query for specific threats using the intelligence data provided to the system administrator. Once they have been identified, the system administrator should be able to use the EPR product to initiate responses based on the type of infection. AV-Comparatives expects EPR products to have non-automated or semi-automated passive response mechanisms.

Correlation of Process, Endpoint and Network

The EPR product should be able to identify and respond to threats in one or more of the following ways:

EPR Validation Overview

AV-Comparatives have come up with the following topology and metrics to accurately assess the capabilities of endpoint prevention and response (EPR) products.

Enterprise EPR Workflow Overview

All the tested vendors’ EPR products were deployed and evaluated in a standalone mode, with each vendor actively involved in the initial setup, configuration, and baselining aspects. AV-Comparatives evaluated a list of 50 scenarios, as often requested by analysts and enterprises, highlighting several enterprise-centric use cases. Every vendor was allowed to configure their own product, to the same extent that organizations are able to do when deploying it in their infrastructure. The details of the configurations are included at the beginning of this report.

Because this methodology is tailored towards the prevention, detection and response capabilities, all vendors activated their prevention and protection capabilities (ability to block), along with detection and response, so that they emulate the real-world enterprise-class capabilities of these products.

The testing supported EPR product updates and configuration changes made by cloud management console or local area network server. We went through and executed all test scenarios from beginning to end, to the greatest extent possible.

Test Objective

The following assessment was made to validate if the EPR endpoint security product was able to react appropriately to each scenario.

1. In which attack phase did the prevention/detection occur? Phase 1 (Endpoint Compromise and Foothold), Phase 2 (Internal Propagation) or Phase 3 (Asset Breach)?
2. Did the EPR product provide us with the appropriate threat classification and threat triage, and demonstrate an accurate threat timeline of the attacks with relevant endpoint and user data?
3. Did the EPR product incur any additional costs due to imperfect Operational Accuracy or workflow delays?

Targeted Use-Cases

The sequence of events emulated was an enterprise-based scenario where in the system-level user received a file in an email attachment and executed it. In some cases, the emails were benign, while in others they were not. The malicious email attachments, if successfully executed, allowed an attacker to get a foothold inside the environment and take additional steps to act upon their objectives.

During testing, we logged into the EPR product management and the individual test system consoles, to observe, analyse and document what kind of activity is recorded by the product. For instance, if there is an attack, are there any alerts or events, and are these true positives or true negatives?

For true positive alerts, we further investigated whether the subsequent response in terms of event correlation, triages, threat classification and threat timeline were provided to the system administrator in a timely and clear way. We tested the responses as available by products under the test.

The test was conducted in summer 2025, and used an attacker-driven mindset as the attack progressed through the attack nodes to finally meet its objective. User activities were simulated throughout the test such that they were as close to a real-life environment as possible.

All the attacks were crafted using open-source and commercial tools/frameworks, and were developed using in-house expertise. The reason why we included commercial C2 frameworks is that these are frequently misused by attackers in real-life APTs; not using them would cause a „blind spot“ and lead to a false sense of security. Due to license agreement restrictions, we took measures to prevent samples created by commercial C2 frameworks from being distributed to the EPR vendors. These restrictions are made to prevent vendors from focussing on the tools instead of the techniques.

To illustrate the test procedure, we provide below an example of how a typical targeted attack might work. The attacker sends a script payload (containing some defence evasion techniques such as DLL sideloading) via a phishing mail to Network User A on Workstation A. After getting a foothold in the targeted network with the User Account A, internal discovery is performed. This involves enumerating user privileges, user groups, installed security products etc. Through this process it can be seen that the compromised User Account A has access to the C$ share on Workstation B, meaning that the account has local admin privileges on this workstation. With the knowledge gained from internal discovery, the attacker moves laterally from Workstation A to Workstation B. They then continue with internal discovery on Workstation B. This enables them to find a network administrator’s open user session on Workstation B. To take advantage of this, the attacker dumps the LSASS process, and is thus able to steal the administrator’s credentials. After doing this, they discover that the compromised administrator account has access to Server 1. The attacker then uses this compromised admin account to move laterally from Workstation B to Server 1, and then compromise this server. Here they perform further internal discovery, and also use some defence evasion techniques to bypass the installed security product (e.g. by patching AMSI and ETW). At the end of this procedure, they are able to identify credit-card data on Server 1, which they extract via an open C2 channel.