Safeguard 12.1 Keep network infrastructure up to date

What Safeguard 12.1 asks for to keep network infrastructure up to date

Safeguard 12.1 requires that network infrastructure runs supported, current software, such as the latest stable release of the operating system or firmware on routers, switches and firewalls, or a currently supported network-as-a-service offering. The assessor also expects the software versions to be reviewed at least monthly, or more often, to confirm they are still supported. The safeguard sits in Implementation Group 1, so it applies to IG1, IG2 and IG3 enterprises alike. It is the only IG1 safeguard in Control 12, which makes it a baseline expectation for every organization in scope, whatever its size. The risk is concentrated at the edge. Firewalls, VPN concentrators and load balancers face the internet, and a known flaw in their management interface or services can give an attacker a foothold before any endpoint control is reached. Network gear is often missed by patch programs because it is managed by a networking team, sits outside the server patch cycle, runs vendor firmware that does not appear in standard endpoint tools, and may be out of support without anyone noticing. A device that has reached end of support receives no fixes at all, so the review cadence matters as much as the patch itself.

The hardest part is usually not applying the patch. It is knowing the complete list of network devices and the exact version running on each one. Before you commit to a monthly review, confirm that your asset inventory covers every switch, access point, firewall, router and out-of-band management card, because the assessment specification treats a detailed asset inventory (Safeguard 1.1) as a prerequisite for measuring Safeguard 12.1. Ask the networking team which devices exist outside the official inventory, such as lab equipment, branch hardware or cloud virtual appliances. The measure is a coverage ratio: the share of network infrastructure assets that are up to date. An assessor will fail the safeguard at zero if more than thirty days have passed since the last review of network infrastructure, so the monthly cadence needs a named owner, a calendar entry and a record of each review. Keep the review output, including the version list, the vendor support dates and the decisions taken, as the evidence that the process runs.

Which network devices and teams fall under Safeguard 12.1

The monthly version review under Safeguard 12.1 is only as complete as the device list behind it. The decisions below determine which devices enter the review, who signs off on each one, and how much work each monthly cycle creates.

Physical and virtual routers and switches

Physical routers and switches are the most obvious scope, but virtual routers, virtual switches and software-defined networking components run on hypervisors and often sit outside the network team's usual inventory. Each one runs versioned software with its own support lifecycle. Ask whether virtual appliances are recorded in the same asset inventory as hardware, because Safeguard 1.1 is the prerequisite for measuring this safeguard.

Firewalls and load balancers

Firewalls and load balancers are frequent sources of unsupported firmware because they are often managed by security or application teams rather than the network group. Include high-availability pairs as separate entries, since each member can drift to a different version. Confirm that vendor appliances, web application firewalls and clustered devices each have a named owner in the review.

Wireless controllers and access points

Wireless controllers and access points count as network infrastructure, and access points often run firmware that is updated on separate schedules from the controller. Decide whether to track each access point individually or report controller-managed groups. Individual tracking gives a more accurate coverage figure, while group tracking shortens the monthly review but can hide stragglers.

Out-of-band management devices

Console servers, out-of-band management modules and baseboard management controllers provide access to devices when the production network fails, so an unpatched one weakens recovery as well as security. These devices are easy to forget because they sit on separate management networks. Confirm that they appear in the review and that their firmware versions are checked on the same monthly cycle as the devices they serve.

Cloud network-as-a-service offerings

Managed network services such as cloud virtual networks, managed gateways and network-as-a-service offerings are included when CIS describes current, supported offerings as an acceptable way to stay up to date. For these, the provider maintains the software, so the review shifts to confirming that the service remains supported and that your configuration uses its current options. Ask the provider for its support and end-of-life notices in writing.

Ownership across network, security and cloud teams

Each device class usually has a different owner, such as the network team for switches, the security team for firewalls, and the cloud platform team for virtual gateways. The monthly review fails when no one owns the consolidated list. Name one accountable owner for the review record and a delegate for each device group, and document how exceptions are approved.

How an assessor tests network infrastructure up to date

