How to Scan an IP Address for Vulnerabilities?

If you want to know how to scan an IP address for vulnerabilities, the process goes beyond checking whether a few ports are open. A proper assessment verifies the correct and authorized target, identifies reachable TCP and relevant UDP services, fingerprints the software behind them, runs vulnerability-specific checks, validates important findings, prioritizes confirmed weaknesses, applies the right remediation, and rescans the same IP to verify the fix. The scan location also matters because external and internal scans provide different views of exposure.

Before You Scan: Make Sure You Have the Right IP Address

Before opening a vulnerability scanner, confirm exactly which address you intend to test. A public IP, private IP, and IPv6 address can all be valid scan targets, but they provide different views of the environment.

If you scan the public IP of a router, firewall, NAT gateway, or load balancer, you are assessing what is visible through that public endpoint. You are not automatically vulnerability-scanning every internal workstation or server behind it.

If you need a deeper explanation of the concept itself before following this procedure, see our guide to what an IP vulnerability scan is.

How to Scan an IP Address for Vulnerabilities

The process below separates discovery from actual vulnerability detection. That distinction matters because discovering an open port or identifying software does not by itself prove that the target is vulnerable.

Step 1: Confirm Authorization and Define the Scan Scope

Before sending scan traffic, document exactly what you are permitted to test. This is especially important for production systems, customer environments, hosted infrastructure, and any third-party asset.

At minimum, record:

• Target: the exact IPv4 or IPv6 address.
• Ownership: who owns or controls the address.
• Authorization: who approved the assessment.
• Vantage point: whether the test is external or internal.
• Scan window: when scanning is permitted.
• Authentication: whether credentialed testing is allowed.
• Excluded activity: any intrusive, exploitative, or denial-of-service checks that are prohibited.

A simple scope record could look like this:

Target: 203.0.113.10
Scope: Single public IPv4 address
Vantage point: External
Authorization: Written approval from asset owner
Allowed testing: Discovery and non-destructive vulnerability scanning
Excluded: Exploitation and denial-of-service testing

Keeping the scope explicit helps prevent accidental scanning of unrelated infrastructure and makes the results easier to reproduce later.

Step 2: Check Whether the IP Is Reachable

Start by checking whether the target responds to host-discovery probes.

nmap -sn 203.0.113.10

With -sn, Nmap performs host discovery without proceeding to its normal port scan.

A responsive host could produce output similar to:

Nmap scan report for 203.0.113.10
Host is up.

But a missing response does not necessarily prove that the machine is offline. Firewalls can block discovery traffic while still allowing real services such as HTTPS or SSH.

What if the server is online but Nmap reports it as down?

If you control the server and already know it is online, you can tell Nmap to skip its normal host-discovery decision:

nmap -Pn 203.0.113.10

The -Pn option does not bypass a firewall. It simply tells Nmap to treat the supplied target as active and continue with the scan rather than stopping because discovery probes received no response.

Step 3: Find the Open TCP Ports

Once you have the correct target, identify which TCP services are reachable from your scan location.

nmap 203.0.113.10

A standard Nmap scan checks 1,000 commonly used TCP ports rather than all 65,535 possible TCP ports.

An illustrative result might look like this:

PORT    STATE     SERVICE
22/tcp  open      ssh
80/tcp  open      http
443/tcp open      https
445/tcp filtered  microsoft-ds

These states describe what the scanner sees from its current network location. A port can appear open from inside the network and filtered from the public internet.

When should you scan all TCP ports?

If broader coverage is required by the approved assessment scope, Nmap can scan the complete TCP port range:

nmap -p- 203.0.113.10

On systems where raw-packet privileges are available, an explicit SYN scan can also be used:

nmap -sS -p- 203.0.113.10

Do not automatically apply the most aggressive scan configuration to production infrastructure. Scan depth should match the authorized scope and operational tolerance of the environment.

Step 4: Check Relevant UDP Services

A TCP-only assessment can give an incomplete picture. Infrastructure may also expose services over UDP, including DNS, SNMP, NTP, and some VPN protocols.

If these protocols are relevant to the system being assessed, you can test selected UDP ports:

nmap -sU -p 53,123,161,500,4500 203.0.113.10

An example result could look like:

