Reachability and Performance Requirements for Scanning

Overview

Before Strobes can begin scanning your environment, two foundational requirements must be met: reachability and performance. Reachability means our scanning infrastructure can establish a network connection to the assets in scope. Performance means scanning runs at a pace and on a schedule that is safe for your systems. Meeting both requirements up front prevents incomplete coverage, avoids wasted time, and ensures that a clean result is a trustworthy one — not simply a scan that never reached its target.

Why This Matters

The two most common causes of delayed or incomplete assessment results are:

Scanning traffic being blocked at the network layer before it reaches the asset, and scanning traffic being throttled or blocked because a firewall, WAF, or intrusion prevention system mistook it for malicious or overloading traffic.

An asset that the scanner never reached will show as "no findings" — which looks identical to an asset that was thoroughly tested and found secure. Confirming reachability before an engagement starts is what makes a clean result mean something.

Reachability

What Reachability Means

Reachability is the ability of Strobes' scanning infrastructure to establish a network connection to your assets using the ports and protocols required for testing. Two things must be true at the same time for an asset to be reachable:

A network route exists between the scanner and the asset, and nothing along that path — firewall, WAF, IPS/IDS, cloud security group, load balancer, or CDN — is actively blocking or silently rate-limiting the scanner's traffic.

Scanning Deployment Models

Strobes supports three ways of reaching your environment. Most customers use a combination depending on asset type.

External (cloud-based) scanning Strobes' cloud scanning infrastructure reaches your public-facing assets over the internet, the same way an outside attacker would. Your perimeter needs to allow inbound traffic from Strobes' scanner IP ranges.

Internal scanning (on-prem scanner or agent) For assets that are not exposed to the internet — internal applications, private network segments, private cloud VPCs — Strobes deploys a lightweight scanner appliance or agent inside your network. It reaches assets directly over your internal network and only needs outbound access to the Strobes cloud to sync results and receive instructions.

Hybrid Most customers combine external scanning for internet-facing assets with an internal scanner for private assets, feeding a single unified asset inventory.

Reachability Requirements

Performance

What Performance Means Here

Performance has two related meanings: the performance of the scan itself (how quickly and thoroughly it completes) and the performance impact of scanning on your target systems (whether scan traffic noticeably affects real users). Strobes scanners are tunable — intensity, concurrency, and request rate can all be adjusted to match what an environment can safely absorb.

Factors That Affect Scan Performance

• Number of assets and endpoints — more in-scope targets means longer scan duration.
• Scan type — unauthenticated discovery scans are far lighter than authenticated, API, or business-logic testing.
• Target system capacity — staging and QA environments have less headroom than production; the same scan intensity hits harder.
• Network path — internal LAN scans are faster and lower-risk than scans over the public internet.
• Concurrency settings — the number of parallel requests or threads controls how aggressively the scanner works and how much sustained load it generates.

Performance Settings and Recommendations

Pre-Engagement Checklist

Work through this list with your Strobes engagement lead before the scan or test window begins.

Roles and Responsibilities

Support and Escalation

During an active engagement, contact your Strobes engagement lead or Strobes Customer Success Manager immediately if you notice unexpected load on target systems or believe scanning is affecting production.

For reachability concerns identified before or during scanning — for example, an asset returning zero findings when findings were expected — contact your Strobes Customer Success Manager to verify connectivity before treating the result as a clean bill of health. A zero-finding result is only meaningful when reachability has been confirmed.

Tips

Confirm reachability before the scan window, not during it. Discovering a firewall block or DNS issue mid-engagement delays results and may require rescheduling. Run connectivity checks with your Strobes lead at least 24 hours before scanning begins.

Allowlist by IP, not by user-agent. WAFs and CDNs that identify scanners by user-agent string can be updated to bypass detection. IP-based allowlisting is more reliable and does not require changes to scan configuration.

A clean result is only trustworthy when reachability is confirmed. If an asset shows no findings and reachability was not explicitly verified, treat the result as inconclusive, not secure, until confirmed.

Use safe mode for production assets. If scanning must run against live production systems, request the reduced-intensity safe profile to minimize the risk of scan-induced latency or availability issues.

Keep your on-call team informed during the scan window. Even with safe mode enabled, unexpected behavior can occur. Having someone aware of the scan window means any anomalies can be attributed quickly rather than triggering an unnecessary incident response.