Monthly vulnerability scanning: what it sees and misses

The monthly vulnerability scanning report came back clean: zero criticals, two mediums, a green chart. You forward it to management and move on. The front page does not say whether the scanner got onto the servers or only knocked on the door, which devices it skipped by default, and what has landed on attackers' lists since the day it ran.

That last point can be counted. In the past 365 days, the CISA catalogue of vulnerabilities with confirmed exploitation (KEV) gained 315 entries, roughly 26 every 30 days, by our count on the official feed of 4 November 2026. Not all of them concern you. But between two monthly scans the attackers' list moves, and your report stays exactly as you received it.

Why a clean report does not mean a clean network

A scanner reports what it managed to check. Whatever it did not check is missing from the list, and a short list looks exactly like a well-maintained network. Four concrete ways this happens:

• The scanner stayed outside. Tenable, the maker of Nessus, says an unauthenticated scan sees the network the way an outside attacker does and does not give the full picture; local checks require authentication. Nessus even has a dedicated plugin, 21745, which flags that the patch assessment did not run, for example because the credentials failed to authenticate.
• The scanner skipped devices. By default, Nessus marks printers and multifunction devices as "Dead" and skips them, because they react badly to scanning. What is skipped does not appear in the report.
• The scanner did not have the check. In a January 2024 benchmark by Pentest-Tools.com (a competing vendor with its own scanner in the test), across 128 vulnerable environments detectable remotely, without authentication and on default settings, Nessus claimed detection for 67.19% and actually identified 22.66%. That is not a production detection rate and it does not show that Nessus is weak. It shows that a signature database is not a guarantee.
• The list contains noise. Red Hat fixes by backporting without changing the version number, and tools that decide on the version number alone report false positives. The time lost on them comes out of the same team that was supposed to fix everything else.

Then there is what a scanner does not set out to see: authorisation, application logic, attack chains. We explain the difference between a scan, an audit and a pentest in a separate article.

