What Is Vulnerability Scanning? How It Works and What It Finds

Vulnerability scanning is an automated check for known security weaknesses in systems, networks, and applications. A scanner compares what it finds against a database of known flaws and reports what needs fixing.

A scan tells you what might be wrong. It doesn’t tell you what an attacker can actually do with it. A scanner can flag a missing security patch on a server, but it won’t tell you whether that server is reachable from the internet, whether a firewall blocks the attack, or whether someone is already exploiting the flaw. Those answers take human judgment and, sometimes, a deeper test.

This guide explains how scans work, the difference between authenticated and unauthenticated scans, how to read severity and exploit-likelihood scores, where scanning can cause harm, and how to turn a long report into work your team can finish. If the word “vulnerability” is new to you, start with our overview of software vulnerabilities in cybersecurity.

How Vulnerability Scanning Works

Most scans follow the same basic loop. Knowing the loop helps you set realistic expectations.

1. Find the assets. The scanner discovers the devices, servers, and services it’s pointed at. If you don’t know what you own, the scan will miss things.
2. Identify what’s running. It checks which ports are open and which software and versions are installed.
3. Compare against known weaknesses. It matches that information against a database of known vulnerabilities, such as the public CVE list, and runs checks for common misconfigurations.
4. Validate the findings. Some results are wrong. A scanner that reads a software banner might flag a system as vulnerable even though the vendor already patched it. More accurate data, such as a login with local access, helps sort out these false positives.
5. Report. The scanner produces a list of findings, usually with severity ratings, affected assets, supporting evidence, and suggested remediation.
6. Fix and rescan. Your team patches the problem, changes a setting, or documents why the risk is accepted for now. Then you scan again to confirm the fix worked.

The loop repeats. A scan is a snapshot, and your environment changes every week as people add devices, deploy code, and install updates.

What Vulnerability Scanners Look For?

Scanners usually check for a handful of common problem types. The exact list depends on the tool and what it’s pointed at.

• Missing security patches in operating systems and applications.
• Outdated software versions with publicly known flaws.
• Misconfigurations such as default passwords, unnecessary open services, or overly broad file share permissions.
• Weak encryption settings and expired certificates.
• Exposed services on systems that face the internet.
• Web application issues such as input validation flaws, for scanners built to test web apps.

The target changes what you’ll typically see:

No single scan sees everything. Each method has limits based on coverage, credentials, network position, and level of interaction. A useful program combines more than one scan type.

Authenticated vs. Unauthenticated Scans

The biggest setup decision is whether the scanner logs in. This choice shapes what the scan can see and how accurate the results are.

Unauthenticated Scans

An unauthenticated scan runs without credentials. The scanner probes the target from the outside, showing which services and weaknesses are visible without internal access. This is useful for checking the external attack surface, but it cannot reliably inspect every software package or local setting.

The limitation is that the scanner can only see what’s visible from outside. It has to guess about the software running behind the door, and guesses create false positives and missed problems.

Authenticated Scans

An authenticated scan, sometimes called a credentialed scan, uses valid login details. The scanner reads the system from the inside: installed package versions, patch levels, registry settings, and local configuration files.

The main benefit is better visibility into the system. Credentialed checks can read installed package versions, patch levels, and configuration details instead of relying only on network banners. This generally improves accuracy, although it does not eliminate false positives or false negatives. Tenable explains credentialed vulnerability scanning in its documentation.

Authenticated scans have trade-offs. Depending on the scanner, checks, and target, they can use additional system resources or affect performance. They also require secure credential storage, suitable permissions, and careful account management. Test the configuration first and schedule resource-intensive scans during an approved maintenance window.

Side-by-Side Comparison

Most teams should use both. The outside view shows what an attacker can see, while the inside view reveals installed software and local settings. Differences between the two results can point to assets or weaknesses that need further investigation.

If credential sharing is a concern, use a dedicated service account with only the permissions required for the scan. Store its credentials securely, rotate them according to policy, and avoid using a shared administrator password.

A useful operational check is the authentication success rate: the percentage of scheduled credentialed scans that successfully log in and complete their checks. Track failures by asset and investigate them; otherwise, a scan labeled authenticated may provide little more than an outside view.

External, Internal, Network-Based, and Agent-Based Scans

Scans also differ by where they start and how they reach devices.

External scans focus on the network perimeter and the systems exposed to the internet. They show what an outside attacker could target first.

Internal scans run from inside your network. They matter just as much because an attacker who gets in through a phishing email or a stolen password may move around internally. Internal scanning helps identify weaknesses that an external scan cannot see.

