What does Lansweeper's endpoint protection data say about coverage gaps?

What did Lansweeper report?

On 7 September 2026 Lansweeper published an analysis by its data team of several million endpoints across about 30,000 organizations. It reported that 96% of endpoints had some protection, and that 68.1% ran full EDR or next-generation antivirus. Those are Lansweeper's figures from its own customer data, which we have not checked; they describe Lansweeper's population, not every organisation.

Why is the gap interesting?

Because the two numbers answer different questions. "Is this endpoint protected?" gets a reassuring yes almost everywhere. "Does this endpoint run the control our policy requires?" gets a less comfortable answer for roughly a third of endpoints in Lansweeper's data. Most security policies are written in terms of the second question, and most dashboards report the first.

How would you measure your own gap?

With a coverage question, built from three parts.

1. The population. Every endpoint you own, which no single tool knows on its own. Combine the endpoint management tool, the directory, network discovery and the CMDB, and merge the records.
2. The control. Define it precisely: a named EDR product, installed and reporting within the last seven days, in the right policy group.
3. The comparison. Devices in the population that fail the control definition. That list is your gap.

The hard part is step one. If the population comes only from the EDR console, every device in it already has the agent, and the gap looks like zero. The population has to come from sources that do not depend on the control being present.

Which approaches help?

Any approach that builds the population from more than one source. A CAASM platform reads the EDR console alongside endpoint management, identity and network sources: Axonius documents Query Wizard for questions across all connected sources, and JupiterOne describes plain-English graph queries. A discovery tool finds devices directly: Lansweeper's own three discovery systems cover the network, off-network laptops and cloud, with deduplication on MAC address, serial number and hostname.

What should you do with the result?

Sort the gap by exposure first: internet-facing and privileged devices before the rest. Route each device to the team that can install or repair the control, and track the gap count over time. A falling number is better evidence for an auditor or a board than any single snapshot. Where a device cannot take the control at all, record the exception and the compensating control, so that it stops appearing as an unexplained gap.

How often should you measure?

Often enough to see a trend, and always after a change that could move it: a new EDR rollout, a large hiring wave, an acquisition or a change of endpoint management tool. Monthly is a reasonable start for most teams; continuous is possible where the inventory refreshes on its own. Keep the definition of the control fixed between measurements, or the trend will reflect the definition rather than the estate.

Is the gap the same for servers and cloud?

Not usually. Servers and cloud workloads have their own controls and their own blind spots: short-lived cloud workloads may come and go between two scans, and servers may run agents that differ from laptops. Measure each population separately rather than blending them into one figure.

What are the traps?

• Counting duplicates. One laptop recorded under two hostnames looks like one covered and one uncovered device.
• Counting the departed. Devices retired months ago but still in the CMDB inflate the gap.
• Counting the wrong control. A device with a different product installed may meet the policy, or may not; decide in advance.

What next?

Read Coverage gaps: asking which devices lack a control, and if audits ask for this evidence, answer question 05 of the finder accordingly.