Why your EDR coverage number is probably wrong

Ask most security teams how well their endpoint detection and response (EDR) tool covers the estate and you will get a confident number, usually somewhere in the high nineties. Ask where that number comes from and the answer is almost always the same: the EDR console.

That is the problem. A console can only count the machines it knows about, and the machines it knows about are, by definition, the ones that already have an agent. The hosts it was never deployed to do not appear as "uncovered". They do not appear at all.

The denominator problem

Coverage is a fraction. The numerator (hosts with a healthy agent) is easy for a vendor to measure. The denominator (every host that should have an agent) is not something any single security tool can know.

When the denominator is "all hosts that have ever checked in", the percentage measures agent health, not agent coverage. Both are useful, but only one of them answers the question your board, your auditor or your incident responders are actually asking: is there anything out there we cannot see?

To answer that, you need a reference inventory that is independent of the tool you are measuring.

What a reference inventory looks like

A good reference inventory is assembled from sources that have different reasons to know about a machine:

• Directory services such as Active Directory or Entra ID: the "should exist" list for domain-joined devices.
• MDM and cloud platforms such as Intune or Azure: managed laptops, mobiles and virtual machines.
• Network discovery: active scans and passive traffic analysis that see whatever answers on the wire, agent or not.
• Other security tools: your vulnerability scanner, NDR and SIEM all keep their own lists, and each one has blind spots the others do not.

Correlate those sources into one record per real machine and you finally have a denominator worth dividing by.

Three ways an "installed" agent is not really covering anything

Even within the numerator, not every agent that reports in is doing its job. Three failure modes come up again and again.

1. Reduced-functionality mode

Most EDR agents fall back to a degraded state when something goes wrong: an unsupported kernel, a failed update, a conflict with another product. The agent still checks in, so the console still counts the host. But prevention, and sometimes visibility, is limited until someone notices.

2. Policy not applied

An agent can be installed, healthy and talking to the cloud while running the wrong prevention policy, or no policy at all, because it landed in a default group. On paper it is covered. In practice it may be in detect-only mode on a server that should be blocking.

3. Silent agents

Agents stop reporting for many reasons: a machine is powered off, re-imaged, cloned, or the agent has been tampered with. A host whose last check-in was three weeks ago is still "in" the console. Whether it is still in your estate is a different question, and one only an independent source can answer.

How to measure coverage properly

A defensible coverage figure takes a few deliberate steps.

1. Build the reference inventory first. Pull from directory, MDM, cloud and network discovery before you look at any security tool.
2. Correlate, do not concatenate. A laptop that appears in four sources is one asset. Matching on agent IDs, hostnames, IP addresses and FQDNs, with guards against obvious conflicts, is what turns lists into an inventory.
3. Overlay each control separately. For every asset, record whether it is seen by your EDR, your vulnerability scanner, your SIEM. Each control gets its own coverage figure.
4. Separate presence from health. "Has an agent" and "has a healthy, correctly configured agent" are different columns.
5. Define scope explicitly. Printers and IP cameras will never run an EDR agent. Mark what is in scope so the gap list is actionable rather than noisy.
6. Rank the gaps. A missing agent on a domain controller matters more than one on a meeting-room PC. Break coverage down by criticality and department, worst first.
7. Track it over time. Coverage drifts. New machines arrive, agents break, policies change. A trend line is more honest than a snapshot.

Question	Vendor console	Reference inventory
How many agents are healthy?	Yes	Yes
Which hosts have no agent at all?	No	Yes
Which agents are degraded or mis-policied?	Partly	Yes, across vendors
Which agents sit on out-of-scope machines?	No	Yes
How has coverage changed this quarter?	Sometimes	Yes

What the gap list usually contains

When teams run this exercise for the first time, the uncovered list tends to fall into a few familiar groups: servers built outside the standard image, machines from a recent acquisition, lab and test systems, virtual machines cloned from old templates, and a long tail of network devices that were never meant to run an agent but were never formally excluded either.

None of these are exotic. They are simply invisible to a tool that only counts what it already manages.

Agents on the wrong machines

Coverage has a second, quieter failure: agents installed where they should not be. Licenses consumed by decommissioned hosts, duplicates left behind by re-imaging, test machines that were never cleaned up. These inflate both cost and the apparent coverage rate. A reference inventory surfaces them too, because they show up as agents with no corresponding live asset.

The takeaway

A coverage percentage is only as good as its denominator. If the denominator comes from the tool being measured, the number tells you how healthy your agents are, not how much of your estate you can see.

Lumen Edge was built around this idea: correlate every source you already run into one inventory, then show each security control's real coverage against it, by department and criticality. If you would like to see what your own gap list looks like, book a demo and we will walk through it on your data.