A silent scan is not a clean scan

A vulnerability report with no findings for a host means one of two things: the host is in good shape, or the scanner could not see it. Most reports do not say which. Absence of findings is not evidence of absence. A clean result needs proof that the scan could see.

I’ve run vulnerability management for organizations in healthcare, defense, government, financial services, manufacturing, retail and technology. The results that worried me most were not the critical findings; those get tickets, owners and deadlines. They were the hosts that went quiet.

A host rarely goes quiet by dropping to zero. The common case is a credential that worked last month and doesn’t now: a rotated password, a locked service account, a changed local policy. The scanner still finds what it can see from the network, so the host never looks empty. What happens to the findings it recorded while it could log in depends on the tool. In my experience they usually stay open: Tenable, for example, marks a local-check finding mitigated only after another successfully authenticated scan. New local vulnerabilities never appear. The host’s numbers freeze, and a frozen host looks stable.

That cuts both ways. To the security team it reads as good news: nothing new this cycle. To the team doing the patching it’s worse. They fix things, the report doesn’t move, and they stop trusting the scan team. In a large organization, with many analysts watching remediation, someone usually notices within a week or two. In a small one, with few people tracking every host, it can run for months.

Some tools fail the other way. Qualys documents that when a vulnerability is active and, in the next scan, “access to the relevant registry entry is either unavailable or blocked, the QID is marked as fixed” (docs). That is a fix nobody made. Qualys points to information-gathered QIDs 34011 (firewall detected), 42432 (possible scan interference) and 90195 (registry key access denied) to diagnose it. I’ve seen this false fix, and among the tools covered here only Qualys documents this behaviour. Nexpose, in my experience, and Tenable’s platforms, per their documentation, won’t mark anything fixed that they couldn’t re-verify. Which failure you get depends on the scanner you run. Frozen or falsely fixed, the report has stopped describing the host, and only the authentication, privilege and scan-interference records tell you which.

This guide covers eight ways scans fail quietly: what each looks like, why the report still looks clean, and how to detect it in Tenable (Nessus, Tenable Vulnerability Management), Rapid7 InsightVM and Qualys output. Then a one-page taxonomy of “not assessed”, what to demand from any tool or vendor, and what to do on Monday. Vendor details come from each vendor’s public documentation as of 2026-10, linked inline; check them against your own version.

Why a failed scan looks like a good one

Scan reports are built around findings, and a finding is a positive statement: this host has this problem. When a scan cannot log in, times out or never reaches a host, there is usually nothing to report, so the failure shows up as an absence. Finding counts, severity totals and SLA charts treat “nothing found” and “nothing looked at” the same way.

The scanners do record the failures. All three vendors produce status data saying whether a host was assessed and with what access. It sits in informational results, appendices and separate reports that are usually filtered out. Detection is mostly a matter of putting those records back in front of you.

1. Credential fallback

What it looks like. The policy has credentials and the scan completes. For some hosts the login failed (a rotated password, a locked service account, a host firewall blocking SSH) and the scanner carried on with network-only checks.

Why the report looks clean. A network-only scan of a well-firewalled server finds little: some open ports, a certificate, a banner. On a host that has never authenticated, missing-patch findings never appear at all. On a host that used to authenticate, the old patch findings either stay open, because there’s no authenticated result to prove them fixed, or, in Qualys’s documented registry case, get marked fixed because the check couldn’t reach what it needed (see the start of this guide). Nothing new is added. Either way the count stops reflecting the host. A host that is new in the scope looks clean; a host that dropped out of authentication looks unchanged.

The fix is a credential report that you actually read: the overall authentication success rate, and the list of hosts that flipped from success to failure since the last cycle.

How to detect it.

