Every scan runs through an entry host — the host the engine connects through to reach the target subnets (see Reaching non-routable subnets). To let a deep scan identify what it finds, store credentials for the hosts you expect to discover first — see Credentials.
Starting a scan
Go to Command Center → Discovery and start a new scan. A scan takes these inputs:- Entry host (required) — every scan starts from an entry host; the engine reaches the target subnets through it. To tunnel through it as a bastion, give its SSH user and key/secret credentials; leave both empty to run the scanner directly from the engine host. If the host has both a public and private IP, you also choose which one to dial.
- Scope (required) — one or more CIDRs to cover (e.g.
10.0.1.0/24, or a comma-separated list). A CIDR must be/16or narrower; broader ranges are rejected to keep a single scan bounded. - Credential allowlist (optional) — restricts which stored credentials a deep scan may try against discovered hosts. Leave it empty and all of the org’s credentials are eligible; narrow it to specific credentials when you want tight control over which logins are ever attempted, such as on sensitive or fragile network segments.
Scan depth
Scan
A reachability sweep only — 2501 checks which addresses in the range are live and which ports they have open. Nothing is logged into.
Review mode
Choose how much of the scan runs without you in the loop:- Auto — recon starts automatically and every host that responds is promoted to a managed host. No manual step.
- Semi-auto — recon starts automatically, but you confirm each host before it’s created or updated.
- Manual — nothing fires on its own. You trigger recon and host creation yourself, node by node.
How it works
The scan runs in an ephemeral container
The scanner runs inside a short-lived container, one per subnet. It probes each address in the range, then — on a deep scan — attempts to authenticate to responding hosts using the eligible stored credentials.
Discovered nodes are characterized
Hosts that accept a connection are characterized automatically — OS, services, routes, and technology stack are derived and attached as tags.
Credentials and characterization
On a deep scan, 2501 tries the eligible stored credentials against each responding host to identify it. Credential handling is deliberately conservative:- 2501 only ever tries credentials already stored in the org — it never generates or guesses logins. The credential allowlist narrows this further; an empty allowlist makes every org credential eligible.
- A node is marked characterized only when a command actually proves access — not on a hopeful match.
- To protect accounts, 2501 stops using a credential after a configurable number of failed authentication attempts (max failures per credential).
- A host that responds but that no credential can authenticate to is still recorded as discovered, so you can supply a credential and re-run recon on it later.

