Vulnerability Scanning Guide: Coverage, Credentialed Scans and Tuning

A vulnerability scanner can only report on the assets it reaches, with the access it is given, using checks that are tuned to the environment, and most scanning programmes fall short on at least one of the three. Unauthenticated scans see the network surface but miss most missing patches; credentialed scans see far more but depend on privileged accounts that become a target themselves; and untuned scans either crash fragile devices or bury owners in noise. This guide covers how to get coverage, how to run credentialed, agent-based and agentless scans, how to tune network, web and template-based scanners, and how to measure whether scanning is working. It is for vulnerability management engineers, infrastructure and cloud teams and the security architects who place scanners. How findings are then ranked is covered in the Vulnerability Prioritisation Guide, and the wider programme in the Vulnerability Management Guide.

Key takeaways

• Coverage is the first metric. Reconcile the scanned asset list against inventory, cloud APIs and attack surface data every cycle; an unscanned host has no findings, which looks the same as a clean one.
• Credentialed scanning is the baseline for internal assets. CIS Safeguard 7.5 asks for both authenticated and unauthenticated internal scans at least quarterly; registry data, package versions and patch levels are only visible with valid credentials.
• Scan credentials are privileged non-human identities. Use dedicated accounts, restrict where they can log in from, vault and rotate them, and alert on their use outside scan windows.
• Combine methods instead of buying one more scanner. Network, credentialed, agent-based, agentless cloud, web and API scanning each see different things; scanner sprawl without de-duplication creates duplicate tickets, not coverage.
• Tune for safety and signal. Use safe checks and concurrency limits for fragile devices, filter low-confidence detections, and track credential failure rates so that "no findings" is never mistaken for "no vulnerabilities".

Scanning methods and what each sees

Code, container image and secret scanners belong in the build pipeline rather than the infrastructure scanning programme. See the Container Image Security Guide and the Git Secret Scanning Guide. Web application testing beyond automated scanning is covered in the Web Application Security Testing Guide.

Coverage: scanning what you actually own

NIST SP 800-53 RA-5(3) asks organisations to define the breadth and depth of scanning coverage: breadth as the percentage of components, system types or criticality covered, depth as the level of the system the scan examines. Make both explicit.

• Reconcile sources: compare scanner targets with the CMDB, endpoint management, directory computer objects, cloud provider inventories and DHCP and DNS records. Every asset in one source and not in the scan list is a coverage gap. See the Asset Inventory and CMDB Security Guide.
• Set frequencies by exposure: CIS Controls v8.1 Safeguard 7.5 requires internal scans quarterly or more often, authenticated and unauthenticated, with a SCAP-compliant tool; Safeguard 7.6 requires externally exposed assets to be scanned monthly or more often. Treat these as minimums: assets that change often or face the internet justify more frequent or continuous scanning.
• Place scanners per zone: firewalls and host filters distort results. Nmap's own documentation suggests scanning from behind the firewall to avoid slow or misleading results; a scanner per network zone or data centre, with management ports open only from that scanner, gives both accuracy and control.
• Catch ephemeral assets: cloud instances and containers can live for hours. Trigger scans on launch events or use agent and snapshot methods. Amazon Inspector, for example, scans agent-managed EC2 instances continuously on events such as launch and new CVE data, and scans eligible unmanaged EBS-backed instances from snapshots every 24 hours in hybrid mode.
• Track exclusions: exclusion tags and do-not-scan lists (for instance InspectorEc2Exclusion in Amazon Inspector) are legitimate for fragile systems but must have an owner, a reason and an expiry.
• Know the outside view: run external scans from the internet, not from inside the perimeter, and feed newly found assets back into inventory. See the Attack Surface Management Guide.

Discovery and port scanning

Discovery decides what is scanned at all. Port scanners such as Nmap report each port as open, closed, filtered (a filter blocked the probe), open|filtered (no response, common with UDP) or unfiltered (reachable but state unknown, ACK scans only).

• Do not skip UDP: Nmap notes that with ICMP limited to one packet per second, a full 65,536-port UDP scan of a host can take more than 18 hours. Scan common UDP ports on every host and full ranges on a rotating sample rather than dropping UDP.
• Full TCP ranges on exposed hosts: top-ports lists miss administrative services moved to high ports. Scan all 65,535 TCP ports on internet-facing addresses.
• Feed results forward: every newly open port should be compared with the expected service list; unexpected listeners are findings in their own right. See the Network Ports and Protocols Security Guide.

