Nmap ndiff: Compare Scan Results Over Time (2026)

Nmap’s ndiff is a surprisingly powerful tool for tracking changes in your network’s attack surface, but most people use it to just see what’s different. The real magic is in how it forces you to think about scan consistency as a primary security control.

Let’s see ndiff in action. Imagine you’ve just run a baseline scan on your internal subnet 192.168.1.0/24 using a fairly comprehensive Nmap script:

nmap -sV -sC -oN baseline.nmap 192.168.1.0/24

A week later, after some server patching and a few new devices were brought online, you run the same scan:

nmap -sV -sC -oN current.nmap 192.168.1.0/24

Now, to compare them, you’d typically use ndiff:

ndiff -output html -o comparison.html baseline.nmap current.nmap

This generates a nice HTML report. You’ll see sections for "New Hosts," "Deleted Hosts," "Changed Ports," and "New Ports." For example, you might see a new entry like this in the "New Ports" section:

Host: 192.168.1.15 (server1.internal)
  Port: 8443/tcp
    State: open
    Service: unknown
    Reason: syn-ack
    Version:

Or, if a critical service was accidentally stopped, you might see a port move from "open" to "closed" under "Changed Ports."

This basic comparison is useful for inventory and spotting obvious changes. But ndiff’s true power comes from understanding what constitutes a "change" and how to control it. The underlying mechanism is Nmap’s XML output format, which ndiff parses. Each host and port is represented as a structured record. ndiff compares these records based on a set of criteria.

The key to building a robust ndiff workflow is to ensure your Nmap scans are as deterministic as possible. This means:

1. Consistent Scan Options: Always use the exact same Nmap command-line arguments. Even minor variations (like adding -T4 vs. -T3 for speed) can lead to different results due to timing variations, which ndiff will flag as changes.
2. Stable Target Definitions: If you’re scanning a range, ensure the range itself doesn’t change unexpectedly. If you’re scanning a list of IPs, ensure that list is managed and version-controlled.
3. Version Control for Scan Data: Store your nmap output files (especially the XML or normal format used by ndiff) in a version control system like Git. This allows you to not only compare scans but also to track when specific changes occurred.

Let’s dive deeper into what ndiff is actually doing and how you can leverage it. ndiff compares two Nmap scan results and reports the differences. It identifies:

• New Hosts: IP addresses that appeared in the second scan but not the first.
• Deleted Hosts: IP addresses that were in the first scan but not the second.
• Changed Ports: Ports on a host that changed state (e.g., open to closed, closed to open).
• New Ports: Ports that are open on a host in the second scan but were not open in the first.
• Deleted Ports: Ports that were open in the first scan but are no longer open in the second.

The output can be directed to HTML, text, or XML. The HTML output is generally the most human-readable for quick reviews.

Consider the scenario where a firewall rule changes. A port that was previously open might now be closed. ndiff will clearly highlight this. If a new server is added to the network, ndiff will show it as a "New Host" and list all its open ports as "New Ports." Conversely, if a server is decommissioned, it will appear as a "Deleted Host."

The tool uses a fuzzy matching approach for hosts, meaning it tries to match hosts based on IP address primarily, but can also use MAC addresses if available in the scan data to improve accuracy. For ports, it matches by protocol and port number.

One of the most overlooked aspects of using ndiff effectively is understanding the impact of Nmap’s script engine (NSE). When you use -sC or specific scripts, the output of those scripts can change even if the underlying service hasn’t. For example, a web server might return a slightly different Server header or a new cookie might appear. ndiff will flag these as port changes. To mitigate this for services you want to monitor for availability, not just version changes, you might consider using a more targeted scan for those specific hosts with fewer scripts, or even a separate scan focused purely on port states.

The real power of ndiff emerges when you integrate it into a scheduled, automated process. Imagine a cron job that runs your Nmap scan daily and then immediately feeds the output to ndiff comparing it against the previous day’s scan. Any significant deviations can then trigger alerts. This transforms ndiff from a manual comparison tool into an automated network change detection system.

You can fine-tune ndiff’s behavior with options like --xml to get machine-readable output for further processing, or --missing-ports to explicitly list ports that were not found in the second scan but were in the first (which is the inverse of "Deleted Ports" and can be useful for specific auditing).

The next step after mastering ndiff is to integrate its output with a broader security information and event management (SIEM) system or a dedicated vulnerability management platform.