Performance testing security software agents
A security agent runs on every customer host, so a small rise in CPU, memory or disk use in one build shows up as slower machines across the whole fleet.
Research desk, cybersecurityqavendors.com. Published 2026-11-11.
Short answer
Run one scripted workload on the same OS image twice, bare and with the agent, record host and agent-process CPU, memory, disk I/O, boot and launch times, fail any build that exceeds the agreed budget, and report any rise over the last release. Ask a QA vendor for a case with the baseline method, the budgets and a build that failed them.
What the agent costs a host
An EDR1 or EPP2 agent intercepts file opens, process starts and network connections. Each interception adds work on the host. A change to a filter driver, a scan rule or a telemetry batch size can raise that cost without changing any feature a functional test checks.
Desktop users see the cost as slow boot, slow application start and busy disks during file copies. Server owners see it as lower service throughput. Performance tests turn those complaints into a number per metric, per OS image, per build.
Measure with and without the agent
- One image, two states. Use the same OS image and the same hardware or VM size for both runs, one without the agent and one with it, so the agent is the only difference.
- Scripted workload. Script what a customer host does: logon, application launches, file copies, archive extraction, compilation and browser sessions on desktops, and the service load on servers.
- Metrics. Record CPU, memory, disk I/O, boot time and application launch time for the whole host and for the agent's own processes.
- Repeated runs. Repeat each run several times and report the spread, because results on a VM vary with load on the physical host.
- Clean state. Restore the image from a snapshot before each run, so caches and update downloads from the previous run do not carry over.
- First run and steady state. Measure a first-run pass, which includes the initial scan, cache build and cloud lookups, and a steady-state pass after a fixed warm-up. Report the two separately.
Scan storms and shared hosts
Put a pool of virtual desktops or VMs with the agent on one hypervisor, trigger a scheduled scan and a signature update on all of them at once, and measure host-level disk queue and CPU. Each guest can look normal on its own while shared storage and CPU saturate, so the host-level numbers decide the result.
Test the agent's randomisation and offload settings in the same setup, since those settings exist to spread the load.
Other agents on the same host change the numbers too. Repeat the baseline with the agents your customers commonly run beside yours, as described in testing EDR agents across OS versions. Run the comparison on each top-tier entry of the compatibility matrix3, because a filter driver can cost more on one OS build than on another.
Budgets and reports
Before testing starts, agree with product management a limit per metric and per OS image, for example the maximum added boot time and the maximum agent memory at idle. Write the budgets into the test plan.
Compare each build with the last release, not only with the bare image. A build that stays inside the budget but uses more than the last release still goes in the report, with the commit range between the two builds.
Report per OS image: the bare baseline, the last release, the current build, the budget, and pass or fail. Keep the raw run data with the report so an engineer can rerun the comparison. Running the suite nightly in the pipeline is covered in test automation for security products.
What to ask a QA vendor
Ask for a case that names the agent type, the OS images, the workload script and the budgets, plus a build that failed one. Agent overhead work is credited as performance or load under test-type depth, dimension 3, and the OS image list can add compatibility matrix work. A published case on an EDR, EPP or DLP agent counts under evidence depth, dimension 1.
A per-build overhead trend is only useful across many releases, so ask how long the vendor ran the suite for one client: engagement longevity, dimension 4. Unreleased agent builds and debug symbols reveal how the product hooks the OS, so ask where they are stored and who can reach them: security posture, dimension 6.
How each dimension is scored is set out in the methodology. A performance testing facet would need more evidenced vendors; its count against the threshold is on not published. Overhead budgets sit beside the agent compatibility items in the security product QA checklist.
- 1 EDR: Software that watches laptops, servers and phones for suspicious behavior, records what it sees, and alerts administrators so they can investigate and respond. Source
- 2 EPP: Software installed on workstations and laptops to block attacks, typically bundling antivirus, a personal firewall and host-based intrusion prevention. Source
- 3 compatibility matrix: A grid listing the operating systems, browsers, devices and versions a product must be tested on, usually ranked by how many users each combination covers. Source
Questions buyers ask
How do you baseline agent impact on CPU, memory and disk?
Run the same scripted workload on the same OS image with and without the agent, restore the image from a snapshot before each run, and record CPU, memory, disk I/O, boot time and launch time for both. Report a first-run pass and a steady-state pass after a fixed warm-up separately.
Why compare images with and without the agent?
The bare image separates the agent's cost from the cost of the OS and the workload. Comparing builds with each other shows change, not total overhead.
What is a security agent CPU and memory overhead test?
A repeated measurement of host and agent-process CPU and memory under a scripted workload, reported as the difference from the same image without the agent.
How do you measure agent impact on desktop performance?
Script the actions a user performs, such as boot, logon, application launch, file copy and archive extraction, then time each one with and without the agent on the same image.
What is a scan storm?
Many virtual machines on one host starting a scheduled scan or update at the same moment, saturating shared disk and CPU. Test it with a pool of guests on a single hypervisor.
Should each build be compared with the bare image or the last release?
Both. The bare image shows total overhead against the budget; the last release shows what the current build changed.
What should I ask a QA vendor about agent performance testing?
Ask for a case naming the OS images, the workload, the budgets and a build that failed them, how long that engagement ran, and how agent builds and symbols were stored.