Vulnerability management tools: types and how to choose

The short answer: vulnerability management tools find the weaknesses in your systems, rank them by real risk and track each one until it is fixed and verified. They come in four families: network scanners, endpoint agents, cloud platforms that connect via API, and external attack surface management. Most organisations need more than one, and the choice depends on coverage, prioritisation, integration and evidence.

This is not a league table. It is a guide to what each type of tool sees and misses, the criteria that separate them, and what European rules such as NIS2 and DORA expect the tooling to produce.

What a vulnerability management tool actually does

A scanner on its own produces a list. A vulnerability management tool turns that list into work. NIST SP 800-40 Rev. 4 describes vulnerability management as a cycle, not a scan: know which vulnerabilities affect your assets, plan the response, execute it, verify it, and keep monitoring that it stays in place. The response is not always a patch. NIST lists four families: accept the risk, mitigate it (a patch, an upgrade, a configuration change or an extra control), transfer it, or avoid it by removing the software or retiring the asset.

So a good tool covers five jobs:

• Discovery: which assets exist and what software versions they run.
• Detection: which known vulnerabilities affect those versions and configurations.
• Prioritisation: which findings to fix first, and why.
• Tracking: who owns each finding, by when, and which exceptions are open.
• Evidence: reports that show an auditor or a board what was found, fixed and accepted.

The reason to get this right is measurable. In the ENISA Threat Landscape 2025, which covers nearly 4,900 selected incidents in Europe between July 2024 and June 2025, exploitation of vulnerabilities was the second most common intrusion vector at 21.3%, after phishing at about 60%. ENISA also notes widespread campaigns that weaponise vulnerabilities within days of disclosure.

The four types of vulnerability management tools

Each family looks at your estate from a different position. None of them sees everything.

1. Network vulnerability scanners

The classic approach: a scanner on your network probes hosts and services and compares what it finds with a database of known vulnerabilities. It can run unauthenticated, seeing what an outsider on the network would see, or authenticated, logging in to read installed packages and patch levels. Tenable's documentation for Nessus states that configuring credentials allows a wider variety of checks and more accurate results, and that the more privileges the scan account has, the more thorough the results. Greenbone describes OpenVAS as a full-featured vulnerability scanner with unauthenticated and authenticated testing.

Good at: servers, network devices and anything with an IP address on networks you control. Weak at: laptops that are rarely on the office network, short-lived cloud workloads, and assets nobody told the scanner about.

2. Agent-based tools

Here a small piece of software runs on each endpoint or server and reports its own state. Qualys, for example, describes its Cloud Agent as lightweight software installed on assets and endpoints that provides continuous assessment without traditional network scans. Agents see remote laptops wherever they are and avoid scan windows.

Good at: roaming devices and continuous visibility. Weak at: anything you cannot or will not install software on, such as network appliances, OT equipment and some managed services. Coverage is only as good as your deployment rate.

3. Cloud and CNAPP platforms that connect via API

In AWS, Azure or Google Cloud, workloads appear and disappear faster than a scan schedule. Cloud security platforms, often grouped under the CNAPP label, connect to the provider's APIs to build an inventory of resources, configurations and permissions, and analyse workloads without installing agents. Wiz, for example, connects through cloud provider APIs, without agents, and presents risks as a prioritised queue of attack paths on its Security Graph. The point of an attack path is context: the same vulnerability weighs more on a machine that is exposed to the internet and holds broad permissions than on an isolated test box.

Google completed its acquisition of Wiz on 11 March 2026. Google states that it retains the Wiz brand, that Wiz products continue to work across major clouds including Amazon Web Services, Microsoft Azure and Oracle, and that Wiz will be combined with Google Security Operations so that security operations teams use the same cloud context to detect and investigate attacks.

Good at: multicloud estates, containers and fast-changing infrastructure, plus the link between a vulnerability and its exposure. Weak at: on-premises servers and user devices, which still need a scanner or an agent. More on this angle in our cloud security service.

4. External attack surface management (ASM)

ASM tools look at you from the outside, the way an attacker would. Starting from a few seeds, such as a domain, known networks or SaaS accounts, they discover internet-facing assets and check them for exposures. Google's Mandiant Attack Surface Management, for instance, works this way, with daily, weekly or on-demand discovery and active checks designed from Mandiant intelligence to validate whether an asset is susceptible to exploitation.

Good at: forgotten subdomains, shadow IT, exposed services and acquisitions. Weak at: anything inside the perimeter. ASM tells you what is exposed; it does not replace an internal inventory.

How the four fit together

A typical mid-market estate needs at least two: a scanner or agents for servers and endpoints, and an API-based platform for the cloud, with ASM on top if the internet-facing footprint is large or poorly known. What matters is that findings from every source land in one register, with one priority model and one owner per finding. Penetration testing sits beside these tools, not inside them: it checks whether a vulnerability can actually be exploited in your context. See our guide to penetration testing services.

Criterion 1. Coverage, checked against your own inventory

Start from your asset list, not from the vendor's feature list. For each asset class (servers, workstations, network devices, cloud accounts, containers, OT, SaaS) ask which tool covers it and how: authenticated scan, agent, API or external check. Anything without an answer is a blind spot. Ask too how the tool finds assets nobody registered, because a scanner only tests the ranges you give it.