• Tenable reports authentication status per protocol in dedicated plugins: 104410 “Target Credential Status by Authentication Protocol - Failure for Provided Credentials”, 110723 “… - No Credentials Provided” (a login service was found but the policy had no credentials for it) and 141118 “… - Valid Credentials Provided”. 21745 “OS Security Patch Assessment Failed” fires when “the credentials supplied in the scan policy did not allow Nessus to log into it or some other problem occurred”; 117887 “OS Security Patch Assessment Available” is the positive signal. Plugin 19506 “Nessus Scan Information” also states per host whether credentialed checks were possible. Status is per protocol: success over SSH says nothing about SMB.
• Rapid7 InsightVM. The reporting data model has a per-asset, per-scan dim_aggregated_credential_status with values for no credentials supplied, all failed, partial success and all successful, plus a per-service dim_credential_status for SNMP, SSH, Telnet and CIFS. Rapid7 documents the aggregated status on fact_asset and fact_asset_scan, so it is one SQL query export away.
• Qualys returns authentication status as information-gathered QIDs (list): 105015 “Windows Authentication Failed”, 105053 “Unix Authentication Failed”, 105296/105297 “Windows/Unix Authentication Not Attempted”, and 70028 “Windows Authentication Method” and 38307 “Unix Authentication Method” when authentication was performed. Hosts that fail authentication appear in the Appendix of the scan results, and the Authentication Report rolls status up per host as Passed, Failed or Not Attempted.

The test. For every host you intend to authenticate, require evidence in the latest scan that the patch inventory actually ran, not just that a login worked: Tenable 117887 (141118 alone proves only a login); InsightVM “all credentials successful” with elevation or root (SSH) or local admin (CIFS) where the platform needs it, plus a populated software inventory for the asset; Qualys 70028/38307 plus a complete installed-software list. A missing marker is a failure, even when no failure marker appears.

2. Partial access

What it looks like. Authentication succeeded, so “did we log in” dashboards are green. But the account lacked privileges for every check, or some commands failed, so the package or patch inventory is incomplete.

Why the report looks clean. The host has some authenticated findings, so it does not look like a network-only scan. Nobody notices they cover only part of the installed software.

How to detect it.

• Tenable. 110385 “Insufficient Privilege”: the login worked but the credentials “were not sufficiently privileged to complete all requested checks”. 24786 “Nessus Windows Scan Not Performed with Admin Privileges”: the scan “may be incomplete”, and Tenable explains that registry-based fallback can produce false positives and false negatives. 117885 flags intermittent authentication failure (for example, session limits). Check that software enumeration ran: 22869 and 97993 over SSH, 20811 on Windows.
• Rapid7 InsightVM. The per-service status separates “Login Successful” from “Allowed elevation of privileges” (SSH), “Root” (SSH, Telnet) and “Login as local admin” (CIFS) (data model). An SSH login that never reaches elevation or root on a Linux host is a partial-access signal.
• Qualys. The Authentication Report’s “Passed*” (insufficient privileges) status is documented as applying only to Policy Compliance. For vulnerability scans, compare the host’s recorded installed software with what you know it runs.

The test. Quarterly, pick ten authenticated hosts (or all of them if you have fewer), covering every OS family and credential or scan policy you use, and compare the package list the scanner recorded with a listing taken on the host. A short list, or a missing package manager, is the signal.

I see this often, mostly on Windows but on Unix and macOS too. On Windows the usual causes are LocalAccountTokenFilterPolicy not set to 1, so remote logins with a local administrator account typically get a filtered token without admin rights (Microsoft), or a WMI service that is stopped or blocked. On Unix the scanner often logs in as a standard user and can’t escalate to root, so it runs only part of the checks. Either way the scanner may report the login as a success. The success that counts is a login with administrative or root privileges. Changes to the account or to services on the host itself usually have no change ticket, so nobody connects them to the scan. The result is that vulnerabilities you expect to see don’t show up, and most teams don’t find out unless they go looking.

3. Unsupported OS streams and versions

What it looks like. The login worked, but the scanner has no patch checks for that OS, version or stream: a new major release, an extended-support stream, an appliance OS, a niche distribution.

Why the report looks clean. Credential dashboards are green, and no patch checks ran, so there are no patch findings.

How to detect it.

• Tenable has a plugin for this: 110695 “OS Security Patch Assessment Checks Not Supported” (“the credentials … may have been successful, but OS Security Patch Assessment cannot be performed”). 117886 “OS Security Patch Assessment Not Available” covers non-failure reasons such as unsupported or unidentified targets. Do not confuse these with 33850 “Unix Operating System Unsupported Version Detection”, a real finding that the OS vendor no longer ships patches. 110695 is about the scanner not covering the OS.
• InsightVM and Qualys both run patch checks on authenticated scans, but I have not found a documented status in either that flags ‘logged in, but no patch checks exist for this OS’ the way 110695 does. Group authenticated hosts by detected OS and version and look for groups with successful logins and zero OS patch findings; then ask the vendor whether they support that stream.