Network-based scanning runs from a scanning appliance or host and reaches targets over the network. One scanner can cover many hosts, but it only sees what’s online and reachable at scan time. A laptop that’s off or roaming may never appear in the results.

Agent-based scanning installs a small piece of software on each device, which reports back. This catches roaming laptops and remote workers. If your team already uses endpoint management tools, agent-based scanning can build on that foundation.

Understanding Severity: CVSS and the NVD

Most scan reports rate findings with the Common Vulnerability Scoring System (CVSS), which assigns a severity score from 0.0 to 10.0. The commonly used CVSS severity bands are:

Many scanners use the National Vulnerability Database (NVD), maintained by NIST, as one source of vulnerability information. NVD records can include CVSS severity scores, Common Weakness Enumeration (CWE) classifications, and Common Platform Enumeration (CPE) product information. An NVD record is not proof that a particular system is vulnerable; teams still need to confirm the affected product, version, configuration, and vendor guidance.

NVD Coverage and Scoring

NVD enrichment and scoring coverage can change as the database processes a growing number of CVE records. A newly published CVE may not immediately have a complete NVD analysis or NIST-assigned CVSS score. Do not treat a missing score as evidence that a vulnerability is harmless. Check the CVE record, the affected vendor’s security advisory, and other reliable threat information before assigning priority.

The practical lesson is that a missing score doesn’t mean a flaw is low risk. Check the vendor advisory and the CVE record, then make a judgment call. Confirm the current NVD process directly on NIST’s site, because the details of this change are still moving.

Severity Isn’t the Same as Risk

A high CVSS score measures the potential severity of a vulnerability. It does not show whether attackers are exploiting it in the wild or whether your particular system is exposed. That is why zero-day vulnerabilities and actively exploited flaws may need faster attention than a score alone would suggest.

Adding Exploit Likelihood: EPSS and KEV

Two additional data sources help answer the question CVSS can’t: how likely is this flaw to be used against us?

EPSS (Exploit Prediction Scoring System), maintained by FIRST, estimates the probability that a publicly known vulnerability will be exploited in the wild in the next 30 days. Its score ranges from 0 to 1. EPSS is a probability estimate, not confirmation that an attack has occurred.

EPSS is a population-level estimate, not a statement about your specific systems. Your actual exposure still depends on whether the affected product is present, reachable, and configured in a vulnerable way. A low EPSS score doesn’t prove that a flaw is safe; it indicates a lower estimated probability of exploitation over the model’s forecast window.

CISA’s Known Exploited Vulnerabilities (KEV) Catalog lists vulnerabilities that CISA has identified as exploited in the wild. Unlike EPSS, KEV is not a prediction. It is evidence of known exploitation and should be treated as an important prioritization signal. You can check the official CISA KEV Catalog.

A simple way to use all three signals:

• CVSS tells you how bad the flaw could be.
• EPSS tells you how likely it is to be used soon.
• KEV tells you whether it’s already being used.
• Your asset context tells you what happens if it’s exploited.

A Worked Example (Hypothetical)

The scenario below is illustrative, not a real case. It shows how the pieces fit together for a 50-person company with a public customer portal, an internal file server, a set of laptops, and a development server.

Step 1: The scan runs. An external scan finds an outdated web framework on the customer portal, with a CVE rated 9.8 under CVSS. An authenticated internal scan finds a missing patch on the file server with a score of 8.1, along with an outdated PDF reader on six laptops (medium severity). A banner-based check on a development server flags a high-severity library, too.

Step 2: Add context. The portal is internet-facing, so the external finding gets immediate attention. The CVE is also on the KEV list, which means it’s being used in real attacks. The file server holds payroll files, so it has high business impact even though it’s not reachable from the internet. The laptop findings are real but low urgency. The development server is not reachable from outside.

Step 3: Check the false positive. The team logs into the development server with a service account and runs a local check. The library was already updated in a recent deployment, and the banner was outdated. The scanner was wrong. The team marks the finding as a false positive, documents the evidence, and adds a note to the scanner’s exception list with a review date.

Step 4: Prioritize and assign.

1. Customer portal: Highest priority. It’s internet-facing and on KEV. The team patches within a few days, and the owner signs off on a short maintenance window.
2. File server: Next. It’s not exposed to the internet, but the payroll data raises the business stakes. The team patches within the week and checks whether any suspicious access appeared in the logs.
3. Laptops: Batch them into the regular patch cycle.
4. Development server: Closed as a false positive, with documented proof.

Step 5: Verify. The team rescans the portal, the file server, and the laptops. All three now come back clean on those checks. They keep the scan record for their next audit.

