Nmap for Defenders: Safe Asset Discovery Guide

Most organisations cannot say with confidence which hosts and services are reachable on their own networks, and Nmap is the most widely used free tool for finding out. This guide is for network, vulnerability management and SOC teams scanning assets they own or are authorised in writing to test, and covers Nmap strictly from the defender's side: discovering your own assets, checking that firewall rules do what the change record says, and validating exposure before an attacker does. It explains which options are safe for production, how to run scans under change control, how to handle results, and what the Nmap Public Source License means. Evasion and exploitation are out of scope.

Key takeaways

Authorisation comes first. Scan only assets you own or have written permission to test. Scanning systems without permission may be unlawful under computer misuse laws such as the UK Computer Misuse Act 1990 or the US Computer Fraud and Abuse Act, and Nmap's own legal guidance advises written permission before any scan.
Discovery is a control, not a project. CIS Controls v8.1 Safeguard 1.3 expects an active discovery tool to run daily, and Nmap with XML output and Ndiff is a simple way to meet it.
Safe defaults are documented. SYN scans, default timing or -T2 polite, narrow port lists and no scripts on fragile systems are the Nmap project's own advice for avoiding crashes.
The value is the difference. A scan only matters when compared with what should be there: the asset inventory, the firewall rule base and the previous scan.
Results are sensitive data. A scan file is a map of every listening service on your network. Store, share and delete it as you would a vulnerability report.

What the tool does

Nmap ("Network Mapper") sends probes to target addresses and interprets the replies to work out which hosts are up, which ports are reachable and, optionally, what software is listening. Its companion tools are Zenmap (a graphical front end) and Ndiff (scan comparison). The options below are the benign discovery features from the Nmap Reference Guide that defenders use most.

Core functions

Function	Main options	What it tells a defender
List targets without sending packets	`-sL`	Expands a range and does reverse DNS only: useful for checking scope before a scan
Host discovery only	`-sn`	Which addresses respond. Privileged default probes are ICMP echo, TCP SYN to 443, TCP ACK to 80 and ICMP timestamp; on local Ethernet Nmap uses ARP (IPv4) or Neighbor Discovery (IPv6)
Skip discovery	`-Pn`	Treats every address as up: needed where hosts drop ping, slower on sparse ranges
TCP SYN scan	`-sS`	Default with raw packet privileges; reports port state without completing the connection
TCP connect scan	`-sT`	Used without raw privileges; completes connections, so targets are more likely to log it
UDP scan	`-sU`	DNS, SNMP, NTP and similar; slow because closed ports reply with rate-limited ICMP
Service and version detection	`-sV`, `--version-intensity 0-9` (default 7), `--version-light`	Identifies the product and version behind an open port using the `nmap-service-probes` database
Target files and exclusions	`-iL`, `--exclude`, `--excludefile`	Scan exactly the approved scope and keep fragile or out-of-scope ranges out
Machine-readable output	`-oX`, `-oA`, `--reason`	XML for tooling (the guide calls it the preferred format for programs); `--reason` records why each port has its state

Reading port states

Nmap reports six states; the two not shown, unfiltered (ACK scan only) and closed|filtered (idle scan only), do not arise in routine defender scans. Read the rest precisely: "filtered" is not "closed" when proving a firewall rule.

State	Meaning (Nmap Reference Guide)	Defender reading
open	An application is accepting connections or datagrams	Must match an approved service; otherwise it is a finding
closed	Reachable, but nothing listening	The host is reachable through the filter: a firewall rule may be broader than intended
filtered	A filter prevents probes reaching the port	Expected result for a blocked port
open\|filtered	Cannot tell open from filtered (common with UDP)	Confirm with version detection or from inside the segment

The Nmap Scripting Engine (NSE) extends Nmap with scripts grouped into categories. The safe category contains scripts not designed to crash services or exploit holes; intrusive, brute, dos, exploit and fuzzer scripts are not routine defender tools, and the external category sends data to third-party services. Even -sC (the default category) includes some scripts the Nmap documentation says should not be run without permission. Keep scripts out of scheduled production scans unless individually approved.

Defender use cases

