The EDR metrics that matter are healthy agent coverage, detection of behaviors you tested, time to isolate a host, and how much tuning load alerts create. Misleading ones include "threats blocked" totals, installed-agent counts and third-party test scores read as a guarantee for your environment.
EDR, endpoint detection and response, watches devices for suspicious activity, records what happened on them and lets responders contain a machine. Metrics should show whether that chain works, from the sensor on the device to the person who acts.
Metrics worth tracking
Healthy coverage against inventory. Not agents installed. Agents that checked in recently, divided by the devices that exist. NIST SP 800-53 control CM-8 describes an inventory that is accurate and complete, and that is your denominator. Break the gap down by device type, because servers and contractor laptops often hide there.
Sensor health. Count agents with disabled protections, outdated versions or long silence. A silent agent looks the same as a quiet machine unless you check.
Detection of tested behaviors. Pick a handful of common techniques from MITRE ATT&CK, a knowledge base of adversary behavior, and run harmless simulations in a controlled way on test machines. Record which were detected, which were only logged and which were missed. Repeat after product updates.
Time to isolate. From alert to host contained. Measure the human portion too: who was paged, who approved. A tool that can isolate in seconds delivers little if approval takes an afternoon.
Investigation time. How long an analyst needs to answer what happened on this host. EDR is supposed to shorten that by recording process, file and network activity. If analysts still ask for disk images, the tool is not paying off.
Actionable alert rate. The share of alerts that led to a ticket, a block or a confirmed incident. Low rates mean tuning is needed.
Exclusion list size and age. Every exclusion is a place where the sensor stays blind. Count them, record who requested each, and review them on a schedule.
Reinfection or repeat incidents. If the same host or technique returns, response stopped at cleanup.
Metrics that mislead
Threats blocked. A large number mostly reflects commodity noise. It shows activity, not the incidents that mattered.
Agents deployed. Deployment is not health. A device with an agent that stopped reporting last month counts as protected in this metric and is not.
Independent test scores. Public evaluations can be useful input. They test specific scenarios in specific configurations, so a good result does not predict how the tool performs against your applications, your exclusions and your attackers. Read the test method before quoting a score.
Dwell time quoted from industry reports. Averages from other organizations tell you little about yours. Measure your own with exercises.
Mean time to respond across all alerts. False positives dominate the average. Separate real incidents from noise.
Detections per endpoint. Depends on how noisy your software is, not how safe you are.
A constructed example
A team reports 100 percent deployment and zero missed detections in a quarter. Two checks change the picture. Sorting agents by last check-in shows that 12 percent have been silent for more than a week, mostly laptops that left the office. And the zero missed detections came from a test the vendor ran, not from the team's own simulation. When the team runs five harmless technique simulations on a test machine, three are detected, one is only logged, and one is missed because of an exclusion added for a build tool. This example is constructed for illustration.
How to report them
Keep to six or seven numbers. Show the definition and the denominator for each, and call out the worst category, not just the average. Present the simulation results as a table of techniques and outcomes, with dates.
Who should own each number?
Give every metric a named owner. Coverage and sensor health belong to the team that manages devices. Detection tests and isolation time belong to security. Exclusions need an owner on both sides, since they are often requested by engineering and approved by security. When a number moves the wrong way, the owner explains why in one sentence at the next review. A metric with no owner is decoration.
What to do
- Compute coverage from the asset inventory and count only recently reporting agents.
- Alert on agents that go silent or lose protections.
- Run a harmless simulation set after every major update and record results.
- Time isolation end to end, including approval.
- Review exclusions quarterly and remove those without an owner.
- Drop metrics nobody acts on.
Quick check
Is a high detection score in a public test enough?
No. It shows performance in that test setup. Test your own critical scenarios in your own environment.
How often should we run simulations?
At least quarterly and after product or policy changes. Keep them harmless, scoped and agreed in advance.
Sources
Last reviewed: 18 October 2026.