Notice what made the difference. The highest CVSS score was not the first fix in this example. The internet exposure and exploitation status moved the portal to the top. The file server’s score mattered less than its data. The false positive didn’t need a patch at all. That’s the kind of judgment a raw scan report can’t make for you.

Scanning Can Break Things

Vulnerability scanning sends traffic at your systems. Most of the time, that’s harmless. Sometimes it isn’t.

Operational technology (OT) and industrial systems need special care. Traditional IT scanners can disrupt industrial control systems that were not designed to handle active probing. Passive scanning, which observes network traffic without sending probes, may be a safer way to identify devices, although it can provide less detail. Coordinate any assessment with OT owners and equipment vendors before scanning.

Internet-connected programmable logic controllers (PLCs) and other operational technology can be attractive targets, but active scanning may also disrupt equipment that was not designed to handle aggressive probes. Keep these systems off the public internet unless there is a documented operational need and appropriate protection. Follow equipment-vendor guidance and coordinate any assessment with the OT owner.

For everything else, a few practical rules help:

• Schedule heavy scans for quiet hours or maintenance windows, especially authenticated scans that use more resources.
• Start with a small test group before you scan the whole environment with a new configuration.
• Check account lockout settings before an authenticated scan runs. A wrong password in the scanner’s configuration can lock out real users.
• Exclude fragile systems only with a documented reason, and make sure someone reviews those exclusions regularly.
• Agree on rules with the system owners before the scan starts, including who to call if something slows down.

Scanning Modern Stacks: Containers and Infrastructure as Code

Traditional scans focus on servers and endpoints. Many teams now also need to scan the things that build those systems.

Container images package an application with its operating system libraries and dependencies. A scanner can inspect these layers for known vulnerable packages, outdated dependencies, and sometimes exposed secrets. Scanning can happen during the build and again after deployment. That second check matters because a previously clean image can contain packages that become vulnerable as new flaws are disclosed.

Infrastructure as Code (IaC) describes servers, networks, and cloud resources in files such as Terraform templates or Kubernetes manifests. Scanners can flag misconfigurations in those files before anything is deployed. An open storage bucket or an overly permissive firewall rule is much easier to fix in a template than after deployment.

Open-source tools can make this practical for small teams. For example, Trivy can be added to a build pipeline to scan container images and Infrastructure as Code files before deployment. Teams can set policies for which findings should fail a build and which should create a ticket. Our article on importance of security testing in software development explains how this fits into a broader development process.

The main caution is about noise. Image scanners can report many low-severity findings in base images. Set a clear policy for what blocks a build, what creates a ticket, and what gets logged for later review. Otherwise, developers will learn to ignore the results.

Vulnerability Scanning vs. Penetration Testing vs. Vulnerability Management

These three terms get mixed up all the time, so it helps to separate them.

Vulnerability scanning is automated, broad, and repeatable. It looks for known issues across many systems and produces a list. It doesn’t try to prove that a weakness can be used to break in.

Penetration testing is more hands-on. A tester attempts to exploit weaknesses, within an agreed scope, to determine what an attacker could access or affect. Scanning identifies potential weaknesses at scale, while penetration testing investigates whether selected weaknesses can be exploited and what their impact could be. Our explainer on vulnerability scanning and penetration testing goes deeper. Teams can also review our guide to free penetration testing tools, but these tools still require skill and written authorization.

Vulnerability management is the ongoing program that uses scanning as one input. It covers finding assets, assessing risk, prioritizing, fixing, and verifying. Scanning feeds the program, but scanning alone doesn’t manage anything. If you’re comparing the terms, our guides on scanning vs. vulnerability management and vulnerability management vs. vulnerability assessment explain where each one fits.

How Often Should You Scan?

The minimum depends on your compliance obligations. Best practice usually goes further.

Scan more often than the minimum required by a compliance framework when your exposure, rate of change, or risk justifies it. Internet-facing assets and rapidly changing environments may need more frequent checks than a stable internal network.

Scans should also run after significant changes. Adding a server, opening a port, changing a firewall rule, or launching a new web application can create exposure that wasn’t present during the previous scan. A change-triggered scan supplements the regular schedule; it does not replace it.

For a small team without a formal compliance requirement, a reasonable starting point is an authenticated internal scan and an external scan of internet-facing systems, both at least monthly, plus extra scans after major changes. This is my practical suggestion, not a published standard. Adjust it based on how fast your environment changes and how much a breach would cost you. For more starting points, see our small business network security checklist.

PCI DSS and Other Compliance Requirements

If you handle payment card data, PCI DSS sets specific vulnerability-scanning requirements. The exact obligations depend on the applicable PCI DSS version, scope, and assessment context. Check the current PCI Security Standards Council documentation and confirm the requirements with your Qualified Security Assessor (QSA).

