Safeguard 1.3 Utilize an active discovery tool: requirements and evidence

What CIS Safeguard 1.3 asks for and why active discovery matters

Safeguard 1.3 requires an active discovery tool that identifies assets connected to the enterprise network, and it must be configured to run at least once a day. It sits in the Devices asset class and the Detect security function, and it is an IG2 Safeguard, so it is not part of the IG1 essential baseline. Its job is to feed the detailed asset inventory described in Safeguard 1.1 with what is actually on the network, rather than what someone recorded when a device was bought. Without it, the inventory is only as good as the manual process that populates it, and unknown devices stay unknown until something goes wrong.

The risk is simple to state. A device nobody knows about has no owner, no patch schedule, no configuration baseline and no monitoring. Rogue laptops, forgotten test servers, network printers with default credentials and shadow cloud instances all fall into this gap. Active discovery narrows it by sending probes across defined address ranges and recording what responds. Because the result is compared against the inventory, the output also drives the response work in Safeguard 1.2. In practice, the decision an organization must make first is which ranges, VLANs, cloud accounts and subnets the tool must cover, and who signs off on that scope.

Active scanning is harder to keep correct than it looks. Scan targets drift as segments are added, cloud subnets are created by application teams, and VPN or branch networks are renumbered. Scanners also need credentials, firewall rules that permit probes, and scheduling that does not collide with maintenance windows. A tool that runs daily against an outdated range list will pass a casual check and still miss most of the estate. Before committing to a design, confirm with your assessor how they will evidence the daily schedule and coverage, and plan an owner for scope reviews each time the network changes.

Which networks, devices and teams fall under an active discovery tool

Safeguard 1.3 is only as complete as the scope it is configured against. The decisions below determine which segments, clouds, sites and operational ranges the scanner covers, and which teams own the results.

Internal network segments and subnets

List every subnet that carries enterprise assets, including user, server, guest and management VLANs. A scan that covers only the main office range leaves gaps an assessor will find by comparing the tool's scope against the network diagram and IP address records. Document each range the scanner targets, and confirm that segments reachable only through routed paths are included. Ask the scanning owner which ranges were excluded and why.

Cloud and virtual networks

Cloud accounts, virtual private clouds and hypervisor networks hold assets that a perimeter-facing scan may never reach. Active discovery needs a deliberate path into these networks, such as a scanner deployed in each VPC or subnet, and credentials or agents where the platform requires them. Confirm that short-lived instances and containers are either covered by scheduled discovery or captured by another Safeguard 1.4 or 1.5 feed.

Remote and branch sites

Branch offices, retail locations and home-office VPN users often sit behind separate routers and firewalls. Decide whether each site runs its own scanner that reports to a central inventory or whether one scanner reaches across tunnels. Check that scan results from remote sites arrive on the daily schedule, because a site that silently stops reporting produces a failing measurement for the whole program.

Operational technology and IoT ranges

Industrial controllers, building systems and some medical or IoT devices can fail or reset under aggressive port and service probing. Agree in writing which ranges receive active scans, which receive only passive or DHCP-based discovery, and which are excluded with a documented compensating control. The exception list is itself evidence that the scope decision was deliberate and reviewed by the asset owner.

Ownership of the scanner and inventory

Name one owner for the scanner configuration, one for the schedule and alerting, and one for reconciling discovered assets with the inventory from Safeguard 1.1. When the security team runs the scanner but IT operations maintains the asset records, unresolved findings can sit between the two. Record these owners in the asset management procedure so an assessor can trace each discovered asset to a named person.

Scan credentials and change approval

Authenticated discovery depends on credentials that the scanner must store, rotate and restrict to the scanning purpose. Decide who approves changes to target ranges, scan timing and credential scope, and log those approvals. Without a change record, the scanner's configuration cannot be shown to match the approved scope during an assessment, and an unexplained change to the target list is the kind of gap assessors look for first.

