Ask five security engineers how long a vulnerability scan should take and you will get five different answers, because “a scan” can mean a five minute discovery sweep or a four day authenticated web crawl. The useful question is not whether scanning is slow in general, it is whether this scan type, at this scope, is taking longer than its own baseline. Below are those baselines, the variables that actually move the number, and a way to tell a slow scan from a broken one before you burn a maintenance window chasing the wrong cause.
Baseline timings by scope
Duration expectations only make sense per scan type. The four categories below cover most of what shows up in an SLA conversation: network discovery, credentialed host scanning, web application crawling, and container image scanning. Treat the ranges as starting points. Host count, hardware, and how many checks are actually enabled all move the number in either direction.
| Scan type | Typical scope | Typical duration | Primary time driver |
|---|---|---|---|
| Network discovery (/24) | 254 hosts, TCP SYN sweep | 2 to 15 minutes | Host count and rate limiting |
| Credentialed host scan | Single Windows or Linux host, full plugin set | 15 to 60 minutes per host | Plugin count and enumeration depth |
| Full web app crawl | Mid sized app, authenticated, active checks on | 4 to 24 hours | Crawl depth and payload combinations |
| Container image scan | Single image, SBOM plus CVE match | 10 seconds to 3 minutes | Layer count and DB freshness |
Network discovery across a /24
A plain TCP SYN sweep with a command like nmap -T4 -p- -sV 10.0.0.0/24 behaves very differently depending on what you ask for. A SYN only pass against common ports at T4 timing usually finishes in 2 to 4 minutes on a responsive LAN. Add -p- for all 65535 ports and -sV for service detection against the same range and the same sweep can stretch to 30 to 90 minutes, because service detection sends multiple probes per open port and waits for a banner on each one.
Credentialed host scan
Windows hosts are usually the slower half of a mixed fleet. WMI queries for patch history, registry reads, and installed software enumeration commonly add up to 15 to 60 minutes per host depending on plugin count. Linux hosts authenticated over SSH tend to finish in 5 to 20 minutes, since a package manager query (dpkg, rpm) is far cheaper than walking the Windows update history.
Full web application crawl
Spidering an authenticated application with a couple hundred unique endpoints, then running a full active check set (SQL injection, XSS, XXE, SSRF probes), typically takes 4 to 12 hours. Larger applications, or ones with heavy client side routing the spider has to render, push past 24 hours. Raising thread count shortens wall clock time but increases the odds of tripping a WAF or rate limiter, which slows the scan further through retries.
Container image scan
A tool like trivy image <name> against an already cached vulnerability database usually finishes in under a minute for images under 500MB. The first scan after the weekly database refresh (a download in the 200MB range) adds one to three minutes, but that cost is paid once per refresh, not once per image.
The four real bottlenecks
Almost every “why is this scan slow” ticket traces back to one of four things.
Host responsiveness
A host under load, or sitting behind an IPS that silently drops half the SYN packets, forces the scanner into its own retry and timeout logic on every probe. A default 5 to 10 second timeout multiplied across dozens of ports on a flaky host adds real minutes, and that time is invisible in the summary report because the scan still “completes.”
Plugin or check count
Every enabled plugin adds at least one round trip. Modern scanners skip most of their catalog through prerequisite logic, an OS fingerprint routes the engine to the right plugin family instead of running everything against everything, but a policy set to “scan for all known checks” forces a banner grab and version probe against every open service regardless of relevance.
Authentication overhead
WinRM and SMB negotiation, Kerberos ticket exchange, and UAC elevation checks each add fixed latency per host, typically 2 to 8 seconds per successful attempt. A misconfigured service account that trips a lockout policy can add 30 seconds or more per host while the scanner retries, and across a few hundred hosts that alone can double the scan window.
Network latency and topology
Scanning across a site to site VPN or several routed hops adds round trip time to every probe, not just the first one. A scan that takes 20 minutes on a local segment can run three times longer over a link with 150ms of latency, because most scan engines cap concurrency per target to avoid flooding it, which makes the scan partially sequential no matter how much parallelism the engine supports elsewhere.
Why scan time grows non-linearly with enabled checks
Doubling the number of enabled checks rarely doubles scan time, and it is almost never less than double either. Two mechanics explain the curve. First, dependency chains: an OS or service fingerprint has to complete before the engine can select the right plugin family, so on a host running many services, that fingerprinting step repeats and compounds rather than adding a flat cost. Second, in web application scanning the number of test cases is a product, not a sum: parameters multiplied by injection categories multiplied by payload variants. A 20 percent increase in discovered parameters, from a new form or a newly indexed API route, can produce a 50 percent or larger increase in total active check time.
There is also a tail latency effect. Exponential backoff on a timeout means one flaky host near the packet loss threshold can dominate the whole batch’s wall clock time even though every other host finished on schedule. If reports look fine on average but occasionally run far over, look for the single host holding up the batch before touching policy settings.
How to profile a slow scan and find which phase is eating the clock
Guessing wastes the maintenance window. Work through phases in order.
- Split the run by phase. Discovery, enumeration, active checks, and report generation each log a timestamp in most engines; grep the scan log for phase transitions before assuming the whole run is uniformly slow.
- Isolate a single host and rerun the same policy against it alone. If it finishes near baseline, the problem is scope or a specific target, not the policy.
- Check the network path independently with traceroute or mtr between the scanner and the target segment, separate from the scan tool itself, to rule out latency before blaming plugin count.
- Pull authentication logs on the target for repeated failed handshakes or account lockouts, which show up as scanner slowness but are really an identity problem.
- Watch for 429 or other rate limit responses from the target application or its WAF. That is target side throttling, and no amount of scanner tuning fixes it.
If you are running several scanners into one console rather than one engine in isolation, the clock the team actually cares about, time to a reviewable finding, includes a collection and normalization step after the raw scan finishes. Platforms that ingest output from several tools, SITEY among them, spend real time in that scanner integration and deduplication layer matching the same CVE reported by two different engines with slightly different naming, and that step is worth profiling on its own instead of folding it into “the scan was slow.”
Realistic targets for an SLA without forcing shallow scans
An SLA written purely as a wall clock number invites teams to hit it by disabling checks, which defeats the point of scanning. Tier the target by asset criticality instead of applying one number everywhere. Internet facing and PCI scoped assets justify a weekly cadence with a full active check set, and a 24 hour completion window for the crawl phase is realistic without cutting corners. Internal, lower exposure segments can run monthly with a same day completion window since credentialed host scans are the dominant workload there, not web crawling.
Write the SLA against two numbers, not one: maximum completion time, and minimum check depth or plugin family coverage. A completion time alone, with no floor on depth, invites quietly narrowing scope until the number looks good. Scheduling deep scans in windows long enough to finish, without shallow discovery runs blocking on the same queue, is a scan management problem as much as a scanning one, since overlapping jobs against the same host range compete for the same rate limited connections. Because a self-hosted platform like SITEY runs against your own infrastructure rather than a shared external queue, the completion time you measure locally is the real number, not one shaped by contention on a vendor’s side.
When a long scan is a symptom of a broken configuration rather than scale
Host count growth explains gradual increases. It does not explain a scan that suddenly takes five to ten times its normal baseline with no change in scope. When that happens, work through this checklist before assuming the target simply got bigger.
- DNS resolution failures. A reverse lookup per host that times out against an unreachable DNS server can silently add 5 or more seconds per host across the entire range.
- An IPS or IDS treating the scan as an attack and resetting connections, which the scanner interprets as packet loss and retries.
- A TLS handshake or certificate chain misconfiguration causing renegotiation loops on every HTTPS probe.
- A single hung service, a stuck print spooler or a web server thread pool exhausted by something unrelated, forcing the scanner to wait out the full timeout on every probe against that host.
- Two scanning engines targeting an overlapping IP range without a shared target list, effectively scanning some hosts twice.
Once a patch job runs, the remaining question is whether it actually closed the finding rather than just changed a version string in a config file. Automating that check by re-running the original test against the specific finding, which is what the retest and closure phase is for, adds a scan cycle to the timeline but replaces a manual re-check that otherwise gets skipped under deadline pressure. Platforms that automate this step, including SITEY, re-run the scanner’s own check against the specific finding instead of trusting the patch command’s exit code, since an exit code of zero only tells you the command ran, not that the vulnerable configuration is gone.
Findings that come back after triage also deserve a look before you blame the scan itself. If the same low confidence result keeps resurfacing scan after scan, the bottleneck may be in triage and validation rather than in scan duration, since a validation step that filters out repeat false positives before they reach an analyst changes how much of the scan’s output is actually useful, independent of how many minutes the scan itself took.
About SITEY
SITEY is an autonomous vulnerability management platform. It discovers, validates, prioritizes, remediates and re-tests vulnerabilities through an eight-phase automated pipeline, unifying output from 17 integrated scanners. SITEY is self-hosted: it runs in your own infrastructure and your findings are stored there. Outbound connections are limited to licence activation and the optional services you enable, such as an AI provider, CVE enrichment and patch catalogues. Pricing is 599 USD per month or 5,999 USD for a perpetual lifetime license. See pricing or how the platform works.