Asset discovery: run daily host discovery (-sn) across every internal range and compare live addresses with the CMDB. CIS Safeguard 1.3 expects active discovery at least every 24 hours and Safeguard 1.2 expects unauthorised assets to be dealt with weekly. See the Asset Inventory and CMDB Security Guide.
Exposure validation: scan your internet-facing ranges from outside, across all 65,535 TCP ports and the common UDP ports, and confirm that only published services answer. The MongoBleed exposure is the illustration: Censys reported more than 87,000 potentially vulnerable MongoDB instances reachable on TCP 27017, a port that should almost never face the internet. See the Attack Surface Management Guide.
Verifying firewall rules: after a change, scan from the source zone the rule is meant to restrict. A port that should be blocked must show filtered; closed means the packet got through. Pair this with the Firewall Rule Review Checklist.
Segmentation testing: scan from a workstation VLAN towards server, management and OT zones to prove that segmentation holds. See the Network Segmentation Guide.
Service and version inventory: -sV results feed CPE matching in the vulnerability programme. See the CVE, CWE and CPE Guide.
Change detection: keep XML output from scheduled scans and run Ndiff between runs. Ndiff reports hosts coming up or going down and ports changing state, in text or XML, so a new listener can raise a ticket automatically.

Unexpected open ports are findings in their own right, before any CVE is considered. The Network Ports and Protocols Security Guide lists the ports that should trigger immediate review.

Deployment and safe use

Authorisation and legal position

Nmap's legal guidance says the legality of scanning depends on jurisdiction and facts, recommends written permission from the network owner, places that permission in the statement of work for penetration tests, and for internal scanning advises confirming that it is within your job duties. For defenders this translates into a standing scanning authorisation signed by the asset owner or CISO, listing ranges, source addresses, schedules and permitted options. Third-party and SaaS assets are out of scope without the provider's written agreement.

Safe settings for production

Setting	Use	Why
`-sS` with default timing (`-T3`)	Routine internal and external scans	Nmap's guidance recommends SYN scans and default or polite timing to reduce crash risk
`-T2` (polite)	Slow links, legacy and fragile segments	Serialises probes with 0.4 seconds between them; about ten times slower than default
`--max-rate`	Any shared or WAN link	Caps packets per second across the scan, giving a predictable network load
`--host-timeout`	Large ranges	Stops one slow host holding up the schedule; timed-out hosts have no results, so report them
Narrow port lists (`-p`) and `--excludefile`	Sensitive systems	The Nmap guidance advises limiting ports and hosts on fragile devices
No `-sV`, `-O` or scripts	OT, medical, printers, old embedded devices	Version detection, OS detection and scripts are named by Nmap as the options to avoid on sensitive systems

Version detection already excludes TCP 9100 by default because some printers print any data sent to it. Overriding that with --allports needs a recorded reason. For OT and safety systems, prefer passive discovery and vendor-approved methods; see the OT Asset Visibility Guide.

Rollout

Define scope: build target and exclusion files from IPAM and the CMDB, with owners for each range. Run -sL to confirm the expansion is what you expect.
Agree authorisation and windows: record ranges, scanner source addresses, times and options in a change record under the Change Management Policy Template. Tell the SOC and network operations.
Pilot: scan one low-risk subnet with host discovery only, then a SYN scan of the top ports, and check device and link health with the owners.
Extend in rings: add server ranges, then user ranges, then external ranges. Keep fragile segments on -T2 with narrow port lists, or excluded.
Automate: run scheduled scans from a dedicated, hardened scanner host, write -oX output with timestamped filenames and diff each run with Ndiff.
Roll back: if a device misbehaves, stop the job, add the address to the exclusion file, inform the owner and record the incident. Resume with --resume only after the cause is understood.

Data handling of results

Classify scan output: XML and normal output list every live host, open port and software version. Treat them as confidential and restrict access to the teams that need them. See the Data Classification Guide.
Store centrally, not on laptops: push results to the vulnerability management platform or a restricted store.
Set retention: keep enough history for Ndiff comparison, then delete. See the Data Retention and Secure Deletion Guide.

Licensing

Nmap is distributed under the Nmap Public Source License (NPSL), which the project describes as based on the GNU GPLv2 with additional terms, conditions and exceptions. A stated goal of the licence is to prohibit redistribution and use of Nmap within proprietary hardware and software products; vendors that want to embed Nmap buy the Nmap OEM licence, which includes support and indemnification. Using Nmap internally to scan your own networks is the use case the licence is meant to keep free, but anyone building Nmap into a product, appliance or managed service should read the full licence text and take legal advice. Nmap 7.90 to 7.92 may optionally be used under the earlier 7.80 terms.

Detection and hardening value

Attackers run the same discovery: MITRE ATT&CK lists T1046 Network Service Discovery and T1595.001 Scanning IP Blocks. Scanning yourself first shows what they would see.