How an assessor tests Safeguard 1.3

This table sets out what the CIS Assessment Specification measures for Safeguard 1.3, the failing conditions, the evidence an assessor typically requests and the findings that cause trouble. Read it as a preparation checklist: each row names something the assessor will look at, so confirm that your scan schedules, scope and configuration exports match what each row describes before the review starts.

Assessment element	What the assessor checks	Evidence to prepare
Scan frequency	Whether the active discovery tool runs at least once every 24 hours. A tool that runs less often than that is scored as failing.	Scheduler configuration, cron or task definitions, and run history covering the assessment period
Tool configuration	Whether an active discovery tool is present and properly configured for the enterprise network, not just installed on one segment.	Configuration exports showing scan targets, credentials scope, and the schedule setting
Discovery coverage	The share of enterprise network assets the tool actually finds compared with the asset inventory from Safeguard 1.1.	Scan reports reconciled against the inventory, with the method used to match records
Tool compliance ratio	How consistently the tool meets its required configuration across the scanned environment, including subnets and sites.	Per-segment configuration records and a list of exceptions with owners and dates
Prerequisite: Safeguard 4.1	Whether a secure configuration process exists that produces the data the discovery measurement relies on, such as hardened build records and configuration baselines.	Documented secure configuration process and recent baseline or build records
Stale or missing results	Whether scan results are current. Old reports, failed runs that went unnoticed or undocumented gaps are common findings.	Failed-run alerts, ticket records for scan failures and evidence of corrective action
Coverage gaps	Segments, VLANs, cloud accounts or remote sites that the tool never reaches, which leave assets outside the measurement.	Network scope map showing scanned and unscanned ranges, with documented reasons for exclusions
Measurement method	CIS specifies what to measure but not how. The assessor will expect a repeatable, documented method for calculating coverage and ratio.	Written method, calculation worksheet and the date each measurement was taken

How to implement an active discovery tool step by step

This sequence turns Safeguard 1.3 from a tool purchase into a measured process: a scoped scan plan, a deployed tool on a daily schedule, results flowing into the asset inventory, and proof that known subnets are covered. Each step ends with an output an assessor can check.

Define scan scope against the network map
Start from the network diagram and the addressing plan, then list every subnet, VLAN, cloud account and site that should be scanned. Mark exclusions explicitly, such as segments that cannot tolerate active probing, and record who approved each exclusion. The output is a written scope document that names each address range, its owner and the reason for any gap. Confirm the list against the existing Safeguard 1.1 inventory so that known ranges are not missed.
Select and deploy the discovery tool
Choose a tool that can perform active scanning of the ranges in the scope document and that can run from a host with network reach to them. Open-source options such as Greenbone Community Edition (OpenVAS) can be deployed inside the client's own infrastructure, but confirm during evaluation that a given tool covers the asset types you need, including network devices and cloud workloads. The output is a deployed scanner host, documented in the configuration baseline, with a named administrator.
Configure credentials and scan schedules
Set up authenticated access where the tool supports it, so that scans can identify installed software and hardware details, not only open ports. Create a schedule that runs the discovery job at least once every 24 hours, as Safeguard 1.3 requires, and keep the schedule definition under version control. The output is a saved job list with run frequency, target ranges and credential references, plus a test run that completes within the scheduled window.
Connect scan results to the asset inventory
Set up the export or integration path that moves discovered assets into the Safeguard 1.1 inventory, whether that is a CMDB, GLPI Assets or another system of record. Map the tool's fields to the inventory fields, and decide which system is authoritative when records conflict. The output is a sample import in which a discovered device appears in the inventory with its address, identifier and discovery timestamp.
Set alerting for failed or missed scans
Configure notifications for jobs that fail, do not start on schedule or return zero results for a range that normally has hosts. Route those alerts to a named owner with a documented response step. Test the alert by deliberately pausing one job in a non-production window and confirming the notification arrives. The output is a tested alert rule and a runbook entry describing who responds and how the gap is recorded.
Validate coverage against known subnets
Compare the ranges that the discovery tool actually scanned against the scope document and the network map. Investigate any subnet that returned no assets and any discovered asset outside the approved ranges. Record the coverage result and the tool configuration settings that an assessor will ask about. The output is a coverage report that shows each known subnet, its scan status, the count of assets found and the reasons for any exceptions.
Document the process and retain run evidence
Write the procedure that covers scope changes, schedule changes, exclusion approvals and alert handling, and assign an owner to review it on a recurring basis. Keep job logs, coverage reports and change records together so that the evidence for the measurement can be produced for an assessment. The output is an approved procedure and an evidence folder with dated run history, which a qualified assessor can sample.

