Every security team has two lists that should match and don't. One is the set of devices your vulnerability scanner reports on. The other is the set of devices your endpoint protection agent reports on. Ask which assets appear on one list but not the other and most teams answer with a spreadsheet, a few days of effort, and a caveat that the numbers are already stale.

That gap is not a tooling failure. It is a data-model problem and it is solvable with one query once your assets live in a graph.

Why the two lists never match

Scanners and EDR agents answer different questions. A scanner knows what it can reach on the network and what it found there. An EDR agent knows what it was installed on. Neither knows what the other knows, and neither knows what neither one covers.

The gaps that result are ordinary and predictable:

• A server the scanner assesses every week that never got an EDR agent.
• A laptop with a healthy agent that sits outside every scan window.
• A cloud instance launched last Tuesday that appears in neither tool yet.
• The same machine under three names, one per tool, so every count is inflated and no comparison is reliable.

The last one is the quiet cause of most coverage reporting errors. You cannot compare two lists until you know which rows are the same asset.

Step one: resolve identity before you compare

JupiterOne ingests assets from each source as its own entities, then resolves matching records into a single unified device using attributes such as serial number, device ID, FQDN, hostname and IP address, each weighted by how reliably it identifies a machine. The scanner's record, the EDR agent's record, the MDM record and the cloud record for the same machine become one asset with links back to every source that reported it.

Once that is done, "which tools see this device" stops being a lookup across systems. It is a property of the asset.

Step two: ask the question in both directions

Because each source is connected to the unified device, a coverage question is a graph traversal. Devices your scanner reports that have no endpoint protection agent are one query. Devices with an agent that your scanner has never assessed are the same query with the condition reversed.

Start with the protection gap: devices your vulnerability scanner has assessed that have no record in any endpoint protection tool. Every unified device lists the sources that reported it, so this is a filter, not a join. The example uses Tenable as the scanner, with CrowdStrike and SentinelOne as the endpoint tools. Swap in your own.

FIND UnifiedDevice WITH _sourceType = 'tenable_asset'

  AND _sourceType != 'crowdstrike_host'

  AND _sourceType != 'sentinelone_host'

  AND osType = ('windows' OR 'windows-server' OR 'Windows' OR 'macos' OR 'MacOS') AS ud

RETURN ud.displayName AS device, ud.osType AS os, ud._sourceType AS sources

Then reverse it: devices your endpoint tools report that your scanner has never assessed. These are machines you defend but do not measure, so their vulnerabilities appear in no report.

FIND UnifiedDevice WITH _sourceType = 'crowdstrike_host'

  AND _sourceType != 'tenable_asset' AS ud

RETURN ud.osType AS os, count(ud) AS devices

ORDER BY devices DESC

Because the unified device keeps a list of every source that reported it, the question "which tool sees this and which does not" is a property of the asset. It does not depend on remembering which system holds which list.

Both directions matter. The first list is your protection gap. The second is your assessment gap: machines you defend but do not measure, so their vulnerabilities are invisible to every report you produce.

Step three: separate real gaps from expected ones

A raw gap list is a starting point, not a to-do list. Some devices should not have an agent: network appliances, printers, lab hardware. Some are retired and not yet decommissioned. Enrichment is what turns the list into decisions.

Two examples worth building into the same view:

• Operating system support status. A device missing from endpoint protection and running an operating system past end of life is a very different priority from a supported workstation that is a week behind on an agent rollout.
• Ownership and location. The same gap on a production server owned by a named team has a fix and an owner. On an unowned device it needs triage first.

Recency. Filter on last seen date before you hand anyone a list. Stale records of retired machines inflate every gap count, and a list that includes them loses the reader's trust at the first row they recognize as decommissioned. Add a line such as AND lastSeenOn > date.now - 30 days to the first query.

What the result looks like

In the JupiterOne demo environment, the scanner has assessed 117 Windows and macOS devices, and 2 of them have no record in CrowdStrike or SentinelOne. Both are also seen by a cloud security tool, so the gap is small and specific. The reverse query is the bigger finding: 190 of the 305 devices CrowdStrike protects, 62%, have never been assessed by the scanner. That is 120 Windows servers, 49 Windows machines and 21 Macs.

Linux servers and network appliances are left out of these numbers on purpose. Many run no endpoint agent by design, so counting them would inflate the protection gap with devices nobody expects to cover.

The demo environment uses synthetic data, so read these figures as an illustration of the method, not a benchmark. JupiterOne customers describe the same pattern in their own words. An American Financial Services Company ran several scanners whose databases did not agree with each other, and cut the time spent correlating vulnerabilities to assets by 20 times, from 2 days to about 5 minutes. Its Head of Vulnerability put the problem this way: "There's a huge problem in the industry of different products building their own databases of vulnerabilities... all of these databases don't agree with each other."

Socotra found forgotten infrastructure across more than 50 AWS environments. Its CISO, Mark Holtz, said the platform "paid for itself by saving us from having to purchase separate GRC and vulnerability management tools and easily showing us leftover AWS resources we were paying for but weren't using."

What this does not do

A coverage query is only as complete as the sources connected to it. If a scanner has no visibility into a network segment and no other integration reports on it, those assets will not appear in either list. The way to close that last gap is to add a discovery source: cloud account integrations, network discovery, identity and MDM data. Each new source makes the comparison stronger because it is one more place an asset can be seen.

Identity resolution has the same limit. A record with too little identifying data, such as a hostname alone, does not carry enough weight to be matched safely, so it stays a separate asset instead of being merged by guesswork. That is the right default, and it is a reason to feed the graph sources that carry serial numbers and device IDs.

Try it

Find your coverage gaps. Request to book a demo.