A vulnerability scan that finishes in 40 minutes but knocks a branch office’s VoIP calls out of sync did not save anyone time. It just moved the cost from the security team’s calendar to the help desk’s ticket queue. Scan concurrency, how many hosts you probe at once, how many checks run per host, and how many connections each check opens, is the single setting most likely to turn a routine scan into an incident. Get it too low and a monthly scan window stretches into a multi-day crawl. Get it too high and you fill firewall state tables, starve interactive traffic, and generate false negatives because half your probes time out. This is a tuning problem, not a checkbox, and it has a repeatable method.
The three knobs that matter
Most scanners expose concurrency as one slider, but it actually resolves into three independent variables. Treating them as one number is why tuning by feel fails.
- Parallel hosts: how many targets the scanner engages at the same time. Nmap calls this the host group size (min-hostgroup and max-hostgroup); Nessus and Qualys expose it as “max hosts per scan” or similar. This is the knob with the biggest blast radius on a shared network segment.
- Checks per host: how many plugins or probes run concurrently against a single target. A host with 40 open services can have 40 checks fired at once, which is often what trips an embedded device’s TCP stack or a fragile SCADA gateway long before the network itself notices anything.
- Per-host connection limits: the number of simultaneous TCP or UDP sessions the scanner opens toward one IP. This interacts directly with connection tracking on any stateful firewall or load balancer sitting between the scanner and the target.
The failure mode differs by knob. Too many parallel hosts saturates link bandwidth and switch buffers. Too many checks per host crashes flaky embedded services and skews timing-based results. Too many per-host connections exhausts firewall session tables even when total bandwidth is nowhere near the link limit. Tune them separately, not as one dial.
Sizing concurrency against link capacity and firewall session tables
Start from two hard numbers before you touch a scan profile: the link’s usable bandwidth and the connection tracking table size of every stateful device in the path.
For bandwidth, work backward from what a single scan thread actually generates. A TCP SYN scan against a /24 at a moderate rate produces a modest, bursty packet stream, well under 1 Mbps per host group. The real cost is rarely raw throughput; it is packet rate and connection setup and teardown rate, which stress CPU-bound firewall inspection and NAT tables long before they saturate a 100 Mbps WAN link.
Connection tracking is the more common bottleneck. A typical mid-range firewall ships with a conntrack table sized for 65,536 to 262,144 entries by default. A vulnerability scan that opens 50 parallel hosts times 40 checks times 3 connections per check can generate 6,000 simultaneous tracked sessions from a single scan engine, on top of whatever normal traffic the site is carrying. When the table fills, the firewall does not queue new connections gracefully; it drops them, and every dropped connection on the scanner side looks like a closed port or a dead host. That is a direct integrity problem for the scan, not just a network nuisance: you get false negatives that nobody notices until an incident proves the host was actually running the vulnerable service the whole time.
Practical sizing rule: keep total concurrent scanner-initiated sessions at any single point in the path under 25 percent of the smallest conntrack table between the scanner and the target. If you do not know that number, ask the network team for it before your first full-subnet scan, not after the first outage ticket.
Signs you are hurting the network
Concurrency problems rarely announce themselves in the scan report. You have to watch the network while the scan runs, not just review results afterward.
- Session table exhaustion: firewall logs showing “session table full,” “conntrack table full, dropping packet,” or a sudden spike in NAT allocation failures during the scan window.
- VoIP jitter and dropped calls: RTP is loss-sensitive and has essentially no retry mechanism. A scan that adds 20 to 40 ms of jitter on a shared uplink is invisible to a file transfer and immediately audible on a phone call. If your helpdesk gets call-quality complaints that correlate with your scan schedule, that is your answer, not a coincidence to dismiss.
- Latency spikes on interactive traffic: SSH sessions lagging, RDP feeling sluggish, or point-of-sale terminals timing out during business hours are the visible symptom of queue buildup on a link the scan is saturating.
- Rising scan error rates: an increase in “host unreachable” or “filtered” results partway through a run usually means the scanner itself is being rate-limited by something downstream, not that those hosts actually went dark.
Any one of these during a scan window is a signal to reduce concurrency before the next run, not to push through and fix the ticket afterward.
Throttling strategies for WAN links and satellite sites
A concurrency profile tuned for a gigabit LAN segment will overrun a 10 Mbps site-to-site VPN or a satellite backhaul in seconds. WAN and satellite links need a different profile, not just a lower version of the same one.
For standard WAN links (MPLS, site-to-site VPN, DSL backup circuits), cut parallel hosts to a fraction of the LAN value, commonly 5 to 10 concurrent hosts instead of 50, and extend per-probe timeouts to 2 to 3 times the LAN default. High latency does not mean the host is slow to respond; it means the round trip itself takes longer, and an aggressive timeout will report live hosts as dead.
Satellite links add a further wrinkle: round-trip latency of 500 to 700 ms even under good conditions, plus asymmetric bandwidth that is often far narrower on the upstream side. Two concurrency-relevant consequences follow. First, the natural latency means a single scan thread already fills more of the pipe’s usable throughput than the packet count suggests, so parallel host counts in the low single digits are often the ceiling, not a conservative starting point. Second, retransmission timers need to be lengthened well beyond terrestrial defaults, or the scanner will treat a slow-but-present response as a dropped packet and retry, doubling the effective load for no additional coverage.
A workable default for satellite or high-latency WAN sites: 2 to 4 parallel hosts, single-digit checks per host, and a minimum round-trip timeout of 3 to 5 seconds before a retry fires. Confirm this against the actual measured RTT to the site rather than a generic assumption, since satellite topologies (geostationary versus low earth orbit) differ by an order of magnitude in latency.
| Link type | Parallel hosts | Checks per host | Retry timeout |
|---|---|---|---|
| LAN / data center | 40 to 60 | 30 to 50 | 1 to 2 seconds |
| Standard WAN (MPLS, VPN) | 5 to 10 | 10 to 15 | 2 to 4 seconds |
| Satellite / high-latency link | 2 to 4 | 5 to 8 | 3 to 5 seconds |
Splitting one large scan into staged jobs instead of raising parallelism
The instinct when a scan takes too long is to raise concurrency. Often the better fix is to keep concurrency where it is safe and split the target list into staged jobs instead.
A single /16 or a multi-site asset inventory scanned as one job forces you to pick one concurrency profile for every subnet in it, including the slowest satellite link and the most fragile embedded device on the list. Staging the same inventory into per-subnet or per-site jobs, run sequentially or in a small number of parallel streams gated by site bandwidth, lets each job carry a concurrency profile matched to its own link and device population. A data center subnet full of modern servers can run at LAN-speed concurrency; the branch office on the same overall scan can run at WAN-throttled concurrency, in a separate job, without either one compromising for the other.
This also isolates blast radius. If one staged job trips a session table or upsets a fragile device, only that job’s targets are affected, and you have a clean boundary for the incident review instead of a subnet-wide guessing game across a scan that touched everything at once. Platforms that organize scanning around asset groups and site boundaries, such as SITEY, let you attach a concurrency profile to each group so a WAN site and a data center segment never share settings by accident, and the scheduler runs the staged jobs in sequence without someone manually queuing them by hand every cycle.
Staging costs some wall-clock time compared to one maximally parallel job, but it buys back predictability, which is what you are actually optimizing for once a scan has caused even one network incident.
A tuning loop: measure, raise, watch, roll back
Concurrency tuning is iterative, not a value you set once from a vendor’s documentation. Run it as a loop with a fixed procedure:
- Measure the baseline: before any scan, capture normal link utilization, conntrack table usage, and, if available, VoIP jitter and MOS scores for the site. You cannot tell a scan degraded something you never measured beforehand.
- Raise one knob at a time: increase parallel hosts by roughly 20 to 25 percent from the last known-safe value. Do not raise parallel hosts and checks-per-host in the same test run, or you will not know which change caused any regression you see.
- Watch during the run, not after: monitor firewall session counts, link utilization, and interactive traffic quality live while the scan executes. Set an explicit rollback threshold in advance, for example conntrack usage crossing 70 percent of table capacity, or jitter exceeding 30 ms on a monitored VoIP path, so the decision to stop is not made under pressure mid-incident.
- Roll back on any threshold breach: drop back to the last known-safe concurrency value immediately, finish or reschedule the scan at that level, and treat the failed step as data, not a fluke to retry right away with the same settings.
- Hold and document: once a profile runs clean for two to three consecutive cycles, record it as the standing profile for that site or asset group, including link type, conntrack table size if known, and the date it was validated, since link upgrades and firewall replacements will eventually invalidate it.
The output of this loop is not a single global concurrency number. It is a small table of profiles, one per site type or link class, each backed by a measured rollback threshold rather than a guess. Re-run the loop whenever a site’s link, firewall, or device population changes materially, since a profile validated against last year’s conntrack table size is not automatically valid against this year’s replacement firewall.
Getting this right is largely why scan scheduling and network reachability checks belong together rather than treated as separate concerns: a reachability probe that already knows a site’s measured latency and link class can hand a sane starting concurrency profile to the scan job instead of making the operator guess it fresh every time. Platforms such as SITEY apply this by running a lightweight reachability pass ahead of the full scan phase and using its latency and loss readings to pick a starting concurrency profile per host group rather than one profile for the entire job. The same logic applies to scan management more broadly, where per-group concurrency settings and staged job scheduling turn this from a manual spreadsheet exercise into a configuration that persists across cycles. If your current asset list does not distinguish WAN sites from LAN segments to begin with, that gap shows up first in asset inventory, since concurrency profiles are only as good as the site and link metadata attached to each host group.
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.