Evidence that passes an active discovery audit

An assessor testing Safeguard 1.3 looks for proof that the tool ran on schedule, covered the whole environment and changed only through approved decisions. The cards below cover the artifacts that prove each of those points, and each one needs a routine owner so it stays current between audits.

Scan schedule configuration

Export the scheduler settings and the tool's discovery job definitions, including target ranges, scan frequency and the authenticated or unauthenticated methods used. The CIS Controls Assessment Specification fails Safeguard 1.3 when the tool runs less often than every 24 hours, so the schedule must show a recurrence of at least once a day. Keep a dated copy after each change, and confirm the exported configuration matches what the tool is actually running.

Daily scan run logs

Retain the run history that shows each scheduled discovery job started and finished on each day in the audit period. Assessors compare these dates against the schedule to find gaps, skipped runs and failed jobs. A missing day is a finding even when the next run succeeds, so set an alert for failed or missed runs and record the reason and the recovery time in the same log.

Discovery reports by subnet

Produce a report showing the number of assets found in each subnet on each run, with the first-seen and last-seen dates for each asset. Trends matter here: a sudden drop in a subnet can mean a scan target was removed or the tool lost credentials. Store the reports in the same location as the run logs so an assessor can follow a single discovery event from schedule to result.

Coverage reconciliation against the network map

Compare the subnets and address ranges in the discovery tool's scope with the current network diagram and address plan. Each range on the map should appear in the tool's scope, and each scanned range should exist on the map. Record any difference with an owner and a date. Reconcile at least as often as the network map changes, and keep the signed reconciliation with the inventory from Safeguard 1.1.

Change records for scope updates

Record every change to discovery scope, tool version or credentials with the request, the approver, the date and the reason. Assessors use these records to confirm that a range added or removed from scanning went through a documented decision, not an informal edit. Link each change to the reconciliation it prompted so the scope history can be traced from the network map to the tool.

Keeping artifacts current

Assign one owner to the schedule export, the run logs, the reports, the reconciliation and the change log, and set a fixed monthly date to collect them into the evidence folder. Run a test extract before each audit to confirm the tool still produces every artifact. Ask the implementation partner or the platform team to confirm which exports the chosen tool supports, because report formats differ between products.

Open-source tools that can produce active discovery evidence

GLPI (GPL-3.0-or-later) is the record-keeping side of the picture. Its Assets module holds computers, monitors, software, network equipment, peripherals, printers, phones and racks. Records are entered manually or pushed automatically by the GLPI Agent through the native inventory built into GLPI since version 10, which makes it a practical home for the single asset record that Safeguard 1.1 expects.

Asset records: Devices found by a discovery run can be stored and reconciled against approved entries in one place.
Agent-fed updates: The GLPI Agent pushes hardware and software data, which keeps records current between manual reviews.
Limit of the record: A GLPI entry shows what was entered or reported, not that a network sweep ran at least once every 24 hours. Confirm whether your GLPI version can schedule network discovery itself.
Run history: Keep the discovery schedule, job logs and output as retained evidence, and confirm where GLPI stores them.

Before relying on GLPI, confirm in your own deployment how discovery jobs are configured, scheduled and logged, and whether those logs can be exported for an assessor.

