What Is Vulnerability Scanning? Types and How It Works

Most companies breached through an unpatched system were holding a scan report that named the flaw. The report ran to four hundred findings, arrived as a PDF, went into a shared folder, and nobody ever decided which three of the four hundred an attacker would reach for first. Running the scan is the cheap part and it is the part every vendor sells. Deciding what to do with the output is the work, and it is where almost every program stalls.

What Is Vulnerability Scanning?

A vulnerability scanner connects to your systems, works out what software and versions are running, and compares each one against a catalog of published flaws. What comes back is a list: this host runs a web server two versions behind, that database accepts a default password, this cloud storage bucket answers to anyone. Each finding carries an identifier, usually a CVE number, and a severity score.

The word doing the most work in that description is known. A scanner is a lookup against a database that somebody else maintains. It is very good at the enormous, boring problem of finding the flaw that was published eight months ago and is still sitting on a server nobody owns. It is useless against a flaw that has not been published, and it is only as good as its view of your network.

Scanning is also one step inside a longer process, and the two get conflated constantly. Vulnerability management is the whole loop: find the flaws, decide which matter, fix them, prove they are gone, and do it again next month. NIST's Guide to Enterprise Patch Management Planning frames the remediation half as ordinary preventive maintenance, defining it as identifying, prioritizing, acquiring, installing and verifying patches across the organization, and arguing that treating it as routine upkeep rather than an emergency is what makes it survivable. Scanning supplies the first two verbs. It cannot supply the rest.

That distinction matters for budgeting. A scanner license is a small purchase; the staffing to act on what it produces every month is not, and buying the first without the second is how a program ends up as a folder full of PDFs. Scanning belongs inside a layered defense, doing one narrow job no other control does.

How Vulnerability Scanning Works

A scan runs in five stages, and only three of them are automated.

Discovery comes first because you cannot scan what you have not found, and the inventory a scan produces is often more valuable than the vulnerability list attached to it. Forgotten test servers, a subsidiary's address range nobody documented, a cloud account opened for a project in 2023: these turn up in the discovery pass, and they are disproportionately the systems that nobody has patched.

Fingerprinting is where the scanner decides what it is looking at. Sometimes that means reading a version banner a service volunteers. Sometimes it means sending a harmless probe and judging the answer. This is also where false positives are born, because a version number is a guess about what is patched underneath it, and backported security fixes routinely leave the old version string in place.

The urgency behind all of this changed recently. The 2026 Verizon Data Breach Investigations Report found 31 percent of breaches beginning with vulnerability exploitation, the first time in nineteen years that it has passed stolen credentials as the leading way in, and describes attackers closing the gap between a published flaw and a working exploit from months down to hours. A quarterly scan cycle was built for a world where you had weeks.

What Are the Two Main Types of Vulnerability Scans?

Ask three engineers and you will get two different answers, because two separate pairs both claim the name. Both pairs are worth knowing, because they answer different questions.

Internal against external is about where the scanner stands. An external scan runs from the public internet against the addresses you own, and it sees exactly what a stranger sees: the open ports, the exposed management interfaces, the certificate that expired last month. An internal scan runs from inside the network and sees the far larger population of systems that the firewall in front of them keeps out of public view. External scanning tells you about the front door. Internal scanning tells you how far someone gets after they are through it.

Authenticated against unauthenticated is about how much the scanner is allowed to know. An unauthenticated scan probes from outside the login and judges by what the service reveals. An authenticated scan signs in with credentials you provide and reads the installed package list, the patch level and the local configuration directly. An unauthenticated scan of a Linux server returns a dozen guesses from banner versions; an authenticated scan of the same box returns the actual patch state and far fewer false positives.

A third distinction is worth a sentence. Active scanning sends traffic to the target and waits for an answer. Passive scanning watches traffic already flowing and infers what is running, which finds nothing new but touches nothing either. Passive monitoring is how industrial and medical networks get covered, because the devices on them fall over when probed.

Types of Vulnerability Scanners

Scanners specialize by what they are pointed at, and no single one covers a modern estate.

Two patterns are worth pulling out. Agent based scanning has become the default for endpoints, because a laptop that is on the office network one day a week never gets scanned by anything waiting for it to appear. And container scanning belongs in the build pipeline rather than production, because once a vulnerable image is running the fix means rebuilding and redeploying rather than patching in place.

Vulnerability Scanning vs Penetration Testing

These get sold together and confused constantly, and the difference is the difference between a checklist and an adversary.

The practical answer for most organizations is that these are not alternatives. Scanning is the hygiene control you run continuously. A penetration test is the annual proof that the hygiene is working, and its most useful output is usually not the vulnerability list but the answer to a different question: did anyone notice? A scanner has no opinion on whether your monitoring works. A tester does.