This table walks through the assessment steps the CIS Controls Assessment Specification sets for Safeguard 12.1, from the prerequisite asset inventory to the evidence an assessor requests. Read each row as a question the assessor will ask, and use the common findings column to check your own records before the review starts.

Assessment element	What the assessor checks	Evidence requested	Common findings
Prerequisite inventory (Safeguard 1.1)	A detailed enterprise asset inventory exists and lists the network infrastructure that the Coverage measure depends on	Current asset inventory export showing routers, switches, firewalls and other network devices with owner and location	Inventory omits branch devices, virtual appliances or cloud network services, so the denominator is incomplete
Coverage metric	The share of network infrastructure assets that are up to date, calculated against the inventory	Coverage calculation tied to the inventory, with the version and support status recorded per device	Coverage is reported without a clear list of which devices were counted
Version review cadence	Network infrastructure software versions are reviewed monthly or more often to confirm they are still supported	Dated review records or tickets for each monthly review, with the reviewer named	Version reviews exist but are undated or cannot be linked to specific devices
Thirty-day failure threshold	The measure scores zero and fails if more than thirty days have passed since the last review of network infrastructure	Date of the most recent review and a schedule showing the next review falls inside the window	Reviews happen but the last one is older than thirty days at the time of assessment
Supported software status	Each device runs the latest stable release or a currently supported network-as-a-service offering	Vendor support end dates or lifecycle records matched to each device model and software version	Unsupported hardware or end-of-life firmware still in service with no documented exception
Update currency for in-scope devices	Devices in the inventory are on current software, and any deviations are visible in the records	Version reports from device management tools or configuration backups showing installed versions	Devices upgraded in the field without a matching record update in the inventory
Vulnerability and advisory tracking	Known weaknesses in installed network software are identified and linked to the review process	Advisory or vulnerability scan output tied to the same device list and the review date	Scanner results are not reconciled with the inventory, so unpatched devices go unrecorded

Implementing a monthly network version review that passes

This sequence builds a documented inventory, a named monthly review and a dated trail of version checks and remediation, so the organization can show that its network infrastructure stays on supported software. Each step ends with an artifact an assessor can inspect.

Build the network device inventory first
Start by listing every router, switch, firewall, wireless controller, load balancer and other network device in scope, with its location, owner and management address. The CIS assessment specification treats a detailed asset inventory (Safeguard 1.1) as a prerequisite for measuring Safeguard 12.1, so this list is the foundation for everything after it. Confirm the inventory against cloud accounts and data center records, not only against the team's memory. Done when an owner has signed off the list and it is stored under change control.
Record software versions and support end dates
For each device, record the installed operating system or firmware version, the vendor's support status and the end-of-support date published by the vendor. Where a network-as-a-service offering is used instead of owned hardware, record the service's current supported release or the provider's stated support terms. Tools such as GLPI can hold this record in its Assets module, and a discovery agent can populate it, but the vendor's support pages remain the reference for support dates. Done when every in-scope device has a version and a support status entry with its source noted.
Assign a monthly review owner and calendar
Name one accountable owner for the network version review and a second person who can cover absences. Put a recurring calendar entry in place for the monthly review and state in the procedure that reviews can happen more often when needed, as Safeguard 12.1 permits. The assessment specification fails the measure if more than thirty days pass since the last review, so the calendar and the escalation path for missed reviews matter. Done when the procedure names the owner, the cover and the review interval, and the calendar entries exist.
Compare versions against support status and latest releases
At each review, compare every device's recorded version with two references: the vendor's current support status and the latest stable release the vendor publishes. Flag devices that are end of support, past their support window, or running a version behind the current stable line without a documented reason. Vulnerability data from tools such as Greenbone Community Edition or Fleet can support this comparison for software they can detect, but they do not replace the vendor's support statement. Done when the review produces a dated comparison table with each device marked current, at risk or unsupported.
Plan and track remediation for outdated devices
For every device marked at risk or unsupported, open a tracked remediation item that names the planned action, such as an upgrade, a replacement or a documented compensating decision signed by the risk owner. Link each item to a change record so the upgrade is tested and approved through the normal change process. Keep items open until the device is verified on a supported version at the next review. Done when each flagged device has a ticket with an owner, a planned action and a closure record.
Retain dated review records
Store each monthly review as a dated record containing the device list, the version comparison, the reviewer's sign-off, the remediation tickets and any exceptions with their approvals. Keep these records in a location with access control and retention rules that the organization sets. An assessor will usually sample several months of records to confirm the review happened on schedule and that findings were acted on, so gaps in the sequence are the most common finding. Done when an assessor could pick any month and trace the inventory, the comparison and the closed remediation items.
Confirm the evidence with the auditor early
Before the first formal assessment, walk the procedure, one sample review record and one remediation trail with the independent auditor or assessor, and ask which evidence format they accept. DeployOpen can prepare the inventory, the review templates and the record structure, but the assessor decides whether the evidence is sufficient. Note any questions the assessor raises and update the procedure before the next monthly cycle. Done when the assessor has confirmed the record format in writing or in the engagement notes.