• External scans must be performed at least quarterly by an Approved Scanning Vendor (ASV) for the applicable PCI DSS external scanning requirement. Check the PCI Security Standards Council for the current standard and ASV program details.
• Internal scans are also required at least once every three months under the applicable PCI DSS vulnerability-scanning requirement. They do not have to be performed by an ASV.
• Authenticated internal scanning is required for applicable internal vulnerability scans. Credentials and scan coverage must be sufficient to identify vulnerabilities that unauthenticated checks could miss.
• Remediation and verification must follow the applicable PCI DSS requirements. Rescan after remediation to confirm that vulnerabilities have been addressed, and document unresolved findings and compensating controls where permitted.

Other frameworks ask for similar practices. The NIST Cybersecurity Framework is a useful reference if you’re building a broader program around scanning.

Measuring Whether the Program Works

A scanner that runs every week doesn’t prove your environment is getting safer. You need metrics that show outcomes, not just activity. Counting scans or total findings is easy, but those numbers can go up while your real risk stays the same.

Here are the metrics that matter most in practice:

• Scan coverage. The percentage of known assets scanned on schedule. Coverage gaps are visibility gaps: vulnerabilities on assets that have not been scanned may remain undetected. Compare scanner results with your asset inventory rather than relying on the scanner’s discovered-asset list alone.
• Mean time to remediate (MTTR) by severity. This measures how long it takes to fix findings after they are detected. Break it down by severity or risk level; a blended average can hide a serious backlog of critical issues.
• Percentage of high-risk findings overdue. Track the share of high-priority vulnerabilities that remain open beyond your remediation deadline. You can also monitor how long the oldest unresolved findings have been open.
• Authentication success rate. The share of scheduled authenticated scans that actually log in, as described earlier.
• Percentage of known exploited findings open. How many KEV-listed issues remain on your systems. This is a strong signal of real risk.

Remediation targets vary by organization, framework, and risk. Set deadlines based on severity, evidence of exploitation, exposure, and business impact rather than copying a vendor’s example as a universal rule. Track trends over time and explain exceptions clearly to leadership.

Reporting Results to Leadership

Executives rarely care about the number of findings. They care about business risk. Translate your scan data into questions they can act on.

Good questions include:

• How many internet-facing systems have open findings that are on the KEV list?
• How long do our most serious findings stay open, on average?
• Which business-critical systems have the most overdue high-risk issues?
• Are we improving compared with last quarter?

A useful dashboard focuses on exploited vulnerabilities that remain open, overdue high-risk findings, scan coverage, and remediation performance. That view helps leaders decide where to allocate time and budget. A raw count of thousands of low-severity findings rarely tells the whole story.

Also be honest about limits. If scan coverage is 80 percent, say so. A dashboard that looks clean because some systems aren’t being scanned can be more dangerous than no dashboard at all.

Common Mistakes to Avoid

These are the mistakes that come up most often.

• Scanning without an asset list. If you don’t know which systems exist, you’ll miss some of them. Build and maintain an inventory first.
• Treating every finding as equal. A low-severity issue on a test machine shouldn’t jump ahead of a critical flaw on a public server.
• Trusting the report blindly. Expect false positives. Expect some false negatives too, especially from unauthenticated scans.
• Skipping authenticated scans because logins are inconvenient. You’ll get a much less accurate picture of what’s on each machine.
• Scanning systems you don’t have permission to test. Get written authorization from the owner first, even for a quick check.
• Never rescanning. A finding marked “fixed” should be verified. Otherwise, you’re relying on memory.
• Ignoring new assets. Cloud resources, remote laptops, and short-lived containers appear and disappear. A schedule that doesn’t account for them leaves gaps.
• Scanning fragile systems without a plan. Especially in OT and legacy environments, check the risks before you start.
• Ignoring the scanner’s own exceptions. Exclusions and false-positive markings should have owners and review dates, or they quietly hide problems.

Choosing a Vulnerability Scanner

Scanners range from open-source tools to enterprise platforms. The right choice depends on your scope and goals, not on which brand you’ve heard of most often.

Start with these questions:

• What do you need to scan? Networks, web applications, cloud accounts, containers, and endpoints all have different requirements.
• Does it support authenticated scanning? This matters for accurate internal results.
• How does it handle false positives? Look for tools that let you validate findings and document known false positives so they don’t keep returning.
• Can it produce the reports you need? If you’re subject to PCI, external scans must come from an ASV, and your internal reports should match what your assessor expects.
• Does it fit your workflow? Check whether it connects to the ticketing and patching tools your team already uses.
• Where does it run? Some scanners are delivered as cloud services, while others run on your own hardware. Teams with strict data handling rules often prefer the second option.