The test. Treat any OS group with full authentication success and no OS patch findings as suspect until the vendor confirms support.

4. Per-host timeouts

What it looks like. A host is slow, rate-limits the scanner or has a huge file system. The scanner hits a per-host limit and moves on.

Why the report looks clean. Depending on tool and setting, the host gets no results or partial ones, and “no results” reads as “nothing found”.

How to detect it.

• Nessus. “Max scan time per host” is disabled by default; when set and reached, “No scan results are produced for the target that timed out” (docs). The same page documents the 5-second default network timeout and per-plugin command timeouts (the Unix find command defaults to 240 seconds). Plugin 19506 reports scan duration per host; trend it.
• InsightVM offers a per-device maximum scan duration, and Rapid7’s own page advises against it: it “obscures visibility to legitimate scanning obstacles” and may lead to “false negatives and therefore a false sense of confidence in results.”
• Qualys. When the maximum scan duration per asset is reached, “the scan on the asset will be aborted”, the host is listed under “Hosts Exceeded Duration”, and “you will not have scan results” for it (docs).

The test. Know whether a per-host limit is set in each tool. If it is, pull the hosts that hit it after every scan and count them as not assessed.

5. Scan-window truncation

What it looks like. The scan has a window. When it closes, the scan stops and the remaining targets are never reached.

Why the report looks clean. The scan shows as finished or stopped by schedule. Reached hosts report normally; the rest keep old results, or none.

How to detect it.

• Tenable. Tenable Vulnerability Management creates a rollover scan when a scan ends early, including when it “times out due to the Scan Window setting”; the rollover covers only unscanned targets (docs). In Tenable Security Center, the “Scan Timeout Action” default imports results and creates a rollover; another option “discards the information for the unscanned hosts” (docs). An unlaunched rollover is a list of hosts not assessed.
• InsightVM. Scheduled scans that exceed their maximum duration “will be paused”, per Rapid7’s API client documentation. Check for paused and stopped scans, not just failed ones.
• Qualys. The Appendix lists hosts not scanned because the scan was paused or cancelled, including “automatically by the service as specified in scheduled scan settings” (docs).

The test. Every run, compare targets scanned with targets in scope. A scan that finishes exactly at the end of its window probably did not finish.

6. Assets dropping out of scope

What it looks like. Coverage drifts rather than breaks: a new subnet never added to a target list, a tag rule that stops matching after a naming change, a “temporary” exclusion, old records aged out.

Why the report looks clean. Coverage metrics often divide by the assets the tool knows about. An asset that leaves the inventory leaves numerator and denominator together, and the percentage holds or improves.

How to detect it.

• Tenable Vulnerability Management. Asset Age Out is on by default at 180 days (range 14–450): host assets “not seen on a scan” that long are permanently deleted with their vulnerabilities (docs).
• Qualys. In Qualys CSAM, purge rules can delete assets automatically, including a default rule for scan-based assets older than 90 days; the defaults are disabled until someone enables them (docs). Check whether someone did. The Appendix also lists excluded hosts (docs).
• InsightVM. The “last scan date” filter with “earlier than” finds assets not scanned within a set number of days (docs); Rapid7 notes that dynamic group membership changes as new scans run.

Age-out and purge are sensible housekeeping. The risk is reading a coverage figure without knowing its denominator is maintained this way.

The test. Reconcile the scanner’s asset list against an independent source (CMDB, directory, cloud inventory, EDR) and report the assets the scanner does not know about.

7. Agent check-in staleness

What it looks like. Agents are installed, but some stopped reporting: a laptop off the network for a month, an agent broken by an OS upgrade, a cloned VM with a duplicate agent identity.

Why the report looks clean. The asset’s last results stay in place and look current unless you check their age. Some consoles also drop silent agents from their counts.

How to detect it.

