Nmap Compliance Scanning: PCI DSS Port Audits (2026)

PCI DSS compliance scanning with Nmap is surprisingly effective because it leverages Nmap’s raw network probing capabilities to identify open ports, which is a direct requirement for PCI DSS Section 1.3.1.

Here’s a PCI DSS compliance scan in action. Let’s say we’re checking a web server at 192.168.1.100 for PCI DSS compliance, specifically looking for unauthorized open ports.

sudo nmap -sS -p- --open -oN pci_dss_scan.txt 192.168.1.100

This command initiates a SYN scan (-sS) of all ports (-p-), reporting only open ports (--open), and saving the output to pci_dss_scan.txt.

Let’s break down the internal workings. Nmap, at its core, sends packets to target hosts and analyzes the responses (or lack thereof) to infer the state of ports. For compliance, we’re interested in ports that shouldn’t be open. PCI DSS 1.3.1 mandates that "all system components are protected from unauthorized access," and open network ports are a primary vector for such access. Nmap’s ability to scan all 65535 TCP ports quickly and report only those that are actively listening provides a clear picture of the attack surface.

The key levers you control are the scan type, the port range, and the output format. A SYN scan (-sS) is stealthy and efficient, as it doesn’t complete the TCP handshake for most probes. Scanning all ports (-p-) ensures you don’t miss anything, though it can be time-consuming. Filtering for --open is crucial for compliance, as we only care about active listeners.

The output file (pci_dss_scan.txt) will contain a list of open ports. For a PCI DSS compliant system, this list should ideally be very short, containing only ports that are explicitly required for business operations and are properly secured.

# nmap scan output snippet
PORT    STATE SERVICE
22/tcp  open  ssh
80/tcp  open  http
443/tcp open  https

If you find unexpected open ports, like port 3389 (RDP) or 21 (FTP), you need to investigate. For example, if 3389/tcp is open and not required:

Identify the service: Nmap might label it as ms-wbt-server or similar.
Determine necessity: Is RDP required for this server’s function? If not, it’s a compliance risk.
Remediate:
- On Linux: If it’s an unexpected xrdp instance, stop and disable the service:
```
sudo systemctl stop xrdp
sudo systemctl disable xrdp
```
  This prevents the RDP service from starting on boot and immediately closes the port.
- On Windows: Use the "Services" management console, find "Remote Desktop Services," stop it, and set its Startup type to "Manual" or "Disabled."
- Firewall Rule: If the port is required for a specific IP, ensure your firewall (OS-level or network) is configured to only allow access from authorized source IPs. For example, on iptables:
```
sudo iptables -A INPUT -p tcp --dport 3389 -s 192.168.1.50 -j ACCEPT
sudo iptables -A INPUT -p tcp --dport 3389 -j DROP
```
  This explicitly allows RDP from a specific management IP and drops all other RDP connection attempts.

The surprising thing about using Nmap for PCI DSS compliance is how much information you can glean about potential security misconfigurations by simply looking at which doors are left ajar, without needing specialized, expensive compliance scanners for this specific requirement. Nmap’s foundational network probing is often sufficient.

The next step in a PCI DSS audit would be to verify the security posture of those expected open ports, such as ensuring SSH is configured with key-based authentication and has strong cipher suites enabled.