Evidence that shows network infrastructure is up to date

Safeguard 12.1 is tested through records, not promises: an assessor expects to see what devices exist, what versions they run, when someone last reviewed them and what happened to anything out of support. The six artifacts below connect those answers, and each one should be refreshed on the same review cycle so the set stays consistent between audits.

Current network asset inventory with versions

This is the population every other artifact is measured against. Each routers, switches, firewalls and other network device should appear with its model, serial number, owner, location and installed software version. Safeguard 1.1, the detailed enterprise asset inventory, is a prerequisite for measuring 12.1, so an assessor will first ask whether the list is complete. Compare the inventory against discovery results and the network diagram before accepting it. An inventory missing devices makes every coverage figure meaningless.

Dated monthly version review records

Safeguard 12.1 asks for network infrastructure software versions to be reviewed monthly or more often to confirm they remain supported. Keep a dated record for each review showing who ran it, which devices were checked and which versions were confirmed or flagged. Assessors look for an unbroken sequence of entries. The measurement fails if more than thirty days pass since the last review, so the record must show the gap is closed on time, not reconstructed afterward.

Vendor support status snapshots

A review record says a device was checked, but the snapshot shows what the vendor said about it on that date. Capture the end-of-support and end-of-life dates for each software release in use, with the source page and capture date. Vendor lifecycle pages change, so a snapshot taken during the review is stronger evidence than a remembered date. Ask the vendor or your support contract to confirm any date that is not published openly.

Remediation tickets with closure dates

When a device runs an unsupported version or a version with a known vulnerability, the finding should create a ticket with an owner, a target date and a closure date. Assessors sample these tickets to confirm that flagged devices were actually upgraded or moved to a supported option, and that closure dates fall within a reasonable window. Vulnerability scanning results can feed these tickets. Confirm that scanner findings for network devices are matched to the correct firmware version, since generic scans can miss them.

Exception records with compensating controls

Some devices cannot be upgraded on schedule because of vendor dependencies, certified configurations or hardware limits. Each one needs a formal exception that names the device, the reason it cannot be updated, the approver, an expiry date and the compensating controls such as network isolation, restricted management access or enhanced monitoring. Assessors check that exceptions expire, are reviewed and are not used as a permanent way around the safeguard. Confirm how your organization's risk acceptance process handles these records before the first audit.

Review calendar with named owners

A calendar shows that the monthly review is planned, not only that it happened. List each recurring review, the named owner, a backup owner and the date of the next occurrence, and tie the calendar to the inventory so new devices enter the cycle automatically. Assessors compare the calendar against the review records to confirm there were no silent gaps. Name people by role where possible, and update the calendar when staff change so the owner is never an unknown person.

What keeping network infrastructure up to date costs

This table compares the cost components of Safeguard 12.1 by who is paid, whether the cost is one-time or recurring, what drives it up, and how to reduce it. Use it to frame a written quote, since no price or duration is supplied for this safeguard. The main takeaway is that the largest recurring costs come from the monthly version review and the change windows that follow it, so the estate size and vendor count matter more than the tooling line.

