A vulnerability scanner is deployed to reduce risk, yet a rushed rollout creates a new privileged system that holds administrator credentials for most of the estate, sees every weakness, and produces findings nobody trusts. This playbook covers rolling out a vulnerability scanning platform as a product class: architecture and placement decisions, securing the platform and its credentials, integrating asset inventory and ticketing, piloting and expanding coverage in rings, and running it once it is live. It is vendor-neutral and based on CIS Controls v8.1 Control 7, NIST SP 800-53 Rev. 5 RA-5, NIST SP 800-40 Rev. 4, FIRST EPSS and CVSS v4.0, CISA SSVC and the CISA Known Exploited Vulnerabilities catalogue. It is written for vulnerability management leads, infrastructure security engineers and platform owners. Scanning methods and scan tuning are covered in the Vulnerability Scanning Guide; this page is about getting the platform deployed safely and making it stick.
Key takeaways
- Design for coverage, not for licences. Decide which assets each scan method (network, agent, cloud API) will cover before sizing, and report unscanned assets as a first-class result.
- The scanner is a tier 0 system. Its console, engines and stored credentials can reach almost everything, so it needs the same admin, network and logging controls as a domain controller or PAM vault.
- Integrations decide the outcome. Without asset ownership from the inventory and an automated route into ticketing, findings pile up in the console and remediation does not happen.
- Prioritisation is agreed before the first full scan. Remediation SLAs that use KEV, EPSS and asset exposure alongside CVSS stop the first report from overwhelming owners.
- Roll out in rings with a way back. Pilot credentialed scans on a representative group, expand by zone, and keep versioned scan policies so a bad change can be reverted in minutes.
Phase 0: scope, requirements and success criteria
Start from the outcomes the platform must support. CIS Controls v8.1 Control 7 gives a practical baseline: a documented vulnerability management process reviewed annually (7.1), a risk-based remediation process reviewed monthly or more often (7.2), automated authenticated and unauthenticated scans of internal assets quarterly or more often (7.5), automated scans of externally exposed assets monthly or more often (7.6) and remediation monthly or more often (7.7). NIST SP 800-53 Rev. 5 RA-5 (Vulnerability Monitoring and Scanning) adds enhancements for updating the vulnerabilities to be scanned (RA-5(2)), breadth and depth of coverage (RA-5(3)) and privileged access for scanning (RA-5(5)). Most organisations want more frequent cycles than the CIS minimums; set them from risk, not habit.
- Asset scope: list every asset class in scope (servers, workstations, network devices, hypervisors, cloud instances, containers, external IP ranges and domains, web applications) and who owns the inventory for each. See the Asset Inventory and CMDB Security Guide.
- Exclusions: name the systems that must not be actively scanned (fragile OT, medical devices, some legacy systems) and the alternative evidence used for them. See the ICS Advisory Triage and OT Vulnerability Management Guide.
- Success criteria: agree target coverage, credentialed-scan success rate and remediation SLAs with asset owners and the change board before deployment, so the pilot can be judged against them.
Phase 1: architecture and placement
A scanning platform usually has a management console (on-premises or SaaS), one or more scan engines, optional endpoint agents and connectors to cloud provider APIs. Each method sees different things and has different security costs.
| Method | Best for | Security and operational cost | Rollout note |
|---|---|---|---|
| Network scan engine, unauthenticated | Discovery, exposed services, external attack surface | Needs network reach; low depth, more false positives from version banners | Place one engine per network zone rather than opening firewall paths across zones |
| Network scan engine, credentialed | Patch level, local configuration on servers and network devices | Stores privileged credentials; management ports must be reachable from the engine | Restrict SMB, WMI, SSH and SNMP access to engine addresses only |
| Endpoint agent | Laptops off the corporate network, hosts where inbound management ports are closed | Agent runs with high privilege on every endpoint; agent update channel is a supply chain path | Deploy through existing endpoint management; pin and stage agent versions |
| Cloud API or snapshot scanning | Cloud instances, images and serverless functions without agents | Requires a cross-account role with read access to the cloud estate | Use read-only roles scoped to scanning; see the Cross-Account and Cross-Tenant Access Guide |
| Container and registry scanning | Images before deployment and in registries | Needs registry pull credentials and CI integration | Pin scanner images and CI actions by digest or commit SHA |
- SaaS console or self-hosted: a SaaS console moves patching and availability to the provider but sends asset and vulnerability data off-premises; confirm data residency, retention, encryption and the provider's own access to your data (NIST SP 800-53 SA-9 External System Services). A self-hosted console keeps data in-house and makes hardening, backups and upgrades your job.
- Engine placement: engines inside each zone with outbound-only connections to the console reduce the number of inbound firewall rules. Avoid one central engine with routes into every segment; it becomes a perfect pivot point.
- Sizing: size engines from the number of hosts per zone, the scan window and the required cycle, and test throughput in the pilot rather than trusting a datasheet.
Phase 2: securing the platform itself
NIST SP 800-53 RA-5(5) recognises that scanning needs privileged access; the platform that holds it must be protected accordingly. Attackers also run discovery and scanning (ATT&CK T1595.002 Vulnerability Scanning and T1046 Network Service Discovery), and a compromised scanner gives them a pre-built map of exploitable weaknesses. Hardening of a running platform is covered in Securing the vulnerability scanner itself; the rollout decisions are below.
- Console access: single sign-on through the workforce identity provider, phishing-resistant MFA for all administrators, and no shared local accounts except one break-glass account held in a vault (AC-6(5) Privileged Accounts).
- Role design: separate platform administrators (engines, credentials, integrations), scan operators (schedules and policies), and read-only viewers per business unit. Asset owners should see only their own assets.
- Scan credentials: dedicated accounts per zone and platform, never personal accounts, retrieved from a secrets vault at scan time where the platform supports it, and rotated on a schedule. Scan accounts are non-human identities; give each an owner. See the Service Account Security Guide.
- Integration tokens: API keys for the CMDB, ticketing, SIEM and cloud connectors get the narrowest scopes, an owner and an expiry.
- Data protection: findings reveal exactly how to attack you. Encrypt exports, restrict report sharing and set retention.
- Supply chain: pin scanner images, plug-in feeds and CI actions. In the Trivy supply chain attack, mutable tags of a popular scanner's GitHub Action were repointed to credential-stealing code, and the LiteLLM PyPI package breach shows how a poisoned scanner in a pipeline can leak a publishing token.
Phase 3: integrations
| Integration | Purpose | Design point |
|---|---|---|
| Asset inventory or CMDB | Owner, business criticality and exposure per asset; coverage gap reporting | Reconcile scanner-discovered assets against the inventory both ways: unknown assets found, and known assets not scanned |
| Ticketing | Route findings to owners with an SLA | Group by asset owner and fix (one patch, many CVEs) rather than one ticket per CVE per host |
| Patch and endpoint management | Confirm deployed fixes and close tickets | Close tickets on rescan evidence, not on the patch job status alone |
| Threat intelligence feeds | KEV and EPSS enrichment | Refresh daily; EPSS scores are published daily |
| SIEM | Platform audit logs, scan schedules for correlation | Forward console logins, policy and credential changes; see the SIEM rollout playbook |
| Secrets vault | Scan credentials at runtime | Vault access limited to the engines that need each credential |
Phase 4: prioritisation and remediation workflow
Agree the prioritisation model before the first full scan, because the first report on a large estate commonly lists tens of thousands of findings. Combine these signals rather than relying on base CVSS alone:
- Known exploitation: the CISA Known Exploited Vulnerabilities catalogue lists CVEs with evidence of active exploitation, a required action, a due date for US federal agencies and a flag for known ransomware campaign use. Treat KEV entries on your assets as the top tier. See the CISA KEV Catalogue Guide.
- Likelihood: FIRST EPSS estimates the probability that a CVE will be exploited in the wild in the next 30 days, published daily with a percentile. See the EPSS Guide.
- Severity in context: CVSS v4.0 renamed the Temporal group to Threat and added a Supplemental group; record which nomenclature (CVSS-B, CVSS-BT, CVSS-BE, CVSS-BTE) your scores use. See the CVSS v4 Guide.
- Decision model: CISA's SSVC decision tree uses exploitation status, technical impact, automatable, mission prevalence and public well-being impact to reach Track, Track*, Attend or Act.
| Tier (NHI Mgmt Group recommendation) | Typical criteria | Example SLA to agree locally |
|---|---|---|
| Emergency | KEV listed, internet-facing, or SSVC Act | Days, with emergency change |
| High | High EPSS percentile or critical severity on important assets; SSVC Attend | 2 to 4 weeks |
| Standard | Everything else with a fix available | Next regular patch cycle |
| Exception | No fix, or fix breaks the business | Documented compensating control, owner and expiry date |
Exception handling and SLA design are covered in the Remediation SLAs and Vulnerability Exceptions Guide and the Vulnerability Prioritisation Guide.
Phase 5: pilot, ring expansion and rollback
- Change approval: register engine addresses, scan windows and scan accounts with the change board and the SOC. Tell the SOC about scans without suppressing all alerts from scanner addresses.
- Discovery only: run unauthenticated discovery across all ranges and cloud accounts to measure the gap between the inventory and reality.
- Pilot ring: credentialed scans on one representative server group and one workstation group in a maintenance window, with owners watching for service impact. Measure authentication success per host and compare findings with known patch levels.
- Agent pilot: deploy agents to a small group of remote laptops and hosts without inbound management, and compare results with network scans of the same hosts.
- Expand by zone: add zones one at a time, production last, adjusting concurrency for slow links and fragile segments. Turn on ticketing per zone only once owners have reviewed the first results.
- External and cloud: add external scanning of internet-facing ranges and cloud API connectors; confirm authorisation for any third-party hosted assets before scanning them.
- Rollback: keep scan policies and plug-in or check sets versioned. If a policy change causes outages or a flood of new findings, revert the policy, pause the zone and investigate. Agents should be removable through endpoint management in one change. For a platform replacement, run the old and new platforms in parallel for at least one full cycle; see the Vulnerability scanner migration playbook.
Decision guidance
- Agents or network scans: agents suit mobile and cloud workloads and avoid opening management ports; network credentialed scans suit data centres and devices that cannot run agents. Most estates need both, plus discovery to find what neither covers.
- One platform or several: separate tools for infrastructure, containers and web applications are common. If you keep several, normalise findings on asset and CVE before ticketing so owners see one list.
- Small organisations: a SaaS console with agents and an external scan covers most needs with little infrastructure; focus effort on credentials, ticketing and the KEV tier.
- Large organisations: distributed engines per zone, federated read access per business unit, and a central team that owns policies and SLAs while asset owners own remediation.
Detection and measurement
Monitor the platform: administrator logins, new or changed scan credentials, policy changes, new integrations and exports. Alert when a scan account authenticates from an address that is not an engine or outside a scan window. RA-5 and CA-7 (Continuous Monitoring) expect scanning results to feed ongoing risk decisions, so measure both coverage and outcome.
| Metric | Why it matters |
|---|---|
| Share of inventoried assets scanned in the last cycle, by method | Findings mean little without coverage |
| Credentialed scan authentication success rate | Failed logins make hosts look clean |
| Unknown assets discovered per cycle | Health of the inventory and shadow IT |
| KEV findings open past SLA | The highest-risk backlog |
| Median time to remediate by tier | Whether the workflow actually works |
| Exceptions open past expiry | Risk acceptance that has quietly become permanent |
Framework mapping
| Rollout element | NIST SP 800-53 Rev. 5 | NIST CSF 2.0 | CIS Controls v8.1 |
|---|---|---|---|
| Scanning coverage and frequency | RA-5, RA-5(2), RA-5(3) | ID.RA-01 | 7.5, 7.6 |
| Inventory reconciliation | CM-8 System Component Inventory | ID.AM-01, ID.AM-02 | 1.1, 2.1 |
| Privileged scan credentials | RA-5(5), AC-6(5) | PR.AA-05 | 5.4 |
| Remediation workflow | SI-2 Flaw Remediation | PR.PS-02 | 7.2, 7.7 |
| Continuous monitoring of the platform | CA-7, AU-6, SI-4 | DE.CM-09 | 8.2 |
| SaaS scanning provider | SA-9 External System Services | GV.SC-07 | 15.1 |
Common failure patterns
- Coverage assumed, not measured: reports show findings but not which assets were never scanned or where credentialed logins failed.
- Domain admin as the scan account: one credential with rights everywhere, stored in a console many people can log in to.
- Ticket floods: one ticket per CVE per host sent to owners on day one, who then ignore the queue.
- CVSS-only prioritisation: thousands of "critical" findings with no distinction between exploited and theoretical.
- Flat network access for engines: a central engine with routes and management access into every zone, including OT.
- Unpinned scanner components: scanner images, actions and plug-ins pulled by mutable tags in pipelines that hold secrets.
Practitioner checklist
- Agree scope, exclusions, scan frequency and remediation SLAs against CIS Control 7 and RA-5 before buying engines.
- Choose scan methods per asset class and place engines per zone with outbound-only connections.
- Put the console behind SSO with phishing-resistant MFA and role separation.
- Create dedicated, owned scan accounts per zone, held in a vault and rotated.
- Integrate inventory, ticketing, patching, KEV and EPSS feeds and the SIEM before full rollout.
- Pilot credentialed scans and agents, measure authentication success, then expand by zone.
- Version scan policies and keep a tested rollback for policies and agents.
- Report coverage, KEV backlog and time to remediate monthly to asset owners and leadership.
Standards and references
- CIS: Controls v8.1 Assessment Specification, Control 7 Continuous Vulnerability Management
- NIST: SP 800-53 Rev. 5 Security and Privacy Controls
- NIST: SP 800-40 Rev. 4 Guide to Enterprise Patch Management Planning
- NIST: Cybersecurity Framework 2.0
- CISA: Known Exploited Vulnerabilities Catalog
- CISA: Stakeholder-Specific Vulnerability Categorization
- FIRST: Exploit Prediction Scoring System
- FIRST: Common Vulnerability Scoring System v4.0
Related NHI Mgmt Group resources: Vulnerability Management Guide · Vulnerability scanner buyer's guide · If your vulnerability scanner is compromised · CIS Control 7 Continuous Vulnerability Management Guide · Patch Management Guide