If you’re looking at cloud environments, our roundup of the best cloud vulnerability scanning tools compares options built for that job.

Turning Results Into Action

A scan that nobody acts on is just an expensive report. Turning findings into fixes is where most of the value is.

1. Group findings by owner. Send each batch to the team that manages the affected system. Many findings stall because nobody knows whose job they are.
2. Validate the top items. Confirm the most serious findings are real before you escalate them. This saves time and builds trust in the scanner.
3. Prioritize with context. Combine severity with exposure, exploitation signals (EPSS and KEV), and business impact, as in the worked example above. Our guide to prioritizing vulnerability remediation goes deeper.
4. Set deadlines. Assign owners and realistic timelines for each priority level, and write them down.
5. Fix, mitigate, or accept. Apply the patch or configuration change where you can. If you can’t, add a compensating control and document who accepted the remaining risk and why.
6. Rescan and confirm. Verify the fix before you close the ticket.

Patching is often the biggest bottleneck. A documented automated patch management process can cut the time between finding a problem and fixing it. A clear vulnerability management policy helps everyone know who does what and how fast.

Frequently Asked Questions

Is vulnerability scanning the same as penetration testing?

No. Scanning is automated and looks for known weaknesses across many systems. Penetration testing is usually done by a person who tries to exploit weaknesses to show what an attacker could reach. Many organizations use both.

Do I need permission to scan a network?

Yes, if you don’t own or control the network. Get written authorization from the owner before you scan, even for a quick check. Scanning systems without permission can cause legal trouble and can disrupt services. Check your cloud provider’s rules too, since some restrict certain kinds of scanning.

How often should I run vulnerability scans?

It depends on your compliance obligations and how fast your environment changes. PCI DSS sets a quarterly minimum for certain scans. Best practice often goes further, and many teams move toward continuous scanning for internet-facing systems. Always scan after major changes.

Can a vulnerability scan slow down my systems?

It can. Authenticated scans in particular may increase resource usage. Schedule heavier scans during maintenance windows, and test a new configuration on a few systems before running it everywhere.

Is it safe to scan operational technology (OT) and industrial systems?

Be careful. Traditional IT scanners can disrupt industrial equipment that isn’t designed for active probing. Passive scanning, which observes traffic without sending probes, is often a safer option. Before any scanning, confirm the risk with the system owners and the vendor.

Does a clean scan mean my systems are secure?

No. A clean scan means the scanner didn’t find known issues within the scope it covered, at the time it ran. It can’t find flaws missing from its database, misconfigurations it doesn’t check, or assets you forgot to include. Treat a clean result as one signal among several.

Is a free vulnerability scanner enough?

It depends on what you need. A free tool can help a small team find known issues on a limited set of systems. If you need compliance reporting, such as external PCI scans, you’ll need an approved vendor. Also consider accuracy, support, and how well the tool handles your environment.

What’s the difference between CVSS and EPSS?

CVSS rates how severe a vulnerability could be based on its technical characteristics. EPSS estimates how likely it is to be exploited in the next 30 days. They answer different questions, so most teams use both, along with KEV data and their own asset context.

Conclusion

Vulnerability scanning shows where known weaknesses might be hiding in your environment. It’s a visibility tool, and its value depends on what you do next.

Start with a current asset list, since you can’t scan what you don’t know exists. Use authenticated scans where you can, and check that they actually log in. Read severity scores alongside exploitation signals and business context. Scan carefully, especially around fragile systems. Then prioritize, fix, and rescan until the important findings are closed.

If you’re not sure where to begin, a network security audit checklist is a practical place to map out what you need to cover before your first scan.

You May Also Like

Data Security & Privacy

Tokenization vs Encryption: Key Differences and Best Practices

Data Security & Privacy

How Encryption Works: A Practical Guide to Data Encryption Best Practices

Cybersecurity

Why Strong Passwords Are Important?

Data Security & Privacy

Endpoint Security vs Antivirus: Key Differences for Better Protection

Network Security

What is Penetration Testing and Why Is It Crucial for Your Cybersecurity Strategy?

Network Security

11 Best Free Penetration Testing Tools: Your Complete Guide for 2027

Cybersecurity

What Is Endpoint Management? A Practical Guide for Modern Teams

Data Security & Privacy

The Importance of Vulnerability Management and Attack Surface Management

Cybersecurity

Effective Strategies for Prioritizing Cybersecurity Vulnerability Remediation