Credentialed scans: making them work

Greenbone's documentation describes authenticated scans as scanning the target "from the inside" as well as from outside: registry data, software versions and patch levels are only accessible with valid credentials, and on Windows administrative accounts produce more results, while an unprivileged Linux account can see most of what is needed.

• Monitor authentication success per host: scanners only run local checks when login succeeds. A host whose credentialed check fails still appears "scanned" with few findings. Report the credential failure rate as a coverage metric and open tickets for failures.
• Use a dedicated group: Tenable's guidance, for example, places the scan account in a dedicated security group added to local Administrators by a Restricted Groups policy, rather than granting broad domain rights.
• Restrict management exposure: limit WMI and SMB firewall rules to scanner IP addresses so that enabling credentialed scanning does not open lateral movement paths for everyone.
• Handle domain controllers separately: Tenable notes that only Domain Administrator accounts can scan domain controllers over the network. Prefer an agent on domain controllers so that a Domain Admin credential is not stored in the scanner.

Where identity fits: scanner credentials and scanner supply chain

A credentialed scanner holds administrator access to most of the estate. It is one of the most privileged non-human identities an organisation has, and NIST SP 800-53 RA-5(5) treats privileged access for scanning as a control in its own right.

• Store credentials in a vault integrated with the scanner, rotate them on a schedule and on staff change, and never reuse them for other purposes. See the Service Account Security Guide.
• Scope by zone: separate scan accounts per environment (production, development, OT) so one leak does not expose everything.
• Detect misuse: Greenbone notes that the scanner's login is likely logged on the target. Alert when a scan account authenticates from an address other than a scanner or outside the scan window.
• Treat scanners as supply chain: in the Trivy supply chain attack of March 2026, attackers repointed mutable version tags of a popular scanner's GitHub Action to an infostealer that read secrets from CI runner memory. Pin scanner actions and images to commit SHAs or digests and give scanning jobs only the secrets they need.

Tuning for safety and signal

Safety

• Safe checks: remote checks may send malformed requests to extract information. Greenbone's "Full and fast" configuration runs with safe_checks=yes and excludes very invasive or denial-of-service tests; keep that default for production.
• Concurrency: reduce simultaneous hosts and checks (in Greenbone, maxhosts and maxchecks) for slow links and fragile devices. Some IoT devices crash when one host opens many connections at once.
• OT and medical devices: prefer passive discovery and vendor-approved methods over active scanning. See the OT Asset Visibility Guide.
• Active web and API scans: they submit forms and call endpoints, which can create or delete data. Run them against test environments or with test accounts; ZAP's API scan has a safe mode (-S) that performs only a baseline scan.

Signal

• Filter low-confidence detections: scanners grade how a finding was detected. Greenbone's Minimum Quality of Detection setting, for example, controls which results are stored; version-banner guesses are the usual source of false positives on systems with vendor backported fixes.
• Tune rules as code: ZAP's API scan reads a configuration file that sets each rule to WARN, FAIL or IGNORE, and returns exit codes a pipeline can act on. Keep such files in version control with a reason for each IGNORE.
• Review templates before use: template-based scanners such as Nuclei run YAML templates (more than 6,500 contributed by the community) across HTTP, DNS, TCP and file targets. Pin template versions in production and review new templates for intrusive actions.
• De-duplicate across scanners: when network, agent and cloud scanners report the same CVE on the same asset, merge them on asset and CVE before ticketing. Scanner sprawl otherwise multiplies tickets and erodes trust.
• Tell the SOC, but do not blind it: register scanner addresses and windows so that scans are recognised, without suppressing all alerts from those sources. Attackers run the same discovery (ATT&CK T1595.002 Vulnerability Scanning and T1046 Network Service Discovery), and a compromised scanner should still be detected.

Implementing a scanning programme