PORT     STATE          SERVICE
53/udp   open           domain
123/udp  open|filtered  ntp
161/udp  closed         snmp

UDP results require different interpretation from TCP. Many UDP applications do not respond to unexpected packets, and firewalls can silently discard the traffic. In both cases, the scanner may receive no response and return open|filtered.

That result should not automatically be treated as confirmation that the UDP service is running.

Step 5: Identify the Services and Software Versions

A port number alone does not provide enough evidence for vulnerability assessment. The next step is to identify what is actually listening behind the exposed ports.

nmap -sV -p 22,80,443 203.0.113.10

A fictional result could look like this:

PORT    STATE SERVICE VERSION
22/tcp  open  ssh     OpenSSH ...
80/tcp  open  http    nginx ...
443/tcp open  https   nginx ...

Version detection sends additional probes and attempts to determine the real protocol, software product, and version instead of assuming a service based only on the port number.

The difference is important:

22/tcp open

tells you that something accepts connections.

22/tcp open ssh OpenSSH [detected version]

provides substantially more evidence that can be checked against vendor advisories and vulnerability data.

Step 6: Run a Vulnerability Scanner Against the IP

Port discovery and version detection tell you what appears to be exposed. The next stage runs actual vulnerability checks against those services and configurations.

A vulnerability scanner can combine service fingerprints, protocol-specific checks, vulnerability feeds, configuration tests, and product-specific detection logic to determine whether known weaknesses are likely to affect the target.

Option A: Scan the Public IP With ScanTitan

For an authorized public IPv4 or IPv6 target, you can enter the address into the ScanTitan IP Vulnerability Scanner.

The scanner can combine signals such as:

• reachable ports
• network services
• software and version evidence
• known vulnerability matches
• configuration findings
• severity data
• exploitation context where available
• remediation information

A finding could conceptually contain:

Target: 203.0.113.10
Port: 22/tcp
Service: SSH
Product/version: Detected
Finding: CVE-XXXX-XXXX
Severity: High
Evidence: Scanner-specific result

Do not move straight from that output to patching. The next step is to verify that the finding actually applies.

Option B: Scan the IP With Greenbone/OpenVAS

If you want an independent scanner workflow, Greenbone provides a straightforward way to create an IP target and run a vulnerability task.

Using the Task Wizard:

1. Open Scans → Tasks.
2. Select Task Wizard.
3. Enter the authorized IP address or hostname.
4. Select Start Scan.
5. Wait for the task to complete.
6. Open the generated report and review the findings.

For more control, you can create the target and task separately:

Configuration
→ Targets
→ Create Target
→ Enter IP address
→ Save

Scans
→ Tasks
→ New Task
→ Select Target
→ Save
→ Start

Greenbone supports individual IP addresses as well as broader ranges and CIDR targets. Its current documentation also distinguishes between checks that directly test a target and vulnerability prediction based mainly on product or version information.

This is why a useful workflow treats Nmap discovery and a vulnerability-scanning platform as complementary rather than assuming one command replaces an entire vulnerability assessment.

Step 7: Validate the Vulnerability Findings

A scanner finding should trigger investigation, not automatic remediation. High-priority findings should be checked against the actual software, configuration, vendor information, and evidence returned by the scanner.

A version-based vulnerability match can follow a pattern like:

Detected software version
↓
Version falls inside known affected range
↓
Scanner reports CVE

But you should still ask:

• Was the product identified correctly?
• Was the security fix backported?
• Is the vulnerable feature enabled?
• Does the current configuration expose the vulnerable behavior?
• Did the scanner directly test the weakness or infer it from version information?

This is one reason scanner evidence matters as much as the vulnerability identifier itself.

Step 8: Prioritize the Confirmed Findings

Do not automatically sort the report by CVSS and fix vulnerabilities from the highest score downward. Severity is useful, but it is only one input to remediation priority.

A better sequence is:

Is the finding confirmed?
↓
Is the affected service reachable?
↓
Is exploitation in the wild known?
↓
How likely is exploitation?
↓
How severe is the weakness?
↓
How important is the asset?
↓
What controls already reduce the exposure?

CVSS communicates vulnerability severity. FIRST explicitly distinguishes CVSS Base severity from a complete assessment of organizational risk.