What meeting Safeguard 1.3 costs in money and effort

This table separates the cost of running an active discovery tool for Safeguard 1.3 into licenses, engineering, evidence upkeep and external review, and marks which costs are one-time and which recur. Use it to frame a quote request, because the tool license is often the smallest line item and the scheduling, coverage and evidence work drives most of the effort.

Cost component	Who is paid or who does the work	One-time or recurring	What drives it up or down
Tool licenses	Software vendor or none for GPL, MIT and AGPL tools such as GLPI, Wazuh, Fleet and Greenbone Community Edition	Open-source tools carry no license fee; commercial add-ons or support contracts recur	Choice of tool, need for vendor support, and whether premium feeds or modules are required
Deployment and scanner placement	Internal platform team or implementation partner under a written scope	One-time	Number of network segments, VLANs, cloud accounts and remote sites needing a sensor or scan path
Daily schedule and tool configuration	Internal engineering team, often with a partner for initial setup	One-time setup, then recurring checks	Number of scan jobs, change control requirements and how schedules are set and locked
Coverage reconciliation	Internal asset owners and security staff	Recurring	Number of unmanaged or shadow networks, and how often the discovered set is compared with the Safeguard 1.1 inventory
Evidence upkeep	Internal compliance or security team	Recurring	Frequency of exports, retention rules for scan logs and how much history the assessor will sample
Feed and tool maintenance	Internal engineering team or retained support provider	Recurring	Update cadence of the tool and its vulnerability or asset data, and patching of the discovery server
Prerequisite work (Safeguard 4.1)	Internal configuration or platform team	One-time, then recurring reviews	Maturity of the secure configuration process, since the assessment specification treats it as a prerequisite for measuring Safeguard 1.3
External review and auditor sampling	Independent auditor or assessor, who issues any report	Recurring at each assessment cycle	Scope of the assessment, number of sampled days of scan records, and quality of the exported evidence

Which parts of Safeguard 1.3 are worth outsourcing

The part of Safeguard 1.3 that stays with your team is the decision about what the active discovery tool should scan, how often it runs and who reviews what it finds. Those choices are control decisions, and the organization owns them. Your security or IT operations staff should set the scan ranges, approve exclusions, decide how discovered assets are matched to the inventory from Safeguard 1.1, and sign off on how unmatched assets go into the response process in Safeguard 1.2. Keep these decisions in-house so the policy reflects your network and risk appetite, and so that someone accountable can explain every exclusion to an assessor.

A partner is more useful for the technical work that is tedious to prove by hand: installing and configuring the discovery stack, setting the daily schedule so the tool is not run less often than every 24 hours, connecting its output to the inventory, and building reconciliation evidence. In a fixed-scope engagement, the written scope should name the tools, the network segments, the expected deliverables (configuration exports, schedule records, a coverage comparison against the inventory and a test that seeds a rogue device and confirms it is detected) and the handover to your team. Ask for those items by name in any quote. DeployOpen, for example, implements and documents self-hosted open-source platforms in your own environment, but it prepares systems and evidence only. It does not issue attestations, and an independent assessor or certification body reaches its own conclusion about Safeguard 1.3.

Before signing, confirm three things with any candidate. First, whether the partner will test discovery coverage against segments you have not named, since a tool that is configured correctly but never sees an isolated subnet fails the coverage metric. Second, who maintains the configuration after handover and how that work is paid for, because daily runs and changing networks create recurring effort. Third, whether Safeguard 4.1, the secure configuration process, is already in place, since the assessment specification treats it as a prerequisite for measuring Safeguard 1.3. The CIS Controls Assessment Specification states the measures your assessor will use, so compare the proposed deliverables against them before agreeing scope.

Who does what: your team, an implementation partner and the auditor