1. Baseline coverage: reconcile inventory sources and produce a list of assets with no scan in the last cycle, grouped by owner.
2. Stand up discovery: run unauthenticated discovery across all address ranges and cloud accounts, including full TCP on exposed hosts and common UDP ports.
3. Prepare credentials: create dedicated scan accounts per zone, store them in a vault, restrict management ports to scanner addresses and document the change.
4. Pilot credentialed scans: start with a representative ring (one server group, one workstation group) during a maintenance window, watch for service impact and measure login success.
5. Expand in rings: extend to production by zone, add agents where network scanning cannot reach, and enable agentless cloud scanning for unmanaged instances.
6. Tune: review the first full results with owners, suppress verified false positives with reasons and expiry, and adjust concurrency for fragile segments.
7. Roll back if needed: keep previous scan policies versioned; if a policy change causes outages or a flood of new findings, revert the policy, pause the affected zone and investigate before re-enabling.
8. Operationalise: schedule scans by exposure, feed findings to prioritisation and ticketing, and report coverage alongside findings.

Decision guidance

• Agent or network credentialed scan: choose agents for laptops, remote workers, domain controllers and hosts where opening SMB or SSH to a scanner is undesirable; choose network credentialed scans for servers and appliances that cannot run agents. Most estates need both.
• Agentless cloud scanning: good for finding unmanaged instances quickly; check eligibility limits (for example, Amazon Inspector's agentless method needs EBS-backed instances with supported filesystems and fewer than eight volumes) and keep agents where continuous results matter.
• Hosted versus internal scanners: a hosted external scanner gives the true internet view; internal scanners are needed for everything else. Keep credentials for internal scanning inside your boundary.
• Small organisations: start with external scanning of everything internet-facing plus the vulnerability reporting built into endpoint management, then add quarterly credentialed scans of servers.
• Large organisations: one platform per method, a central asset join, scanners per zone, scan policy as code and coverage reporting per business unit. When comparing products, see the Vulnerability Management Buyer's Guide.

Detection and measurement

• Scan coverage: percentage of inventoried assets scanned within the required interval, split by internal and external.
• Credentialed success rate: percentage of targeted hosts where authenticated checks succeeded; investigate any drop.
• Unknown asset rate: assets found by discovery that were not in inventory, per cycle.
• False positive rate: findings disputed and confirmed false by owners, per scanner and plugin family.
• Scan-induced incidents: outages or alarms caused by scanning; should trend to zero after tuning.
• Time to first scan: hours from a new asset appearing to its first credentialed or agent result.

Log scanner job start and end, scan account logons on targets and scan policy changes centrally, so that unusual use of scan credentials or a silently disabled schedule is visible.

Framework mapping

Common failure patterns

• Counting scanned addresses, not assets: DHCP churn and cloud scaling make IP-based coverage figures meaningless; reconcile on asset identity.
• Silent credential failures: a password change or a disabled Remote Registry service turns credentialed scans into unauthenticated ones without any alert.
• Domain Admin in the scanner: using one highly privileged domain account for every scan makes the scanner the best target in the network.
• Permanent exclusions: a fragile system excluded years ago is still excluded, unpatched and now internet-facing.
• Mutable scanner dependencies in CI: referencing scanner actions or images by tag let the Trivy attackers swap in a credential stealer.
• Scanner noise accepted as normal: owners stop reading reports full of duplicates and false positives, and real findings are ignored with them.

Practitioner checklist

• Reconcile scan targets with every inventory source each cycle and report coverage per owner.
• Run internal authenticated and unauthenticated scans at least quarterly and external scans at least monthly.
• Scan all TCP ports and common UDP ports on internet-facing addresses.
• Use dedicated, vaulted, zone-scoped scan accounts and restrict management ports to scanner addresses.
• Report credentialed login success per host and ticket every failure.
• Use agents for laptops and domain controllers, and agentless or event-driven scanning for cloud workloads.
• Keep safe checks on in production and lower concurrency for fragile segments; prefer passive methods for OT.
• Version scan policies, suppressions and templates, each with a reason and expiry.
• Pin scanner actions and images to SHAs or digests in CI.

Standards and references

• NIST: SP 800-53 Rev. 5 (RA-5 Vulnerability Monitoring and Scanning)
• CIS: Controls v8.1, Control 7 Continuous Vulnerability Management
• NIST: SP 800-115 Technical Guide to Information Security Testing and Assessment
• Nmap: Port Scanning Techniques
• Greenbone: Scanning a System
• Tenable: Credentialed Checks on Windows
• AWS: Scanning Amazon EC2 Instances with Amazon Inspector
• ZAP: API Scan

Related NHI Mgmt Group resources: Vulnerability Management Guide · Vulnerability Prioritisation Guide · Web Application Security Testing Guide · Exposure Management and CTEM Guide · Vulnerability Management Buyer's Guide