Cost component	Who is paid or who bears it	One-time or recurring	What drives it up and how to keep it down
Tooling or licenses	Software vendors or open-source support providers	Recurring if commercial; one-time setup for self-hosted tools	Commercial inventory and vulnerability products scale with device count. Self-hosted options such as GLPI, Wazuh and Greenbone can remove most license spend, but confirm feature fit and support terms first.
Inventory setup and maintenance	Internal network or platform engineers, or an implementation partner	One-time build, then recurring upkeep	Safeguard 12.1 depends on Safeguard 1.1, so an incomplete asset inventory adds rework. Keep the device list in one system of record to limit effort.
Monthly version review	Internal network engineers or a managed service provider	Recurring, at least monthly	Device count, number of vendors and multi-site estates raise review effort. Standardize vendor lists and automate version collection where the platform supports it.
End-of-support hardware	Hardware budget owners and procurement	One-time replacement cost per device, plus recurring extended support where offered	Aging devices that vendors no longer patch can force replacement. Track end-of-support dates in the inventory so refresh costs are planned.
Remediation labor and change windows	Network engineers, change managers and sometimes outside contractors	Recurring, driven by release frequency	Each update needs testing, scheduling and rollback planning. Batch updates by site or device role and reuse change templates to reduce labor.
Evidence upkeep	Compliance or security staff	Recurring, usually tied to the monthly review	Keep dated review records, inventory exports and change tickets together. Store them in a central location so each review produces evidence without rework.
External review or testing	Independent assessors or testing firms	Recurring if commissioned each cycle	Scope, number of sites and sampling depth affect the fee. Ask the provider to state what is sampled and how many review periods are covered.
Auditor sampling time	Independent auditor or assessor	Recurring for each assessment	Auditors sample inventory records and review dates. Clean, consistent records shorten sampling. Ask the auditor which evidence and periods they will test before work begins.

Open-source tools that produce inventory and version evidence

Safeguard 12.1 is measured against an inventory of network infrastructure and evidence of current software versions. The four tools below each cover part of that chain: GLPI records the devices, Wazuh and Fleet report the software on them, and OpenVAS tests whether known weaknesses remain. None of them replaces the monthly review that the Safeguard requires.

GLPI asset inventory

GLPI's Assets module records network equipment, alongside computers, software, printers and racks. Entries can be typed in manually or pushed by the GLPI Agent through the native inventory built into GLPI since version 10. For Safeguard 12.1, the inventory is the denominator for the Coverage metric, so every switch, router and firewall must appear in it. Confirm whether your appliances report firmware or OS versions automatically, or whether those fields need manual updates at each monthly review. License: GPL-3.0-or-later.

Wazuh Syscollector inventory

The Wazuh Syscollector module collects hardware, operating system, installed software, network interfaces, open ports, running processes and services from each endpoint. Results are stored in the Wazuh indexer and shown in dashboard reports, which gives you a dated record of versions on hosts that run agents. Syscollector runs on endpoints, so it covers network management servers, jump hosts and appliances only where an agent can be installed. Confirm agent support for each device class before relying on it. License: GPL-2.0-only.

Fleet vulnerability matching

Fleet matches the software installed on enrolled hosts against vulnerability sources, including the NVD, OVAL definitions, Microsoft security bulletins, Amazon Linux advisories and OSV. Its output shows which installed versions have known issues, which is the question Safeguard 12.1 asks when a version is no longer supported or patched. Fleet reports on hosts it enrolls, so network devices without a host agent need a separate version check. Confirm which of your platforms Fleet covers and which advisory sources apply to them. License: MIT.

Greenbone Community Edition scanning

The OpenVAS Scanner in Greenbone Community Edition runs vulnerability tests from the daily updated Greenbone Community Feed against target systems, controlled by gvmd. Scan results show whether a network service on a target is exposed to a known weakness, which supports the upgrade decisions behind Safeguard 12.1. Scans test what the network can reach, so they complement inventory records rather than replace them. Confirm that test coverage includes your specific firmware families, and record scan dates for the monthly review. License: AGPL-3.0-or-later.