Your organization owns Safeguard 1.3. The CIS Controls are implemented by the enterprise, so no vendor or consultant can be accountable for whether discovery actually runs. Your team decides what the discovery tool may scan, how its results feed the asset inventory from Safeguard 1.1, and who acts on what it finds.

Scan policy: define the address ranges, VLANs and cloud accounts in scope, and document each exclusion and the reason for it.
Schedule and configuration: set discovery to run at least once every 24 hours and place the tool configuration under change control.
Exception ownership: name who reviews unmatched assets and who approves removal, blocking or quarantine under Safeguard 1.2.
Sign-off: a named owner approves the scan policy and accepts coverage results at each review cycle.
Prerequisite data: maintain the secure configuration process described in Safeguard 4.1, which the measurement relies on.

Check that a named person can explain, without the vendor present, which networks are scanned, how often, and what happens when the scan finds a device that is not in the inventory.

Common gaps in active discovery and how to close them

An active discovery tool only satisfies Safeguard 1.3 if it runs on schedule, covers every in-scope network and feeds results back into the inventory. The gaps below are the ones assessors most often find when the tool appears to be working but the evidence does not hold up.

Scans that fail without alerting

A scheduled scan can stop after a credential expires, a target list changes or a scanner loses its update feed, and nobody notices until the inventory is stale. Safeguard 1.3 is scored against the tool running at least every 24 hours, so a silent failure is a failed measurement even when the tool is installed. Check that each scan job records a start time, completion status and asset count, and that a missed or failed run raises an alert to a named owner.

Network segments left out of scope

Discovery usually starts with the corporate LAN and quietly skips management VLANs, server enclaves, branch sites and guest networks. Assets in those segments then appear in no inventory and no unauthorized-asset review. Compare the discovery target list against the current network diagram and the address plan, and record any excluded range with a documented reason and an owner.

Cloud networks not scanned

Virtual networks, subnets in cloud accounts and container hosts often sit outside the scanner's reach because they are reached through different routing, security groups or ephemeral addressing. Cloud instances can be created and destroyed between scans. Confirm that each cloud account has a defined discovery method, whether an agent, an API-based inventory or a scanner with a route into the subnet, and that the method runs on the same daily schedule.

Scan results never reconciled with the inventory

A discovery tool that finds assets nobody records has produced data but not control. Safeguard 1.1 requires the inventory to be accurate and current, so discovered hosts that do not match a record must be added, owned or investigated. Set a recurring reconciliation that compares the latest scan against the asset register, logs each unmatched host and tracks it to closure. Assessors will ask for a sample of these reconciliation records.

No record of configuration history

Assessors measure tool compliance over time, so a current configuration alone does not show that the tool ran as required last month. Changes to scan schedules, target ranges, credentials and exclusions can erase the earlier state. Keep the scanner configuration under version control or an audited change process, and retain scan logs long enough to show continuous daily operation across the assessment period.

Safeguard 1.3 questions buyers and engineers ask

How much effort does an active discovery tool take to run?

Most of the effort is one-time setup and then steady tuning, not constant hands-on work. Setup covers choosing the scanning method, defining the address ranges to cover, agreeing which network segments need scanning permission, and deciding where results are stored. After that, the tool runs on its schedule and staff review the results. The recurring effort depends on how often the environment changes, how many unknown devices appear, and how many exceptions need documenting. Ask any partner or internal team to break the estimate into scoping, configuration, integration with the inventory from Safeguard 1.1, and ongoing review, so you can see where the hours go.

How long does deployment usually take?

The timeline is driven by the size and layout of the network, not by the tool alone. Duration grows with the number of sites, subnets and cloud accounts in scope, the number of segments that need approval before scanning, and how many change windows are needed for scanning on production systems. Teams with an existing asset inventory and clear network documentation usually move faster than teams that must first find out what they operate. Ask for a written scope with milestones before work starts, since the scope sets the schedule.

Can an in-house IT team set up active discovery without outside help?