One warning about procurement. Some firms sell an automated scan with a report cover on it as a penetration test. The tell is the deliverable: a real test names the path the tester took, in order, with evidence at each step. A scanner's output is a sorted list.

How Often Should You Run a Vulnerability Scan?

The honest answer is that the cadence follows the exposure, not the calendar.

For anything reachable from the internet, continuous or weekly is the target, because that is the surface attackers scan every day. CISA runs a free service on exactly this basis: its cyber hygiene vulnerability scanning continuously assesses internet-accessible assets for any US federal, state, local, tribal or territorial government body and any public or private critical infrastructure organization, sends a weekly report and raises ad-hoc alerts for known exploited vulnerabilities. It costs nothing, and a great many eligible organizations have never enrolled.

For internal systems, monthly is a defensible floor and weekly is better, with an unscheduled scan whenever something significant changes: a merger, a new office, a major platform upgrade.

Compliance sets a minimum rather than a target, and the best known example is payment card data. PCI DSS Requirement 11.3.2 requires evidence of passing external scans performed by an Approved Scanning Vendor at least once every three months, alongside internal scanning on the same quarterly rhythm. Quarterly is what the standard demands. It is not what the threat looks like, given that attackers now weaponize a published flaw within hours, and treating the quarterly ASV scan as your whole program is a compliance pass wrapped around a real gap.

How to Prioritize Vulnerability Scan Results

Severity scores are where most programs go wrong. A scan of a mid-sized estate routinely returns several thousand findings, a few hundred of them scored critical, and no team patches a few hundred things this week. Ranking by CVSS alone sorts the queue by theoretical severity, which is not the same as sorting by what will actually be used against you.

The correction is exploitation data. CISA maintains the Known Exploited Vulnerabilities catalog as the authoritative record of flaws confirmed to have been exploited in the wild, and tells organizations to feed it into their prioritization rather than relying on severity scores alone.

Deadlines are published too. CISA's Binding Operational Directive 26-04 sets remediation timelines for federal civilian agencies that start at three days, and the four variables it uses to pick each timeline are exactly the four a private company should use: is the asset publicly exposed, is the flaw on the KEV list, can exploitation be automated, and does it hand over partial or total control. The directive binds federal agencies. The logic is free for anyone.

Vulnerability Scanning Tools

The market splits cleanly. Nessus, Qualys and Rapid7 InsightVM are the general purpose commercial scanners most organizations end up on, all three built around a network scanner plus agents and a management console. OpenVAS is the open source equivalent and is genuinely capable if you have someone to run it. For web applications, Burp Suite and OWASP ZAP dominate testing work and Acunetix and Invicti sell the automated version. Nmap is not a vulnerability scanner but is the tool everyone uses to answer the prior question of what is actually listening.

OWASP's vulnerability scanning tools list is the vendor neutral catalog worth reading before any purchase, precisely because it takes no position on which is best.

Choosing between them matters far less than buying committees assume. Comparisons between the major commercial scanners come down to reporting, integrations and price, and any of them finds the flaw that gets you breached. The variable that predicts outcomes is whether anyone reads the output every month and has the authority to make systems restart.

Is Vulnerability Scanning Illegal?

Scanning systems you own or have written permission to test is legal. Scanning systems belonging to somebody else, without their authorization, is not, and in the United States it can fall under the Computer Fraud and Abuse Act as well as state computer crime statutes.

The distinction is authorization, not intent or technique. It does not matter that the scan was read-only, that you meant to be helpful, or that the service answered you. Three situations catch people out. Scanning a supplier, or a company you are considering acquiring, requires their written consent, and reconnaissance from public sources is the alternative when consent is not available. Scanning your own systems inside a cloud provider is governed by that provider's testing policy. And scanning an employer's network is authorized by the employer, in writing, not by your job title.

What a Vulnerability Scan Will Not Find

A scanner reports known flaws in what it can see, and every word in that sentence is a limit.

• The asset nobody told it about. The forgotten server, the shadow cloud account, the system inherited in an acquisition. Discovery helps, but a scanner only sweeps the ranges you configured.
• Business logic flaws. A checkout that lets you set a negative quantity is a serious vulnerability and no scanner will ever report it, because nothing about it is a known flaw in a known product.
• Stolen or reused credentials. An attacker signing in with a valid password triggers nothing. There is no vulnerability to find.
• Social engineering. The call that talks an employee into approving a login prompt defeats a fully patched estate.
• Zero day flaws. By definition not yet in the database. This is the limit people cite most and it matters least, because the overwhelming majority of intrusions use flaws that were published and left unpatched.