The obvious workaround, "we will just install a free scanner", runs into licensing quickly. Nessus Essentials means up to 5 IPs, a 30-day licence, plugins delayed by 30 days and strictly non-commercial use, so it is not an option for a company (you will still find third-party pages quoting 16 IPs; Tenable's own page is what counts). Nessus Professional costs $4,790 a year on a one-year licence. OpenVAS has a free Community feed for widely used software and systems, while network equipment such as Cisco or Palo Alto appears among what the paid Enterprise feed adds. If your perimeter is on that list, check first what the free option covers.

Vulnerability scanning is a measuring instrument

The usual question is how many criticals the scanner found. The useful question is how the measurement was set up. How far you can rely on the list depends on four settings: how often you measure, where you look from, what access you go in with, and what you do between two measurements. Change the position or the access and, on the same network, you get a different list.

A clean report tells you what the scanner did not find. About your network, it tells you only as much as you let it see.

How often: the standards do not give the same number

Look for the answer in the standards and you get five answers:

• ENISA technical guidance v1.0, June 2025: an indicative list suggests weekly scans for new vulnerabilities, noting that frequency depends on the risk assessment, plus scans after incidents or significant changes. The guidance is not mandatory.
• CIS Controls: monthly or more often on externally exposed assets (Safeguard 7.6, with the scanner running at intervals of no more than 30 days) and quarterly or more often internally (Safeguard 7.5). These apply to groups IG2 and IG3, not IG1.
• PCI DSS v4.0.1: internal and external at least once every three months, external scans through an ASV, according to the secondary sources we consulted.
• Regulation (EU) 2024/2690: scans where appropriate, with evidence, at planned intervals. No number. It targets digital entities (DNS, cloud, data centres, managed services and others), not all NIS2 entities.
• ISO 27001:2022, A.8.8: no fixed frequency in the secondary sources we consulted.

The figures do not cancel each other out. Some are compliance thresholds, others recommendations, and they address different audiences. In Romania, Order no. 1 of 6 August 2026 from the national cyber security authority, DNSC, published in Official Gazette no. 712 of 27 August, approves the risk management measures, with the annexes in 712 bis. We could not read the annex, so we make no claim about what it says on scanning: check the annex for the control that applies to your level. We have collected the obligations towards DNSC separately. If you are based in another EU country, check the equivalent national rules.

The practical conclusion: there is no number to copy. You choose a cadence, justify it by risk and write it down. Monthly on what is exposed and at least quarterly internally is the CIS threshold, a good reference to argue from. We found no data showing that scanning more often also leads to fixing faster, so do not pay for a frequency your team cannot absorb.

Where it looks from: external and internal measure different things

An external scan shows what anyone on the internet sees, including those scanning automatically around the clock. An internal scan shows what someone already inside would find. The difference shows up in the data: in the Edgescan 2026 report, at the network layer, 24.62% of vulnerabilities on non-public assets are critical or high, against about 10% on public ones. The population is Edgescan's customers and severity follows the vendor's own score, so this is not a snapshot of small and mid-sized companies. Our reading: whoever scans only the perimeter is measuring the part that looks better.

In the same report, CVEs with identifiers from 2020 or earlier make up about 44% of occurrences on public assets and about 38% on internal ones (the totals are ours, from the report's tables; the identifier is not always the year of publication). Our reading: a good share of what a scan finds did not appear this month.

With what access: here the standards point the same way

On cadence they differ; on access they do not. CIS counts assets covered by authenticated scanning separately, the ENISA guidance suggests it where possible, and PCI DSS v4.0.1 has required it for internal scanning since 31 March 2025, according to the same secondary sources. An authenticated scan means the scanner logs in to the system with an account, often with elevated privileges, and runs local checks instead of only looking from the network. How much more it finds we do not know: the figures in circulation have no study behind them, so we will not give you one.

The practical question is on how many hosts authentication succeeded. A scan that is authenticated on paper, with credentials rejected on part of the fleet, measures less than the cover says.

What covers the gap between two scans

Raw volume says little. In January-April 2026, 20,293 CVEs were published, about 5,073 a month (the average is our calculation), and FIRST forecasts about 66,000 for the full year, adding in June that the actionable burden, measured through KEV and EPSS above 10%, remains flat. Our count on the CISA feed meanwhile shows 284 additions in 2026 up to 4 November, against 245 in all of 2025, with 43 in September and 36 in October. The periods and measures differ, and two months do not make a trend, so this does not mean FIRST was wrong.

For your interval, something else matters: 50 of those 284 have identifiers from 2024 or earlier. Old vulnerabilities also end up on the confirmed-exploitation list, so the order in last month's report can go stale without the scanner having run. Speed does not help either: M-Trends 2026 estimates mean time to exploit at -7 days, meaning exploitation usually comes before the fix, in a population of organisations that called in Mandiant. The same report has exploits as the top initial vector, at 32% of intrusions; DBIR 2026 gives 31%, on a different population.

Do not count on a notification either. In 2025, Romania's DNSC informed 2,020 public institutions and operators of essential services about more than 43,000 exploitable vulnerabilities. An ordinary private company is not on that list, so covering the interval is down to you.

How to run a vulnerability scan you can rely on

1. 1Write down what should be scanned, then compare it with what the tool actually scanned. The ENISA guidance suggests exactly this as evidence: the configuration showing that the scanner covers all relevant infrastructure and has up-to-date definitions.
2. 2Set the cadence in writing, with the reason for it: external at least monthly, internal at least quarterly, plus a scan after every significant change.
3. 3Use a dedicated account for authenticated scanning and, on every report, check on how many hosts it succeeded. In Nessus, plugin 21745 is the place to start.
4. 4Keep a separate list of what is excluded from scanning, from printers to OT equipment, which gets special treatment, and write down how you check them another way. A skipped device is still on the network.
5. 5Compare new entries in the CISA KEV feed with your inventory every week, and follow the channels Regulation 2024/2690 gives as examples: CSIRTs, authorities, vendors.
6. 6Request the free daily Shadowserver reports for your network space. They are for whoever controls that space, with identity verification.
7. 7Keep the evidence: the scan schedule, the results and what you did about them. Regulation 2024/2690 requires in-scope entities to have evidence of the results, the ENISA guidance also suggests logs of the schedule and follow-up, and according to published summaries of the DNSC Order, self-assessment in Romania is annual. Logs then save you from having to reconstruct it all.

For the gap between scans we also have a separate product, Sentinel, where prioritisation on multiple criteria belongs to the product, not to the scanning package.

What to ask any provider, including us

The Monthly Vulnerability Scanning package in our package list means a monthly external and internal scan with Nessus/OpenVAS, a prioritised CVSS report, concrete remediation recommendations and a post-fix retest on demand. Pentesting is a separate service, under cybersecurity. Catalogue prices, per month:

• Micro, up to 10 hosts: €340 excl. VAT.
• Small, 10-50 hosts: €720 excl. VAT.
• Medium, 50-100 hosts: €1,400 excl. VAT.
• Large, 100+ hosts: €2,600 excl. VAT.

The catalogue says CVSS, so we will say plainly how to read it: it is where the ordering starts, not where it ends. At Edgescan, three categories make up almost 60% of critical and high network and host findings (Diffie-Hellman DoS 24%, OpenSSH 22%, SWEET32 13.2%), and about 6.2% of discovered vulnerabilities are linked to ransomware campaigns. Mean remediation time among Edgescan customers, for criticals and highs, is 39 days on device and network, but reaches 134.3 days at EPSS above 0.7, and the report concludes that prioritisation still follows CVSS more than EPSS or KEV. On top of that, NIST no longer routinely adds its own score when one already exists, from which we infer that the score in your report increasingly comes from the product vendor. How to order the list once you have it is covered in our article on unpatched vulnerabilities.

Before you sign, with us or anyone else, ask:

• Is the internal scan authenticated? On how many hosts did it succeed in the last report?
• What was excluded from the scan, and where do I see that in the report?
• Which tool and which feed run against my perimeter devices?
• Does the report give CVSS only, or does it add KEV and EPSS?
• Who validates false positives, and in what windows do scans run? Orange Business Romania, for example, lists manual validation and scans in maintenance windows, so that is a market reference for the question.
• Is the retest included in the price? What counts as a host?

Some of our answers are not in the package sheet, so put these questions to us just as directly. A provider who dodges the question about authenticated hosts is selling you a list without telling you what it measured.

Conclusion

A monthly vulnerability scan is worth its money to the extent that you know what it measured: at what cadence, from what position, with what access, and what you did between two runs. Without those four answers, a clean report is just a short list. If you want to go through your latest report together and see what was left unmeasured, let's talk for 30 minutes.

Sources

• CISA — Known Exploited Vulnerabilities, official feed, version 2026.11.04, our own count (cisa.gov)
• CIS Controls Assessment Specification — Safeguards 7.5 and 7.6 (controls-assessment-specification.readthedocs.io)
• Implementing Regulation (EU) 2024/2690, annex, point 6.10.2, and ENISA — Technical implementation guidance v1.0, 26 June 2025 (enisa.europa.eu); McCann FitzGerald, on the non-binding status of the guidance (mccannfitzgerald.com)
• SecurityMetrics and WithPCI — PCI DSS v4.0.1 scanning requirements (securitymetrics.com); ISMS.online — ISO 27001:2022 A.8.8 (isms.online)
• DNSC Order no. 1/2026, Romanian Official Gazette no. 712 of 27 August 2026 (lege5.ro, legis.medleg.ro); published summaries: Awarely Monitor, Business Generator, Optimizor
• DNSC — Annual Report 2025, p. 16
• Jerry Gamblin — CVE 2026 Half-Year Forecast Update, 5 May 2026 (jgamblin.github.io); FIRST — Vulnerability Forecast Update, 15 June 2026 (first.org)
• Google Cloud / Mandiant — M-Trends 2026, 23 March 2026 (cloud.google.com); Edgescan — analysis of Verizon DBIR 2026 (edgescan.com)
• NIST — NVD operations update, 15 April 2026 (nist.gov)
• Edgescan — Vulnerability Statistics Report 2026 (edgescan.com)
• Tenable — scanning documentation, Nessus plugins 21745 and 11933, Nessus Essentials and pricing (tenable.com)
• Pentest-Tools.com — Network Vulnerability Scanner Benchmark, 2024 (pentest-tools.com); Red Hat — backporting (access.redhat.com); Greenbone — feed comparison (greenbone.net)
• Shadowserver — Get Reports (shadowserver.org); Orange Business Romania — SCUT Vulnerability Assessment (orange.ro)