Yes, many in-house teams can, provided they have network engineers who understand the topology, someone who owns the inventory, and time to test scans without disrupting fragile systems. The harder parts are usually scan safety on operational technology and legacy hosts, deciding which address ranges count as in scope, and proving to an assessor that the schedule and configuration are enforced. An implementation partner can prepare the tool, the configuration records and the evidence, but the organization keeps ownership of its controls. Only an independent assessor can issue an assessment result.

What does the IT team need to provide for an active discovery project?

The team needs to supply accurate network information and decisions that only the organization can make. Typical inputs are:

A list of address ranges, VLANs and cloud accounts that should be scanned
Credentials or agent access approved for authenticated scans, where the organization allows them
Change windows and contacts for systems that can react badly to scanning
Access to the existing asset inventory and the systems that will receive discovery results
Named owners for reviewing new and unknown devices each cycle

Without these inputs, scan coverage is hard to prove and the tool will produce noise that the inventory team cannot act on.

Does an open-source discovery tool pass a CIS Controls assessment?

The CIS Controls do not certify tools. The Assessment Specification measures whether the Safeguard is implemented: whether an active discovery tool runs at least every 24 hours, whether it is properly configured, and how much of the in-scope asset population it covers. An open-source tool can meet those measures if it is deployed, configured and documented well, and if the organization can show the schedule, coverage reports and tuning history. Confirm the exact features and scan methods of any candidate tool in its own documentation and test them in your environment before relying on them. The assessor decides whether the evidence is sufficient.

Is a daily scan schedule the only requirement for Safeguard 1.3?

No. A daily schedule is the timing requirement, but the assessment also looks at what the tool actually covers and whether it is configured correctly. Assessors typically look for evidence that scans reach the in-scope asset population, that results feed the inventory from Safeguard 1.1, and that the configuration is controlled and reviewed. Gaps such as unscanned subnets, scans that silently fail, or results nobody reviews can cause a failure even when the schedule looks right. Keep run logs, coverage comparisons and change records for the tool's configuration.

How does Safeguard 4.1 relate to active discovery?

Safeguard 4.1 covers the documented secure configuration process, and the CIS Controls Assessment Specification lists it as a prerequisite for measuring Safeguard 1.3. The reason is practical: a secure configuration process produces the baseline data and configuration records that discovery results need to be compared against. Without a defined standard for what a compliant device looks like, an unknown or misconfigured asset is hard to recognize. Plan the two together so that discovery results can be matched to approved configurations, and confirm the exact evidence expectations in the Assessment Specification for v8.1.

How DeployOpen scopes and implements active discovery

DeployOpen plans, builds and hands over an active discovery capability for Safeguard 1.3 inside your own infrastructure, so the scan schedule, tool configuration and results feed your asset inventory from Safeguard 1.1. Your organization owns the control and its evidence, and an independent assessor decides whether the Safeguard is met.

How we scope

Engagements are fixed-scope, with the network ranges, scan targets and schedule agreed in writing before work starts.
The written scope names the discovery tool, the daily run frequency and the inventory system that receives the results.
We confirm the prerequisite secure configuration process from Safeguard 4.1 and which assets must be found.

How we build

We deploy the chosen open-source discovery tooling inside your cloud accounts, data centers or air-gapped network.
We configure scans to run at least once every 24 hours and verify that each scheduled run completes successfully.
We connect discovery output to the asset inventory and test that newly connected assets appear in the records.

How we hand over

We document scan configuration, schedules, ranges and exclusions so an assessor can trace how coverage was measured.
We deliver run logs and coverage reports that show discovery frequency and the proportion of assets found.
Your staff receive a walkthrough of how to review unmatched assets and how the evidence is retained.

How we support

Ongoing support, upgrades and continuous testing of the discovery setup are available as a retainer.
Retainer work can cover changes to network ranges, tool upgrades and periodic checks that scans still run daily.
Ask any provider to confirm in writing which evidence they prepare and which parts an independent auditor must review.