CISA KEV indicates that CISA has evidence that a vulnerability has been exploited in the wild. KEV membership is useful prioritization evidence, but it does not mean that your particular host is being attacked at that moment.

EPSS estimates the probability that exploitation activity for a published CVE will be observed in the wild during the next 30 days.

The final decision still needs local context such as internet exposure, asset importance, reachability, compensating controls, and the function of the affected service.

Consider this deliberately simplified example:

The higher CVSS score does not automatically prove that Finding A deserves remediation before Finding B. Prioritization should combine the vulnerability with real exposure and asset context.

Step 9: Remediate the Confirmed Vulnerabilities

The appropriate fix depends on the type of issue the scan uncovered.

Step 10: Rescan the Same IP and Confirm the Fix

A remediation is not complete simply because somebody installed a patch or changed a configuration. Run the vulnerability scan again and verify that the original issue is no longer detectable.

For a meaningful comparison, keep the important conditions consistent:

• same IP address
• same relevant scan vantage point
• comparable scan configuration
• same affected service
• same vulnerability check

For example:

BEFORE

Target: 203.0.113.10
Port: 443/tcp
Service: HTTPS
Finding: CVE-XXXX-XXXX
Status: Detected

After remediation:

AFTER

Target: 203.0.113.10
Port: 443/tcp
Service: HTTPS
Finding: CVE-XXXX-XXXX
Status: Not detected
Service availability: Working

Notice that port 443 is still available. The acceptance criterion is that the vulnerable condition is no longer detected while the required service continues to work.

What If the IP Appears Down but You Know the Server Is Online?

A live host can ignore the discovery probes sent by a scanner. For example, a firewall might allow HTTPS on TCP 443 while silently dropping ICMP or other discovery traffic.

If you own the system and already know it is online, use:

nmap -Pn 203.0.113.10

Or limit the next check to known relevant ports:

nmap -Pn -p 22,80,443 203.0.113.10

This tells Nmap not to rely on its normal discovery stage before scanning. It does not make filtered services visible and it does not bypass access controls.

If the required service still appears filtered, investigate the firewall, routing path, cloud security group, host firewall, or other network controls between the scanner and the target.

Can Nmap Scan an IP Address for Vulnerabilities?

Nmap can contribute substantially to vulnerability assessment, but its role should be described accurately.

It is especially useful for:

• host discovery
• TCP and UDP port scanning
• service identification
• software and version fingerprinting
• targeted Nmap Scripting Engine security checks

The Nmap Scripting Engine includes vulnerability-oriented scripts, but a command such as:

nmap --script vuln 203.0.113.10

should not be treated as a universal vulnerability-assessment recipe. The vuln category contains different scripts with different behaviors, and some NSE checks can be intrusive.

For a structured vulnerability-management process, Nmap is best treated as strong discovery and service-enrichment evidence alongside a vulnerability scanner that provides broader detection logic, reporting, evidence, prioritization, and rescan history.

External vs Internal IP Scanning: Which One Should You Use?

The right scan location depends on the security question you want to answer.

If your question is “What can somebody on the internet reach at this public IP?”, use an external scan.

If your question is “What vulnerabilities exist on this private server inside my network?”, use an internal scanner that has network access to the address.

Many environments benefit from both because the two scan locations reveal different portions of the attack surface. For a deeper comparison, see internal vs external vulnerability scanning.

Common Mistakes When Scanning an IP Address

A technically successful scan can still produce a misleading assessment if the scope or results are interpreted incorrectly.

The Complete IP Vulnerability Scanning Workflow

The full process can be summarized as:

Confirm the correct IP and authorization
↓
Choose the external or internal vantage point
↓
Check target reachability
↓
Enumerate relevant TCP ports
↓
Check relevant UDP exposure
↓
Identify services and software versions
↓
Run vulnerability-specific scanning
↓
Validate important findings
↓
Add exploitation and asset context
↓
Remediate confirmed weaknesses
↓
Rescan the same target
↓
Verify that the finding is closed

A useful IP vulnerability assessment is not the one that generates the longest report. It is the one that identifies applicable weaknesses, provides enough evidence to validate them, leads to a specific remediation, and confirms afterward that the weakness is no longer detectable.

Frequently Asked Questions