Who owns the monthly review and what a partner can take on

Your organization owns Safeguard 12.1. The CIS Controls are a set of practices the enterprise adopts for its own cybersecurity, so no outside party can accept the risk of an unsupported router or firewall on your behalf. Someone on your staff must be named as the review owner, must run or sign off the monthly check of network infrastructure software versions, and must decide what happens when a device is out of support or cannot be upgraded in time.

Review owner: A named role, such as the network engineering lead, who is accountable for the monthly review and for the record that it happened.
Risk decisions: Choosing whether to upgrade, replace, isolate or accept a device that has reached end of support, and recording the reason.
Exception approval: Approving any device kept outside the review cycle, with a documented compensating measure and an expiry date.
Vendor and support tracking: Monitoring vendor end-of-support notices for each model and version in the inventory.
Change execution: Scheduling and carrying out patches or replacements through your own change process.

Before you engage anyone, confirm that the review owner, the exception process and the change window are written down and that your team can produce the monthly records on request.

Where organizations fall short on network patch currency

Most failures under Safeguard 12.1 are not about missing patches. They come from an incomplete device list, reviews that leave no dated record, and exceptions nobody owns. Each card below names one gap and the check that closes it.

Incomplete device inventory

Safeguard 12.1 can only be measured against the devices you know about. Virtual appliances, branch routers, and out-of-band management controllers are often missing from the network list because they sit outside the core network team's tooling. Start by reconciling the inventory against cloud accounts, hypervisor consoles, branch purchase records and out-of-band management networks. Confirm that Safeguard 1.1, the enterprise asset inventory, covers these devices before you report any coverage figure.

Versions reviewed but not dated

A review that confirms a firmware version without recording when it was checked cannot show the monthly cadence the assessment expects. Keep a dated record for each device: the version found, the date of review, the reviewer and the result. Store these records in a system of record rather than a spreadsheet that gets overwritten. An assessor will ask for the most recent review date for each device class.

End-of-support status not tracked

A device can be on the latest patch and still run an operating system that the vendor no longer supports. Record the vendor's end-of-support date for every model and software branch in use, and flag devices that reach that date within your planning window. Confirm the dates directly with each vendor's lifecycle notices, since they change and are not part of this page's researched facts.

Quarterly reviews instead of monthly

Safeguard 12.1 asks for software versions to be reviewed monthly or more often to confirm they are still supported. A quarterly cycle leaves a gap of several months in which a device can fall out of support without anyone noticing. Set a recurring monthly task with a named owner, and treat a missed cycle as a finding. The assessment measures the time since the last review, so a review that slips past thirty days fails.

Exceptions without owners or expiry

Some devices cannot be upgraded on schedule because of change freezes, vendor dependencies or legacy applications. These exceptions are acceptable only when they are documented. Each exception should name an accountable owner, a reason, a compensating control such as segmentation or restricted management access, and an expiry date that forces a decision. Review the exception register at each monthly cycle so that expired exceptions are escalated rather than renewed silently.

Cloud network services assumed current

Managed network services such as cloud virtual networks, gateways and managed firewalls are often treated as always current because the provider maintains them. Safeguard 12.1 accepts currently supported network-as-a-service offerings, but you still need evidence. Record the service version or configuration baseline, the provider notices you receive, and the date you last confirmed support status. Ask the provider for its change and support documentation, and keep that evidence with the device records.

Questions buyers ask about Safeguard 12.1

How much effort does the monthly network version review take?

The effort depends mostly on how many network devices and software platforms you run, how current your inventory is, and how many vendors publish security advisories you must track. Safeguard 12.1 asks you to review network infrastructure software versions monthly or more often to confirm they are still supported, so the work recurs every cycle. A well-kept inventory turns the review into a comparison of recorded versions against vendor support dates. Ask any partner to estimate the recurring hours from your device count, vendor mix and change calendar in writing before you commit.

How long does the first inventory and review cycle take to set up?