• Rapid7 Insight Agent. “Offline” means the agent reported within 15 days but not the last 10 minutes; “stale”, not in at least 15 days. With the default 30-day retention, an agent that does not check in within that period is removed from the Agents table and “no longer affects agent metrics” (docs). The agents silent longest are the ones missing from the health figure.
• Tenable. Agent status shows online, offline and initializing (docs); Tenable Nessus Manager can unlink agents automatically after a set number of inactive days.
• Qualys Cloud Agent records “Last Checked In” and “Last Activity” per agent (docs).

The test. Report each agent-assessed asset’s last successful assessment time, and set a threshold (say, twice your assessment interval) past which it counts as not assessed, whatever its last results said.

8. Network path problems

What it looks like. The scanner cannot reach the host, or only part of it: a firewall change, an IPS dropping scanner traffic mid-scan, a host that ignores ping, a new segment never routed for the scanner.

Why the report looks clean. A host that does not answer produces no findings. A host behind a filter that passes one or two ports produces a few low-severity ones.

How to detect it.

• Tenable. Plugin 19506 reports per host the port scanner used, the port range and the ping round-trip time. A much shorter open-port list than last time is a path question before it is a hardening success.
• Rapid7 InsightVM. The aggregated credential status has a value for “None of the four applicable services (SNMP, SSH, Telnet, CIFS) was discovered in the scan” (docs). On a server you know runs SSH or SMB, that means the scanner never reached the login service; it is not an authentication result at all.
• Qualys. The Appendix lists hosts that “did not respond to probes sent by the scanning engine” when scanning dead hosts was off (docs).

The test. Track open-port counts per host across scans. A large drop with no change ticket goes to the network team before anyone calls it good news.

When a firewall change does have a change request, security is usually not on its distribution list. Either the change isn’t tracked at all, or nobody thinks to tell the scan team. Endpoint protection and IPS rollouts go the same way: someone deploys a new tool without announcing it, testing it against the scanner or following up, and nobody knows why scanning has degraded. The scans keep completing and the reports keep arriving, so it takes days or weeks before anyone realizes the results stopped meaning what they used to.

The taxonomy of “not assessed”

This section stands alone as a one-page resource.

Every host result is one of three things: assessed, with findings; assessed, clean; or not assessed. Only the first two are results. “Not assessed” needs a reason, an owner and a date, like a finding.

Two rules make the table work. The evidence is a positive record of success, not the absence of a failure record. And “not assessed” is reported next to findings, in the same report, with the same owner, so it cannot fall out of view.

What to demand from any tool or vendor

These apply to any scanner, agent or managed service, and to any consultant who hands you a report, me included.

1. Per-asset assessment status in the export: assessed or not, how (authenticated, unauthenticated, agent), and when. If it takes a hand join on an informational plugin or QID, ask for it as a field.
2. A positive success record. “No authentication failure reported” is not “authentication succeeded”.
3. A dated list of supported OS versions and streams for patch checks, and a status on the asset when it is not covered.
4. Coverage with the denominator stated: what the percentage divides by, and what removes an asset from it (age-out, purge, retention, exclusion).
5. Reasons for “not assessed”, not just a count. Unreachable, failed login, unsupported, timed out, truncated and stale have different fixes and owners.
6. Timeouts and truncation reported as events in the results, not only in a scanner log.
7. For managed services and third-party reports, the raw status records, so you can run these checks yourself.

A vendor that cannot answer these does not necessarily have a worse tool. It does mean you cannot tell a clean result from a silent one, and you should not report them as the same thing.

What to do Monday

1. Pull authentication status for the last cycle. Tenable plugins 117887, 141118, 104410, 110723, 21745, 110385, 110695; InsightVM aggregated credential status; Qualys authentication QIDs or the Authentication Report. List every host you expected to authenticate that has no success record.
2. Find the hosts that went quiet. List assets whose findings fell to zero, or by more than half (as a starting point), since the last cycle, and assets whose findings have not changed at all across several cycles while remediation tickets for them were closed. Check each against step 1 and against change tickets.
3. Write down your silent limits, per tool: per-host time limits, scan windows and what happens when they close, age-out or purge settings, agent retention and unlink settings.
4. Reconcile one inventory. Take one independent source (EDR, directory, one cloud account) and count the assets your scanner does not know about.
5. Add one line to your report: “assets not assessed this cycle”, with reasons, next to the finding totals. It will be uncomfortable the first time. That is the point.