Register, do not blind: give the SOC the scanner addresses and windows so authorised scans are recognised, but keep alerting on scans from any other source and on scans from the scanner outside its window. See the SIEM Guide.
Harden from findings: each unexpected listener should end in one of three outcomes: service removed, access restricted, or documented exception. NIST SP 800-53 CM-7 Least Functionality is the control behind it.

Metrics

Discovery coverage: percentage of routed internal ranges scanned in the last 24 hours (CIS 1.3).
Unknown assets: number of live hosts not in the CMDB, and median days to resolve (target under 7, per CIS 1.2).
Unexpected external services: count of internet-reachable ports not on the approved list, trending to zero.
Rule verification rate: percentage of firewall changes with a post-change scan attached to the change record.
Scan safety: scan-related device faults per quarter.

Framework mapping

Framework	Reference	How Nmap scanning supports it
NIST CSF 2.0	ID.AM-01, ID.AM-03	Hardware inventory and authorised network communication are compared with what scans actually find
NIST CSF 2.0	ID.RA-01, DE.CM-01	Exposures identified and recorded; network services monitored for change
NIST SP 800-53 Rev. 5	CM-8, CM-7, RA-5, CA-8	Component inventory, least functionality, vulnerability monitoring and scanning, penetration testing
CIS Controls v8.1	1.1, 1.2, 1.3, 7.6	Asset inventory, unauthorised assets, daily active discovery, monthly external scanning
ISO/IEC 27001:2022 Annex A	5.9, 8.8, 8.20	Inventory of assets, management of technical vulnerabilities, network security
MITRE ATT&CK v20	T1046, T1595.001	The adversary behaviours that your own scanning anticipates and your detection should catch

Alternatives

Option	Strength	Trade-off	Choose when
Nmap	Accurate port states, version detection, XML output, Ndiff	Slower than stateless scanners on very large ranges	Internal discovery, rule verification and exposure checks for most organisations
Stateless internet-scale scanners (for example Masscan, ZMap)	Very fast across large address blocks	Less detail per port; high packet rates can harm networks if not capped	Large external ranges, followed by Nmap on the hosts that answer
Vulnerability scanners (for example OpenVAS)	Discovery plus vulnerability tests and reporting	Heavier, more intrusive and slower	When you need findings against CVEs, not just exposure. See the OpenVAS Guide.
Passive discovery (network monitoring, DHCP and switch data)	No packets sent to targets	Only sees what talks on monitored links	OT and fragile networks; CIS 1.4 and 1.5
External attack surface services	Outside-in view, continuous, includes DNS and certificates	Third party holds your exposure data; scope must be agreed	Large or fast-changing internet estates

Small organisations: a single scanner host running scheduled Nmap scans with Ndiff, plus a monthly external scan, covers most of the value. Large organisations: distribute scanners per zone, feed XML into the vulnerability management platform and asset inventory, and combine active scanning with passive discovery. See the Vulnerability Management Guide.

Common failure patterns

Scanning without a signed scope: a well-meant scan of a partner range or a cloud provider's shared address is still unauthorised. Keep target files under change control.
Reading closed as blocked: a post-change scan that returns closed means the firewall passed the packet. Rule verification must look for filtered.
Top-ports only on the internet edge: management services moved to high ports are missed. Scan all TCP ports on exposed addresses and do not drop UDP.
Aggressive options on fragile devices: version detection, OS detection and scripts on printers, PLCs or old appliances cause the outages that get scanning banned. Use exclusions and polite timing.
Results nobody owns: scans run, files accumulate, and new listeners are never ticketed. Every diff needs an owner and a remediation route.

Practitioner checklist

Hold a written scanning authorisation listing ranges, source addresses, windows and permitted options.
Build target and exclusion files from IPAM and the CMDB, and check them with -sL.
Run daily host discovery across internal ranges and reconcile new hosts within seven days.
Scan all TCP ports and common UDP ports on internet-facing addresses at least monthly.
Use SYN scans with default or polite timing, --max-rate on shared links, and no version detection, OS detection or scripts on fragile systems.
Attach a post-change scan from the restricted zone to every firewall change.
Write XML output, diff each run with Ndiff and ticket every unexpected change.
Classify scan results as confidential, store them centrally and apply a retention period.
Register scanner addresses with the SOC and alert on scanning from any other source.
Read the NPSL before embedding Nmap in any product or managed service.

Nmap for Defenders Guide: Asset Discovery and Exposure Checks Done Safely