The first cycle takes longer than later ones because the inventory has to be built or cleaned before any version check means anything. Setup covers listing every router, switch, firewall and other network device, recording its software version and support status, and agreeing who receives the monthly output. No duration is fixed for this work, so the timeline should come from your environment and be written into the agreed scope. Ask for milestones that show when the inventory is complete and when the first review is signed off.

Can an in-house team run Safeguard 12.1 without a partner?

Yes, an in-house team can meet the safeguard if it owns the inventory, the review schedule and the evidence. CIS Controls content is free for any organization to use to improve its own cybersecurity, so no license is needed to adopt it. A partner adds value mainly when the team lacks time to build tooling, such as an asset inventory feed and a vulnerability matching process. Either way, the organization remains accountable for its controls, and only an independent auditor can issue an assessment report.

What does the monthly review need from network and change teams?

The review needs network engineers to confirm device models, firmware and software versions, and change teams to record upgrades and approved exceptions. Network teams also need to tell reviewers when a platform reaches end of support so the risk can be logged and scheduled. Without a shared change record, the review cannot tell whether a version is current or simply unrecorded. Agree on a named owner, a fixed monthly date and a route for escalating unsupported versions before the review starts.

How does Safeguard 12.1 relate to Safeguard 1.1 and the rest of Control 12?

Safeguard 12.1 depends on Safeguard 1.1, which asks for a detailed enterprise asset inventory, because you cannot measure currency for devices you have not recorded. The CIS Controls Assessment Specification scores 12.1 with a coverage metric, the share of network infrastructure assets that are up to date. Its neighbors in Control 12 cover architecture, diagrams, secure management, centralized AAA and remote access, so the inventory and version records also support those safeguards. Confirm the exact prerequisites and metrics in the CIS Controls Assessment Specification before writing your procedure.

What tooling can produce evidence for the version review?

Open-source asset management and inventory tools can hold the device register and version records that the review depends on. GLPI's Assets module can track network equipment, and its native inventory can be fed automatically by the GLPI Agent. Wazuh's Syscollector collects operating system, software and network interface data from endpoints, which helps where network devices run general-purpose operating systems. Confirm which device types each tool can read in your environment before choosing one, since coverage of appliances and firmware varies.

What should a partner's written scope include for Safeguard 12.1?

A written scope should name the devices and sites covered, the inventory source of truth, the review cadence and the report format. It should list the deliverables, such as the baseline inventory, the monthly review template, the escalation procedure and the handover to your team. The scope should also state what the partner will not do, including that any audit report or certification must come from an independent auditor. Ask for acceptance criteria and a support model, and confirm the fee basis in the written quote.

How DeployOpen scopes and prepares network currency evidence

DeployOpen helps organizations set up the systems, inventories and review routines that show network infrastructure is kept on supported software under Safeguard 12.1. The organization owns its controls and its monthly review decisions, while DeployOpen plans, implements and documents the open-source tooling and evidence that support them.

How we scope

Agree in writing which routers, switches, firewalls and other network devices fall within the Safeguard 12.1 scope.
Confirm the dependency on an enterprise asset inventory under Safeguard 1.1 and record how that inventory is maintained.
Define the monthly version review cadence, its owner and the escalation path for devices past vendor support.

How we build

Deploy GLPI to hold network equipment records, populated manually or through the GLPI Agent native inventory.
Configure Wazuh Syscollector to collect network interfaces, operating system and software details from supported endpoints.
Set up Fleet or Greenbone Community Edition to match installed software against known vulnerabilities and report unsupported versions.

How we hand over

Deliver a documented monthly review procedure, with a dated record template showing each review and its findings.
Provide exported inventory and version reports that show the share of network infrastructure assets that are up to date.
Hand over runbooks so the organization's staff can operate the tooling and produce evidence without DeployOpen.

How we support

Offer ongoing support, upgrades and continuous testing as a retainer after the fixed-scope work ends.
Ask the organization's auditor or assessor which evidence formats they accept before the reports are finalized.
Confirm with the auditor that DeployOpen's preparation does not replace the independent assessment of Safeguard 12.1.