Three sites, one unseen subnet, and a NAT in the middle

Not scanned (190 hosts): Tenable SC does not scan anything itself. It hands target IPs to the scanner in the scan zone you selected, and that scanner must be able to route to the targets and get return traffic back. The zone you picked is almost certainly the branch or DMZ zone, whose scanner either has no route into 10.60.0.0/16 (the edge firewall has no route back to those segments) or is filtering. Second-order causes worth confirming: hosts are genuinely down or the policy's host-discovery ping is ICMP-only and the firewall drops ICMP, so live hosts are declared dead before any plugin runs.

172.31.x addresses: that is the branch firewall's NAT pool. Results are reported with the address the scanner saw, and the scanner sits behind NAT, so every target it reaches looks like a translated address. Two consequences: asset identity in the repository is now wrong, and IP-based asset lists, exclusions, and per-IP risk rules will never match.

Judgement: do not fix this with policy tuning. Put a scanner that has a clean, non-translated path into 10.60.0.0/16 and assign that subnet to a zone containing only that scanner.

Placement: one scan zone per reachability domain, not one zone for the company. The rule is "a zone is a set of scanners that can reach a set of targets the same way." So:

• A new zone for 10.60.0.0/16 containing a scanner deployed inside that network (or with a routed, un-NATed path).
• HQ, DMZ, and branch keep their own zones; never mix a NATed scanner with a routed one.
• Fix the branch NAT regardless: either give SC an un-translated path to that scanner or accept that its data is unusable for anything IP-scoped.

Scan design:

1. Drop ICMP as the only liveness test. Enable TCP ping against ports that are actually open on that estate (443/445/22) plus ARP on local segments, otherwise hosts get marked dead. Alternatively run a Host Discovery pass first to build a live-host asset list, then scan the list.
2. Split the /16 across several scanners so the 5-concurrent-scan ceiling isn't the bottleneck; 4,100 hosts through one scanner with 5 slots means very long serialization.
3. Start with a reduced policy (safe checks, discovery + a targeted family set), then add depth once you know the scan window.
4. Confirm the source address the target firewall sees before the first production run.

The lab has no path, so no scanner can reach it and no zone will help. Run a Nessus scanner locally inside the lab with a matching policy, export the .nessus results, and import them into a dedicated offline repository in SC.

Limitations to state plainly:

• The data is point-in-time. Nothing re-tests those hosts; a finding stays "open" until a newer import supersedes it, so age-based metrics on that repository are only as good as your import cadence.
• Identity is IP-based. If the lab re-addresses hosts, history fragments into new assets.
• Policy drift. If the local export policy differs from the enterprise policy (plugin set, credential settings), findings are not comparable across repositories; keep the policy consistent or segregate reporting.
• Credentialed depth depends on the local run. Credential failures inside the lab are invisible to you unless you check the scan-information output in the imported results.
• Keep it in its own repository and scope dashboards and reports to it, otherwise its hosts will silently merge into enterprise counts and skew trending.