A vulnerability scanner is an automated tool that checks your networks, systems, applications or cloud assets for known weaknesses, such as missing patches, outdated software and risky misconfigurations, and then reports what it found so your team can fix it. NIST's glossary describes it as a network tool, in hardware or software, that scans devices to identify generally known and organization-specific CVEs. Vulnerability scanning is the act of running that tool. Below, we explain how it works, which types exist, what it misses, and what to do with the results.
TL;DR
- A vulnerability scanner automatically inspects IT assets and compares what it finds against databases of known flaws and configuration rules.
- The two main scan modes are authenticated (uses credentials, deeper results) and unauthenticated (outsider's view, broader but shallower).
- Scanners produce false positives and false negatives, and they do not prove a flaw can actually be exploited. Penetration testing does that.
- A scan only has value when findings are validated, prioritized, fixed and rescanned.
- Customers increasingly ask vendors to describe their scanning program in security questionnaires, so documenting it well matters.
Table of Contents
- What a vulnerability scanner actually is
- How a vulnerability scan works, step by step
- Types of vulnerability scans
- What a scan can uncover, and what it can miss
- Vulnerability scanning vs. penetration testing
- Why organizations scan
- What to do with the results
- Do hackers use vulnerability scanners?
- How to choose a vulnerability scanner
- Our perspective: scanning is only half the story
- From scan results to questionnaire answers
- FAQ
- Sources
What a vulnerability scanner actually is
Think of a scanner as a very fast, very literal inspector. It does not guess at your intentions or study your business logic. It looks at what is exposed or installed, then asks a single question: does this match something already known to be dangerous?
IBM defines vulnerability scanning as the process of evaluating networks or IT assets for security vulnerabilities, flaws or weaknesses that internal or external threat actors could exploit. Tenable adds a practical angle: its description is of an automated tool that inspects an organization's attack surface for vulnerabilities, misconfigurations, unpatched assets and outdated operating systems.
A few terms help here:
- Vulnerability: a flaw or weakness in software, hardware or configuration that an attacker could use.
- CVE: a publicly cataloged identifier for a known vulnerability. Most scanners rely on CVE-based databases.
- Attack surface: everything an attacker could reach, from servers and laptops to web apps and cloud services.
- Remediation: the fix, usually a patch, a configuration change or a compensating control.
Scanners can be hardware appliances, software you install, agents on endpoints, or cloud services. The form matters less than what the tool checks and how often it runs.
How a vulnerability scan works, step by step
Vendors describe the flow slightly differently, but the core sequence is consistent. IBM explains that scanners collect information about IT assets, compare it with a vulnerability database, identify potential flaws and compile reports. Check Point describes the same pattern for network scanners: building an asset inventory, establishing the attack surface from host responses and installed software, comparing assets with vulnerability databases or configuration best practices, and generating reports.
Put together, a typical scan looks like this:
- Discover assets. The scanner finds hosts, devices, services and applications within the scope you defined.
- Collect details. It gathers software versions, open ports, running services, installed packages, configurations and, for cloud scans, account settings. Rapid7 lists these among the items a scanner typically collects before checking them against known vulnerabilities or policy rules.
- Match against known issues. Each finding is compared with vulnerability databases and configuration baselines.
- Report. Results come back as a list of issues, usually with severity ratings.
- Prioritize. Advanced scanners rank findings and suggest remediation or mitigation.
- Rescan. After a fix, the same check runs again to confirm the issue is closed.
That last step is the one teams skip most often, and it is the one that turns a report into evidence of improvement.
Why scope and timing matter
Scanning is not free of side effects. NIST's technical guide to security testing notes that scanners can cause network performance problems or disrupt operations if they are not carefully selected and scheduled, particularly when intensive tests are run. Agree on windows with the owners of fragile systems before you scan production.
Types of vulnerability scans
People searching for the two main types of scans usually mean authenticated and unauthenticated. There are other useful ways to slice the same activity, shown below.
| Dimension | Option | What it means | Best for |
|---|---|---|---|
| Access | Authenticated | Uses an authorized user's privileges to inspect software versions, patch levels and configurations in depth | Accurate internal assessments |
| Access | Unauthenticated | No access permissions, so it sees assets from an outsider's perspective | Seeing what an attacker sees |
| Location | Internal | Looks for vulnerabilities from inside the network | Lateral-movement risk, workstations, servers |
| Location | External | Examines the network from outside, focused on internet-facing assets | Websites, VPNs, exposed services |
| Deployment | Agent-based | Software runs locally on an endpoint for deeper configuration visibility | Laptops, remote workers |
| Deployment | Agentless | Assesses assets over the network | Devices where agents cannot be installed |
The access definitions come from IBM's overview, which also covers internal and external scans, and the agent distinction from Tenable's guide. NIST describes local scanning, where a scanner is installed on each host, as giving a higher level of detail than network-based scanning because it can see operating system and application misconfigurations.
Scanners by asset type
Beyond the basic network scan, scanners are built for specific targets:
- Network scanners for servers, routers, firewalls and other connected devices.
- Web application scanners for flaws in sites and APIs.
- Cloud scanners for misconfigured storage, identity settings and exposed services. If you run on Amazon's cloud, our walkthrough on how to perform an AWS vulnerability scan covers the practical steps.
- Host-based scanners for operating system and local application settings.
- Mobile and IoT scanners for devices that rarely get patched on a schedule.
A general-purpose scanner tries to cover several of these at once. A specialized one goes deeper on a single asset type. Most mature programs end up combining both.
What a scan can uncover, and what it can miss
Scans are good at the repetitive, high-volume findings that cause a large share of real incidents: unpatched software, missing patches, and common misconfigurations. NIST lists identifying outdated software, missing patches and misconfigurations, and validating compliance with security policies as core uses.
They are weaker at flaws that only appear at runtime, at business-logic bugs, and at complex combinations of weaknesses that only matter when chained together. The same NIST guide also warns that scanners produce false positives (reporting a vulnerability that is not there) and false negatives (failing to report one that is).
An example of a false positive
Red Hat points out one common cause. Scanners that rely only on package version numbers and external data such as the NVD may flag vulnerabilities that are already patched when they do not account for backported security patches. A distribution may fix a flaw without changing the headline version number, so a naive check sees an old version and raises an alert.
The lesson is to treat scanner output as a lead to verify, not as a verdict. Someone who understands how the component was built and configured should confirm the important items.
Vulnerability scanning vs. penetration testing
These two get confused constantly, and the difference is worth stating plainly.
- Vulnerability scanning is broad and automated. It builds an inventory of potential weaknesses and generally reports them without proving they can be exploited.
- Penetration testing is more manual and offensive. Authorized testers try to exploit weaknesses and determine real-world impact.
The UK National Cyber Security Centre frames pen testing as an attempt to breach some or all of a system using the tools and techniques an adversary might use, and says it should provide assurance about your vulnerability-management processes rather than replace them. In practice, scanning runs continuously or on a regular schedule, while pen tests happen periodically or after major changes.
If you are planning one, our 2026 professional guide to pen testing covers the process, and how to report penetration test findings helps you turn the results into something stakeholders act on.
Why organizations scan
The UK NCSC lists the advantages of scanning tools as automation, speed, cost-effectiveness and scalability. Organizations use them to automate security checks, keep visibility into known weaknesses, and support compliance work.
The compliance angle deserves a note. Many frameworks and customer contracts expect regular scanning, and auditors will want to see that it happens and that findings are closed. Our guide to compliance scanning for secure operations explains how that fits together, and the cybersecurity checklist for enterprises places scanning among the other controls reviewers look for.
What to do with the results
A list of 4,000 findings helps nobody. Rapid7's practical view is that scanner output becomes useful only when findings are assigned, prioritized using risk context, remediated and rescanned, and that detection is one stage of vulnerability management rather than the end of it.
A workable routine:
- Validate. Confirm true positives and discard obvious false ones. Sonar notes that teams must validate true positives, remediate and rerun scans after results are correlated and deduplicated.
- Prioritize. Use severity scores (commonly CVSS) together with context: is the asset internet-facing, does it hold sensitive data, is an exploit known to be in use?
- Assign owners. Every finding needs a named team and a target date.
- Remediate or mitigate. Patch, reconfigure, isolate, or document an accepted risk.
- Rescan. Confirm the fix and keep the evidence.
On frequency, IBM notes that security teams often group assets by criticality and scan them in batches, scanning the most critical assets more frequently. That is a sensible default when you cannot scan everything every day.
Do hackers use vulnerability scanners?
Yes. The NCSC notes that individuals and groups intent on compromising systems often use tools and techniques similar to vulnerability scanners to discover security flaws. That is the strongest argument for scanning your own estate first: if the same checks will be run against you, you want to see the results before someone else does. Only scan systems you own or have written permission to test.
How to choose a vulnerability scanner
Without naming products, here are the criteria that separate a good fit from an expensive disappointment:
- Coverage: Does it handle your actual mix of servers, endpoints, web apps, containers and cloud accounts?
- Accuracy: How does it handle backported patches and false positives? Ask how findings are verified.
- Authenticated and agent options: Deeper checks are worth little if you cannot deploy credentials or agents safely.
- Prioritization: Does it add exploitability and asset context, or only a raw severity score?
- Reporting and integrations: Can findings flow into your ticketing and remediation workflow?
- Operational impact: Can you throttle and schedule scans so they do not disrupt production?
- Compliance mapping: Can you export evidence in a form auditors and customers accept?
Red Hat's perspective is also worth keeping in mind: risk depends on how a component is built, configured and shipped, including which features are enabled. A tool that ignores that context will overstate or understate your exposure.
Our perspective: scanning is only half the story
We spend our days with the people who sit on the receiving end of scanning programs: CISOs, GRC leads and sales engineers who have to prove what their scanners do. When a prospect sends a security questionnaire, a question like "Do you perform regular vulnerability scans, and how are findings remediated?" is rarely about the tool itself. It is about whether your process is real, repeatable and documented.
That changes how we think about this topic. A scanner generates data, but a buyer needs a credible answer: how often you scan, what scope you cover, how you rank findings, how fast you fix critical ones, and how you verify the fix. Teams that can answer those five points consistently, in the same words every time, close reviews faster and with fewer follow-up calls.
So our advice is to write your scanning program down once, keep it in a single knowledge base, and reuse it. Scan evidence, remediation timelines and policy documents should live where your whole team, including sales, can find them. If you are building that discipline, our notes on security review best practices and on optimizing your risk assessment workflow are a good place to continue. Please feel free to reach out if you would like to compare notes.
— Gaspard
From scan results to questionnaire answers
Once your scanning program is running, the next friction point is usually external: customers and prospects asking you to describe it, over and over, in different formats. That is the problem Skypher is built for. Our Questionnaire Automation Tool uses our proprietary retrieval AI with confidence scoring to draft answers from your own approved content, supports every common document format, and connects to more than 40 third-party risk management platforms and workplace tools, including OneTrust, ServiceNow, Slack, MS Teams, Confluence, Notion, Google Drive, OneDrive and SharePoint.
Your scanning policy, remediation timelines and audit evidence become reusable knowledge, with document versioning so answers stay current. If you would like a customer-facing home for that evidence, our Trust Center lets you share your security and compliance posture proactively. You can see how the platform works on our security questionnaire automation page, or read how to streamline security questionnaires and boost questionnaire accuracy. Pricing is quote-based, so book a demo through our site to get a proposal fitted to your volume.
FAQ
What do you mean by vulnerability scanner?
It is an automated tool, delivered as software or hardware, that examines devices, applications or cloud assets for known weaknesses and reports them. NIST's glossary describes it as a tool that identifies generally known and organization-specific CVEs. The report tells your team what to patch or reconfigure.
What are the two main types of vulnerability scans?
Authenticated and unauthenticated. Authenticated scans use an authorized account to inspect patch levels and configurations in depth, while unauthenticated scans look at assets as an outsider would. Most programs use both, because each reveals problems the other cannot.
Is vulnerability scanning the same as penetration testing?
No. Scanning is automated and broad, and it reports potential weaknesses without proving they can be exploited. Penetration testing is a manual, adversary-style exercise that tries to exploit them and measure real impact. The two complement each other.
Do hackers use vulnerability scanners?
Yes, attackers often use tools and techniques similar to scanners to find flaws, according to the UK NCSC. That is why regular scanning of your own systems, with permission and on a schedule, is a standard defensive practice.
How often should we run a vulnerability scan?
There is no single right answer. A common approach is to group assets by criticality and scan the most important ones more often, as IBM describes. Your compliance obligations and customer contracts may also set a minimum frequency, so check them first.
Sources
- vulnerability scanner - Glossary, NIST CSRC
- What is Vulnerability Scanning? IBM
- What is a vulnerability scanner? Tenable
- What is a Network Vulnerability Scanner? Check Point
- Vulnerability Scanning Tools Explained, Rapid7
- Technical Guide to Information Security Testing and Assessment, NIST SP 800-115
- A quickstart guide on vulnerability scanners, Red Hat
- Penetration Testing vs. Vulnerability Scanning, TechTarget
- Penetration testing, UK NCSC
- Vulnerability scanning tools and services, UK NCSC
- What is Vulnerability Scanning? Sonar