Most vulnerability management tools are bought on the strength of a demo dashboard, then judged a year later on a question the demo never answered: did the exploited flaws on the systems that matter get fixed faster? The market spans network scanners, endpoint agents, agentless cloud scanners, container image scanners, risk-based vulnerability management (RBVM) platforms that aggregate several scanners, and vulnerability management as a service (VMaaS). The labels overlap and say little about coverage, accuracy or how findings reach the people who fix them. This vendor-neutral guide is for vulnerability management leads, security architects and procurement teams writing requirements, running an RFP or replacing a scanner, and ends with a proof of concept you can run on your own estate in four to six weeks. Our Vulnerability Management Guide covers the programme itself.
Key takeaways
- Count your assets before you count features. The NCSC notes that many vendors charge "on a 'per asset' basis", so an inaccurate asset count distorts both coverage and cost.
- Authenticated scanning is the baseline, not an option. NIST SP 800-40 Rev. 4 says inventory scans "will need sufficient access to the assets (i.e., authenticated scanning)", and unauthenticated scans underreport.
- Prioritisation must use exploitation data. Look for CISA KEV, FIRST EPSS, CVSS v4.0 Threat and Environmental metrics, SSVC-style decisions and your own asset criticality, all visible and explainable.
- Scanner credentials are privileged non-human identities. A scan account that can log in to every server is a high-value target; insist on vault integration, least privilege and monitoring.
- The product is only as good as the remediation loop. Score ticketing integration, exception handling, verification by rescan and SLA reporting as hard as detection.
Define requirements
Agree these internally and write them into the RFP before the first vendor call.
- Asset coverage: list asset classes with counts and owners: servers, roaming laptops, cloud instances and managed services, containers and Kubernetes, network appliances (VPN gateways, firewalls), databases, OT and IoT, and internet-facing assets. Reconcile the CMDB, endpoint management, EDR agent lists and cloud APIs first; the gaps between them are your first coverage requirement. See the Attack Surface Management Guide.
- Scanning cadence: CIS Controls v8.1 Safeguard 7.5 asks for internal scans "on a quarterly, or more frequent, basis", authenticated and unauthenticated, and 7.6 for monthly external scans (CIS Control 7). The NCSC advises assessing the entire estate "at least every month". If you handle card data, PCI DSS Requirement 11.3.1 requires internal scans at least once every three months (11.3.1.2 makes them authenticated) and 11.3.2 requires external scans by a PCI SSC Approved Scanning Vendor (ASV), so ask whether the service is ASV-qualified.
- Prioritisation model: decide whether you will route on KEV first, EPSS, CVSS-BTE, SSVC decisions (Track, Track*, Attend, Act), or a vendor risk score, and how asset criticality and internet exposure feed it. If you run a continuous threat exposure management (CTEM) programme, the platform must feed it; see the Exposure Management and CTEM Guide.
- Remediation path: which ITSM and engineering tools receive findings, who owns each asset class, SLAs per priority, and how fixes for actively exploited flaws bypass the normal queue. If you are also buying patching tooling, see the Patch Management Buyer's Guide.
- Constraints: air-gapped or highly sensitive networks, where the NCSC advises against SaaS scanners, data residency for scan results, OT safety rules, and who may hold scan credentials.
- Delivery model: self-run tooling, a platform with managed scanning, or VMaaS, where a provider runs scans and triage. A managed service still needs your asset owners, your risk decisions and contractual access to raw findings. Scanning finds known flaws; it does not replace penetration testing or a vulnerability disclosure channel. See the Penetration Testing Guide and the Bug Bounty and Vulnerability Disclosure Guide.
Size changes the answer. A small organisation with one cloud and a few hundred endpoints is usually well served by one agent-based platform with cloud connectors, or an open-source scanner plus disciplined process. A large enterprise runs several scanners and needs an RBVM aggregation layer that de-duplicates findings and maps them to owners.
| Scanning approach | Best for | Watch for |
|---|---|---|
| Unauthenticated network scan | Attacker's view, rogue and unmanaged hosts, external perimeter | Version guessing; underreports compared with credentialed checks |
| Authenticated network scan (SMB/WMI or WinRM, SSH) | Servers and appliances that cannot run an agent | Needs privileged credentials on every host; silent fall-back to unauthenticated results when login fails; account lockouts |
| Endpoint agent | Laptops off the network, servers, cloud instances, near real-time inventory | Agent deployment and health become the coverage gap; no attacker's-eye view |
| Agentless cloud (API and disk snapshot) | Short-lived workloads, managed services, fast cloud coverage | Broad read roles in every account; snapshot timing lags live state. See the CNAPP Guide |
| Container image and registry | Build pipelines and registries, before deployment | Image results do not prove what is running; base images age after build. See the Container Security Guide |
| Passive network monitoring | OT and fragile devices where active probing is unsafe | Sees only communicating devices; limited version detail. See the OT Security Guide |
Evaluation criteria
Weight these to your requirements. An illustrative split: 25% coverage and accuracy, 25% prioritisation and intelligence, 25% remediation and reporting, 15% platform and credential security, 10% commercial terms.
| Criterion | What good looks like | Weak signs |
|---|---|---|
| Asset coverage | An asset view merging agent, network, cloud and CMDB sources that flags assets seen but not scanned | Coverage claims without a reconciliation report; OT handled only by active scans |
| Authenticated scanning | Per-host authentication success reporting for Windows, Linux, network devices and databases; lockout safeguards; SCAP-compliant checks | A failed login quietly produces a "clean" unauthenticated result |
| Detection accuracy | Evidence for each finding (file path, package version, registry key); correct handling of Linux backported fixes | Findings based only on banners; no evidence shown; no way to dispute a finding |
| Prioritisation | KEV flag, daily EPSS, CVSS v4.0 shown as CVSS-B, CVSS-BT or CVSS-BTE, asset criticality and internet exposure, with the score's inputs visible | A proprietary risk number you cannot decompose |
| Vulnerability intelligence speed | Checks for new and KEV-listed flaws within days, independent of NVD enrichment, including edge appliances | Checks that wait for NVD CPE data; no published content release history |
| Remediation workflow | Two-way ITSM integration, grouping by fix (one patch, many CVEs), owner routing, SLA timers, closure only after a rescan confirms the fix | One ticket per CVE per host; tickets closed by status change alone |
| Exceptions and risk acceptance | Approver, reason, compensating control and expiry date, re-raised on expiry | Suppression with no owner or end date |
| Reporting and SLA tracking | Percentage remediated within SLA by priority and owner, mean and median time to remediate, coverage trend, exportable through an API | Only total vulnerability counts; static PDFs |
| Platform security | SSO with enforced MFA, role-based access, tenant audit log, named hosting regions, independent assurance, a published disclosure process | Shared admin accounts; no customer-visible audit trail |
| Licensing | Clear asset definition (IP, host, agent, container image, cloud resource), handling of short-lived and duplicate assets, cost of adding modules | Counting every ephemeral container as a licence; cost that discourages full coverage |
FIRST says CVSS Base scores "should not be used alone to assess risk" and that applying Threat and Environmental metrics "is the responsibility of the CVSS consumer" (CVSS v4.0 User Guide). The EPSS User Guide warns that "EPSS should never be treated as a risk score". CISA says organisations "should use the KEV catalog as an input to their vulnerability management prioritization framework" (CISA KEV), and its SSVC decision tree combines exploitation status, technical impact, automatability, mission prevalence and public well-being impact. On intelligence speed, NIST announced in April 2026 that backlogged CVEs published before 1 March 2026 move to "Not Scheduled" for enrichment, with KEV-listed CVEs prioritised (NIST NVD), so a scanner that waits for NVD product data will miss or delay checks.
Where identity fits
Authenticated scanning means the platform holds privileged credentials: local Administrators on every Windows server, sudo over SSH, network device and database logins, and cloud read roles across every account. NIST SP 800-53 Rev. 5 recognises this with RA-5(5) Privileged Access for vulnerability scanning. These non-human identities have some of the widest reach in the estate, and scanners are software that can be compromised: the Trivy supply chain attack turned a security scanner into a credential stealer. Require vault or PAM integration so credentials are checked out at scan time and rotated, not stored in the scanner; separate scan accounts per environment and tier; interactive logon denied; alerts on use outside scan windows; and cloud access through role assumption or workload identity federation, not static keys. See the Service Account Security Guide, the PAM Buyer's Guide and the Cloud Workload Identity Guide.
Questions to ask vendors
- Which asset classes do you cover natively, and how do you show assets that exist in our CMDB, EDR or cloud accounts but were never scanned?
- How do you report authentication failures per host, and does a failed credentialed scan ever appear as a clean result?
- Which vaults and PAM platforms do you integrate with for scan credentials, are credentials ever stored in your platform, and what privileges does each check need at minimum?
- For cloud scanning, what roles do you request in each account, can access be read-only and federated, and how do you scan disk snapshots without copying our data out of region?
- How long did it take you to ship detection for the last five KEV additions affecting edge devices, and how do you detect flaws that the NVD has not yet enriched?
- Show the inputs behind your risk score for one finding: KEV status, EPSS, CVSS vector, asset criticality and exposure. Can we change the weighting?
- How do you handle Linux distribution backports and other false positives, and how do analysts dispute a finding?
- Does a ticket close only when a rescan or agent confirms the fix, and how are workarounds and time-limited exceptions tracked?
- What exactly counts as a licensed asset, how are ephemeral containers and duplicate hosts counted, and what happens to cost when coverage grows?
- How do you scan OT and fragile devices safely, and can scanning run passively or with throttled, allow-listed checks?
- What independent assurance covers your platform, and what security incidents affecting your scanners or agents have you disclosed?
Red flags
- Scan credentials stored in the platform with no vault option, or a single domain admin account recommended "for simplicity".
- A risk score that cannot be explained finding by finding, or that ignores KEV status.
- Detection content that lags weeks behind exploited vulnerabilities in VPN gateways and firewalls, the devices behind incidents such as the Ivanti Connect Secure exploitation. See the Edge Device Security Guide.
- Remediation status driven by ticket closure rather than verification, or failed credentialed scans reported as clean.
- Licensing that charges per container instance or per IP in a way that pushes you to scan less.
- Active scanning of OT networks offered without safety controls or a passive option.
- Agents with no tamper protection or vague answers about the agent's own privileges and update signing.
Proof of concept
- Scope and baseline: choose a representative slice of about 500 to 2,000 assets: servers, laptops, one cloud account, one container registry, some network devices and internet-facing hosts. Record asset counts per source and agree scoring weights before the first scan.
- Seed known issues: leave a few known-vulnerable test hosts and images in scope, including one KEV-listed flaw, a missing third-party application update, a Linux package with a backported fix and a misconfiguration. You now have a ground truth for false positives and false negatives.
- Set up credentials properly: create dedicated, least-privilege scan accounts, connect them through your vault, deny interactive logon, and log every use. Note every permission the vendor asks for.
- Run every scan type: unauthenticated, authenticated, agent and cloud. Compare coverage against your asset sources and measure authentication success rates per platform.
- Test prioritisation: export the top 50 findings and check whether KEV-listed and internet-facing issues come first, and whether analysts can explain each ranking.
- Run the remediation loop: push findings into your ITSM tool, fix a sample, and confirm closure happens only after verification. Raise and expire one exception.
- Exercise operational limits and roll back: measure agent CPU and network load, test throttling on fragile devices, then uninstall agents, revoke scan credentials and cloud roles, confirm access has stopped, and request written confirmation that trial data has been deleted.
Carry these numbers from the trial into production: authenticated scan success rate, percentage of known assets scanned in the last 30 days, percentage of KEV findings remediated within SLA, mean and median time to remediate by priority, confirmed false positive rate, and count of open exceptions past expiry. NIST SP 800-40 Rev. 4 suggests the percentage of assets patched by their maintenance plan deadlines and mean and median times, and warns against "overly simplistic metrics" such as raw vulnerability counts (NIST SP 800-40 Rev. 4). The NCSC's vulnerability scanning tools and services guidance adds further vendor questions.
How NHI Mgmt Group can help
We provide independent requirements, RFP and evaluation support. Browse vendors in our products directory or contact us.
Related NHI Mgmt Group resources: Vulnerability Management Guide · Patch Management Guide · Zero-Day and Exploited Vulnerabilities Guide · Exposure Management and CTEM Guide · Patch Management Buyer's Guide