TS-C (NCCT): Two Appliances, Forty Sites, and a Segmented Cardholder Environment

Constraint first: the WAN is the binding limit, not appliance count. At 50 Mbps per site with a 30% cap, the ceiling is roughly 15 Mbps of scan traffic per branch - fine for a handful of network devices, not for sweeping thousands of endpoints across MPLS every night.

Placement:

• Appliance A in data centre 1, Appliance B in data centre 2. Scan zones map to data centre subnets plus the branch ranges that must be scanned remotely.
• Branches: prefer agents over remote sweep. Agents initiate outbound and generate negligible steady-state WAN load, which keeps the POS circuits inside the 30% cap and removes the 01:00–03:00 geographic scheduling problem. Reserve appliance-based scanning for network devices, printers, and appliances that cannot host an agent.
• PCI segment: the third party will not accept inbound, so no external scanner can reach it. Two viable options: (a) fund a third appliance inside the segment, or (b) deploy agents inside the segment, which satisfies the outbound-only rule and gives local check coverage. Option (b) fits this year's budget; option (a) is the cleaner long-term answer for devices that cannot run agents.

Document the zones so that scan traffic never crosses a zone boundary - that is what keeps you inside the utilisation cap under audit.

Principle: the scanning account needs exactly the rights to read configuration, not to change it.

Windows:

• One service account per region, not one global account - a single locked account should not blind the whole estate.
• Rights required: local administrator on targets (needed for local checks and registry reads), obtained via Group Policy restricted groups or a privileged access product, not by adding the account to Domain Admins.
• Set the account so it cannot interactively log on; exclude it from Tier 0.

Unix/Linux:

• SSH key-based authentication with a dedicated key per region, no password login, sudo restricted to the read-only command set the scanner needs. Never the root password.

Network devices:

• Read-only SNMP or a read-only CLI account, separate from the host credentials.

Validation before wide rollout:

1. Pilot on roughly 200 hosts spanning both OS families and at least two regions.
2. Report a credential success rate, not just a scan success rate.
3. Manually reproduce three local checks on a pilot host to confirm you are getting authenticated results and not silently falling back to network-only.

Store credentials in the platform's vault, rotate on a schedule shorter than the audit period, and alert on authentication failure rate - that metric is your early warning that a rotation broke a region.

Two hours is not the real constraint; concurrency is. You cannot lengthen the window without permission, so you reduce the work inside it.

Design:

• Split the estate by collection method. Agent-based assets need no window at all - they report continuously. That removes the majority of hosts from the nightly sweep and leaves a much smaller appliance-scanned population.
• Move bulk discovery to weekly, targeted checks to nightly. Full port and service discovery weekly per zone; vulnerability checks nightly only against hosts with known open ports.
• Stagger by zone with jitter, not all zones at 01:00. Sequence them so no two large zones overlap and each finishes before its successor starts.
• Throttle per scanner to a scan-rate ceiling derived from the site's 15 Mbps allowance, and monitor actual interface utilisation during the window rather than trusting the setting.
• Measure the overrun. Instrument how long each zone takes; if a zone consistently exceeds its slot, that is a scope problem to fix, not a reason to widen the window into business hours.

Present the network team with per-zone utilisation measurements after one cycle - that converts the 30% cap conversation from policy into evidence.