Criterion 2. Prioritisation beyond the CVSS score

Every tool reports more findings than any team can fix at once, so the order is the product. Look for a tool that combines four signals:

• Severity (CVSS). FIRST's CVSS v4.0 produces a score from 0 to 10 indicating the severity of a vulnerability relative to others. The specification recommends enriching the base score with threat and environmental metrics for more meaningful results. A base score alone is a starting point, not a measure of your risk.
• Known exploitation (KEV). The CISA Known Exploited Vulnerabilities catalog lists vulnerabilities with reliable evidence of active exploitation and a clear remediation action. In the version of 27 October 2026 it held 1,760 entries, 361 of them flagged as known to be used in ransomware campaigns. CISA recommends that all organisations, not only US federal agencies, review it and use it in their vulnerability management.
• Likelihood of exploitation (EPSS). EPSS, maintained by a special interest group at FIRST, estimates the probability that a published CVE will be exploited in the next 30 days, and publishes a score every day for every CVE. FIRST suggests combining it with CVSS and KEV.
• Asset context. Internet exposure, business criticality and the data on the system. Only you know this, so the tool needs a way to record it, through tags, asset groups or a link to your CMDB.

The test in a demo: pick ten real findings and ask the tool to explain why each one sits where it does. If the answer is only the CVSS score, the prioritisation is left to you.

Criterion 3. Integration with the SIEM and the ticketing system

A finding that stays in the scanner console does not get fixed. Check three integrations:

• Ticketing: findings open tickets for the right team and close when a rescan confirms the fix, not when someone marks them done.
• SIEM: vulnerability data sent to the SIEM lets analysts see, during an alert, whether the targeted host is actually vulnerable. That changes how fast an incident is triaged. Our guide to SIEM tools covers the SIEM side.
• Change management: patch windows, approvals and rollbacks follow your existing process. For digital providers covered by NIS2, Implementing Regulation (EU) 2024/2690 asks that vulnerability handling be compatible with change management, patch management, risk management and incident management procedures (Annex, point 6.10.2(d)).

Criterion 4. Reporting that stands up in an audit

Auditors and supervisors do not ask which tool you bought. They ask for evidence of a process, and the tool is where most of that evidence lives.

• NIS2. Directive (EU) 2022/2555 lists "security in network and information systems acquisition, development and maintenance, including vulnerability handling and disclosure" among the minimum risk-management measures (Article 21(2)(e)). For the digital providers it covers (cloud, data centre, managed service and managed security service providers, among others), Implementing Regulation (EU) 2024/2690 asks for vulnerability scans where appropriate with evidence of the results recorded at planned intervals, critical vulnerabilities addressed without undue delay, and a documented reason when a vulnerability does not require remediation (Annex, points 6.10.2 and 6.10.3). See our NIS2 service.
• DORA. For financial entities outside DORA's simplified ICT risk management framework (Article 16), Delegated Regulation (EU) 2024/1774 asks for automated vulnerability scanning and assessments, with frequency and scope commensurate to the asset's classification and risk profile, carried out "on at least a weekly basis" for ICT assets supporting critical or important functions (Article 10(2)). It also asks entities to record every detected vulnerability and monitor its resolution, to track third-party and open-source libraries (Article 10(2), points (d) and (h)), and to set time limits and escalation procedures for patches (Article 10(4), point (d)). See our DORA service.
• ISO/IEC 27001:2022. Annex A control 8.8, management of technical vulnerabilities. In an audit the questions follow the cycle: where vulnerability information comes from, how priorities are set, how quickly findings are closed, and how exceptions are justified. More in our ISO 27001 service.

So check that the tool can export, for a given period, the findings by asset group and severity, time to remediation, open exceptions with their owner and review date, and the scan history that proves the cadence. NIST SP 800-40 Rev. 4 warns that oversimplified metrics, such as the share of unpatched assets, lead to no decision unless you know which assets they are.

Criterion 5. Who runs it after go-live

The most common failure is not a bad tool. It is a good tool whose reports nobody reads after the first quarter. Before buying, answer three questions: who tunes the scans and credentials when the estate changes, who reviews new KEV entries against your assets each week, and who chases the owners of overdue findings. If the honest answer is one person part-time, budget for that work alongside the licence, either internally or through a managed cybersecurity service.

Questions to ask in a demo or RFP

1. Which of my asset classes do you cover, and how: authenticated scan, agent, API or external check?
2. How do you find assets that are not in my inventory?
3. Which signals drive your priority score, and can I see them for each finding?
4. How do you use KEV and EPSS, and how quickly do new KEV entries show up?
5. Which SIEM and ticketing integrations are maintained by you, and does a ticket close only after a successful rescan?
6. Can I export the evidence an auditor asks for: findings, time to fix, exceptions and scan history, for any period?
7. What happens to my data and history if I change tool in three years?

In short: network scanners, agents, API-based cloud platforms and external ASM each see a different part of the estate. Choose on coverage of your own inventory, prioritisation with KEV, EPSS and asset context on top of CVSS, integration with the SIEM and ticketing, and reporting that shows auditors a working process. Then decide who runs it.

AmagisTech is a Google Cloud partner and a Wiz partner, and runs managed security services for mid-market organisations. If you want to map which tools cover which parts of your estate, and where the gaps are, talk to our team.