CIS 12.3 Secure network infrastructure management

What Safeguard 12.3 asks for and why IG2 enterprises face it

Safeguard 12.3 asks you to manage your network infrastructure securely. CIS gives two example implementations: keeping device configuration in version-controlled infrastructure as code (IaC) and using secure protocols such as SSH and HTTPS for administration. If you are a compliance lead or engineer who must show that routers, switches, firewalls and other network devices are managed this way under CIS Controls v8.1, the question an assessor will ask is simple: can you show who changed each device, what changed, and that administrative sessions were encrypted? The safeguard sits in the Network asset class and the Protect security function, and it is placed in Implementation Group 2, so it applies to IG2 and IG3 enterprises but not to IG1 organizations.

The risk behind 12.3 is familiar to any network team. Devices changed by hand through a console session, a shared administrative login or an unencrypted management interface leave no reliable record, and each undocumented edit moves the running configuration further from what was approved. That drift is what attackers find: a forgotten management service, a weak administrative protocol or an exposed rule that nobody remembers adding. Treat each device as an asset that needs an owner, a known baseline and a recorded change path, not as a box that someone configured years ago.

The difficulty is that 12.3 depends on other safeguards. The CIS Controls Assessment Specification lists Safeguards 1.1 (detailed enterprise asset inventory), 4.2 (a secure configuration process for network infrastructure) and 12.4 (architecture diagrams) as prerequisites, so you cannot measure 12.3 until you know which devices exist, how they should be configured and how traffic flows between them. Confirm with your own team how many devices lack a current inventory entry and how many have configuration changes made outside any tracked process before you commit to a scope. Those two counts will shape the effort more than any tooling decision.

Which network devices, teams and tools fall under 12.3

Safeguard 12.3 is measured as coverage, so the first decisions are what counts as network infrastructure, which segments run under version-controlled code, and who changes device configuration. Each card below is a scoping question that moves the evidence you need to produce.

Physical and virtual network devices

Scope starts with every routers, switches, firewalls and load balancers the enterprise operates, including virtual appliances running on hypervisors and firewall instances in cloud accounts. Safeguard 12.3 is measured against the share of network infrastructure assets using encrypted sessions, so each device you leave off the list is a device the measure never sees. Confirm the list against your Safeguard 1.1 asset inventory before counting anything.

Cloud virtual networks

Virtual private clouds, subnets, route tables, security groups and cloud-native gateways are network infrastructure even though no one racks them. Teams often manage these through console clicks or separate pipelines, which places them outside the IaC coverage measure. Decide early whether each cloud account is in scope and record which network constructs are defined in code.

Segments managed through IaC

The Infrastructure-As-Code Coverage metric is the share of network segments covered by version-controlled code, so the unit of measurement is the segment, not the device. A segment counts as covered only when its definition lives in version control and changes flow through that code. Map each segment to its repository, branch and deployment path, and list the segments that are still configured by hand.

Teams that configure devices

Network engineering, platform teams, security staff and managed service providers may all change device configuration. Each group that can alter a device needs to be in the scope statement, along with the access path it uses and the way its changes are recorded. A provider who applies changes outside your repository lowers your coverage figure even when their work is correct.

Whether IG2 or IG3 applies

Safeguard 12.3 sits in Implementation Group 2, so it applies to IG2 and IG3 enterprises and not to IG1. An IG1 organization may still adopt it as good practice, but it is not required to report it against that tier. Confirm your Implementation Group with your own risk and sensitivity profile, and record the decision in writing so auditors and customers can see the basis.

Unclear inventory widens scope

If the asset inventory is incomplete, the denominator of every coverage measure becomes uncertain, and an assessor will expand scope to include what cannot be shown to be excluded. Unknown devices, shadow cloud accounts and retired equipment still on the network all widen the work. Reconcile discovered devices against your inventory and document exclusions with a stated reason.

How an assessor tests 12.3 under the CIS Assessment Specification

This table sets out how the CIS Controls Assessment Specification frames the test for Safeguard 12.3, from prerequisites through the two metrics to the evidence and common findings. Read it as a map of what gets measured; the assessing body decides how sampling and verification are carried out.

Test element	What the assessor checks	Evidence to prepare	Common finding
Prerequisite 1.1	Enterprise asset inventory covers the network infrastructure in scope before 12.3 is measured	Current asset inventory listing routers, switches, firewalls and management hosts with owners	Network devices missing from the inventory, so coverage metrics cannot be trusted
Prerequisite 4.2	A secure configuration process exists for network infrastructure and is followed	Written hardening process, baseline configurations and change records for network devices	Baselines documented but not applied to devices in production
Prerequisite 12.4	Architecture diagrams show the network segments and management paths that 12.3 covers	Current architecture diagram(s) with a review date and the segments they show	Diagrams that omit management networks or out-of-band paths
Metric: Encrypted Session Coverage	Share of network infrastructure assets whose management sessions use encrypted protocols	Device list with management protocol settings, configuration exports and session or access logs showing SSH or HTTPS use	Management interfaces still reachable over plaintext protocols such as Telnet or HTTP
Metric: Infrastructure-As-Code Coverage	Share of network segments whose configuration is defined and changed through version-controlled infrastructure as code	Repository history, pipeline records and the mapping of each segment to its code module	Manual changes made directly on devices outside version control, so the repository no longer matches running configuration
Drift and exceptions	Whether any segment or device falls outside the measured coverage and whether exceptions are approved	Drift detection output, exception register with approvals and dates	Undocumented exceptions that exist only in the device configuration
Sampling and verification method	Set by the assessing body, not by the specification, which defines what to measure and not how	Ask the assessor in advance which devices, segments and time periods they will sample and how they will verify	Assumptions about sample size or method that differ from the assessor's approach

How to implement 12.3 in the order an assessor will check it

This sequence moves Safeguard 12.3 from prerequisites to measured coverage, so each step produces an artifact an assessor can trace back to the Safeguard. It starts with the inventory and diagrams the Assessment Specification requires, then builds configuration, change control and encryption on top of them.

Confirm the asset inventory and diagrams
Before measuring 12.3, confirm that the detailed asset inventory required by Safeguard 1.1 and the architecture diagrams required by Safeguard 12.4 exist and match the live environment. The network team owns this check, with the security team reviewing it. The output is a reconciled list of network infrastructure assets (routers, switches, firewalls, load balancers and management controllers) with a current diagram for each segment. Done means every network device in the inventory maps to a diagram segment, and any gap is logged as an open item.
Define the secure configuration process for network devices
Write the secure configuration process for network infrastructure that Safeguard 4.2 calls for, covering the approved baseline, who may change it, how deviations are approved and how the baseline is reviewed. The network engineering lead approves the document, and the security function confirms the baseline names the management protocols permitted on each device class. The output is a signed baseline document and a device-class table that the later IaC repository will implement. Done means every device class in the inventory has a documented baseline.
Move device and segment configuration into version control
Express device and segment configuration as infrastructure as code (IaC) stored in a version-controlled repository, so that the running state can be traced to a reviewed commit. Network engineers write the definitions, and a second engineer reviews each change before it merges to the main branch. The output is a repository of device and segment definitions, a merge record for each change and a documented path for deploying changes. Done means the running configuration of every in-scope segment can be reproduced from the repository.
Enforce encrypted management sessions
Configure every network device so that administrative access uses SSH or HTTPS, and disable plaintext management protocols such as Telnet and HTTP on the management plane. The network team applies the change through the repository so the setting is recorded as code. The output is a configuration file set in which each managed device specifies encrypted management only, along with a list of any device that cannot yet meet the requirement. Confirm the setting on the live device, not only in the file, because a file can differ from the running state.
Measure encrypted session and IaC coverage
Calculate the two metrics the Assessment Specification uses for Safeguard 12.3: Encrypted Session Coverage, the share of network infrastructure assets using encrypted sessions, and Infrastructure-As-Code Coverage, the share of network segments covered by version-controlled IaC. The denominator for each is the population from the inventory and diagrams in step one. The output is a coverage report with both percentages, the population used and the date of measurement. Document the method so an assessor can repeat it.
Record exceptions with owners and dates
List every device or segment that falls outside encrypted management or IaC coverage, and record for each an accountable owner, the reason, a compensating control and a target date for closure. The risk owner approves each exception, and the list is reviewed on the cycle set in the secure configuration process. The output is an exception register that links each item to the coverage report. Done means no asset is missing from both the coverage report and the register.

Evidence that passes 12.3 and how to keep it current

Safeguard 12.3 is measured through two coverage metrics, so the evidence is mostly data an assessor can recalculate. The cards below cover the artifacts that feed those metrics and the records that prove the prerequisites are in place, along with a routine that keeps each artifact current between assessments.

Version-controlled IaC repository

The repository holding device and segment configuration, with commit history and change review records, is the source the Infrastructure-As-Code Coverage metric depends on. Check that every production network device or segment has its configuration in the repository, that changes are made through reviewed merge or change requests, and that the branch protections stop direct edits to the live devices. Export the commit log and pull request approvals quarterly, and snapshot the repository state at each change window so the record is dated.

Infrastructure-as-code coverage calculation

This is the worked calculation of the share of network segments covered by version-controlled infrastructure as code, set against a current segment list. Keep the segment list derived from the Safeguard 1.1 inventory and the Safeguard 12.4 diagrams so the denominator matches what exists. Record which segments are excluded and why. Recalculate the figure on a schedule and whenever a segment is added, retired or moved to manual management, so the number reflects the network on the assessment date.

Encrypted session coverage report

This report shows the share of network infrastructure assets that manage devices over encrypted sessions, with the protocol settings for each device. Pull the management protocol configuration per device, record the SSH and HTTPS listeners and their versions or cipher settings, and flag any device still reachable over an unencrypted protocol. Generate the report from configuration exports or a scanner at a fixed cadence, and regenerate it after firmware upgrades, since upgrades can re-enable default services.

Management service configuration records

These are the exported management service settings for each device showing SSH and HTTPS enabled and plaintext services such as Telnet and HTTP disabled. The records show what the device actually runs, not only what the configuration file says. Confirm the settings with a read-only check on the device or a compliance scanner, store the results with timestamps, and compare them against the repository. Review the records quarterly and after any emergency change, since out-of-band fixes often bypass the repository.

Exception register

The exception register lists each device, segment or protocol that cannot meet the secure management standard, with the reason, the compensating control, an owner and an expiry date. Assessors look for exceptions that are approved, time-limited and reviewed, not for an absence of exceptions. Review open entries at each quarterly cycle, close those that are resolved, and record approval changes in the same change system used for the repository so every exception has a traceable decision.

Linked records for 1.1, 4.2 and 12.4

The assessment specification treats Safeguards 1.1, 4.2 and 12.4 as prerequisites for measuring 12.3, so the inventory, secure configuration process and architecture diagrams must agree with the IaC repository and encrypted session data. Maintain a cross-reference that maps each managed device to its inventory entry, its hardening baseline and its diagram location. Reconcile these records monthly, and after any device is added or removed, so a gap between the inventory and the managed configuration is found before an assessor finds it.

What meeting 12.3 costs in money and effort

This table lists each cost component of building and evidencing Safeguard 12.3, who is paid for it, whether it is one-time or recurring, and what pushes it up or down. Use it to structure a written scope and to compare quotes line by line, since no fixed price applies across environments.

Cost component	One-time or recurring	What drives it up	What lowers it
Tooling and licenses	Recurring	Commercial network management or configuration tools priced per device or per seat, and vendor-specific licensing for each device family	Self-hosted open-source tooling such as OPNsense for firewall rules and Wazuh for configuration assessment, which removes license spend but still needs hosting and upkeep
Engineering time to build the IaC baseline	One-time	Many device types and vendors, no existing templates, and undefined naming, addressing or change standards	A single IaC toolchain, reusable modules, and a documented secure configuration process under Safeguard 4.2 agreed before build starts
Migration of existing devices into code	One-time	Undocumented or hand-edited configurations, drift between devices, and gear whose state cannot be exported cleanly	A current asset inventory under Safeguard 1.1 and a configuration export taken before changes, so each device is brought under version control in known batches
Protocol remediation on legacy gear	One-time, with recurring replacement cycles	Legacy hardware that cannot run encrypted management protocols, requiring workarounds, jump hosts or hardware replacement	A list of affected devices agreed early, a phased replacement plan, and isolation of legacy management interfaces while they remain in service
Evidence upkeep	Recurring	Frequent configuration changes, manual screenshots or exports, and evidence not tied to change records	Evidence generated automatically from the IaC repository, commit history and assessment reports, with a fixed review cadence
External review or testing	Recurring, usually per engagement	Broad scope across many segments, first-time testing of management interfaces, and remediation rounds after findings	Clear written scope, a defined list of management interfaces, and internal pre-checks of encrypted session coverage before external work
Auditor sampling	Recurring, per assessment cycle	Large device populations, inconsistent evidence formats, and gaps between documented and actual configurations	Consistent evidence for the two CAS metrics, Encrypted Session Coverage and Infrastructure-As-Code Coverage, kept in one place the auditor can sample

Which self-hosted open-source tools produce 12.3 evidence

Safeguard 12.3 is scored on encrypted session coverage and infrastructure-as-code coverage, so the evidence has to show both how administrators reach network infrastructure and how its configuration is defined and reviewed. The tools below each cover a different part of that picture, and none of them replaces the organization's own configuration baseline, change process or assessor-reviewed records.

Wazuh configuration assessment

Wazuh Security Configuration Assessment (GPL-2.0-only) scans monitored endpoints against YAML policies, mostly based on CIS benchmarks, and reports failed checks with remediation advice. For Safeguard 12.3, it helps show that managed hosts that front network infrastructure, such as management servers and jump hosts, keep SSH and HTTPS settings that match the approved baseline. Confirm that your network devices are in scope, since agent-based scanning may not reach appliances that cannot run an agent, and check whether custom policies are needed for your secure-protocol standard.

Fleet policies for device checks

Fleet (MIT) policies are yes or no questions asked of devices as osquery queries, and the policies page shows which devices pass or fail each one. You can write checks such as whether an administrative workstation has an approved SSH client configuration or whether a management tool is installed with an unapproved protocol enabled. The pass and fail history is useful recurring evidence, but you must confirm that the queries you need can reach the devices in your network, including any that Fleet cannot enroll.

OPNsense rules and logs

OPNsense (BSD-2-Clause) is a stateful packet filter whose rules pass, block or reject traffic by source, destination, port and protocol. Aliases group addresses, so a single alias can define the administrator subnet allowed to reach management ports, and per-rule logging lets reviewers see matches in the live log view. For Safeguard 12.3, the rule set and its log history can show that management traffic is limited to approved protocols. Confirm that rule exports and logs can be retained in the form your assessor expects and that your vendor devices are managed through a different control plane.

Coraza for web management interfaces

Coraza (Apache-2.0) is a web application firewall compatible with ModSecurity SecLang rulesets and the OWASP Core Rule Set. It defends against attacks such as SQL injection, cross-site scripting and code injection, and integrates with Caddy, HAProxy, Traefik and Nginx. Use it to protect web-facing management consoles or services that sit in front of your infrastructure, and keep its rule logs as evidence of that protection. It does not configure or secure network devices themselves, so confirm with your assessor that device management over HTTPS is covered by other evidence.

Who owns 12.3, what a partner can take on, and where the auditor stops

Your organization owns Safeguard 12.3. CIS frames the Safeguard as managing network infrastructure securely, and an assessor will look to you, not your vendor, for the decisions and the accountability behind the configuration. Keeping that ownership in-house is what makes the evidence yours to defend when questions come.

Infrastructure as code design decisions: Choose the repository structure, the review rules for changes, and which network segments and device classes fall under version control.
Device changes and approvals: Approve and execute changes to live network devices, and keep the change records that tie each change to a reviewed commit.
Secure management standards: Decide which protocols are permitted for administration, such as SSH and HTTPS, and which are prohibited, and record that decision in policy.
Risk acceptance of exceptions: Any device that cannot use encrypted sessions or code-managed configuration needs a documented exception, an owner and an accepted risk.
Prerequisite safeguards: Maintain the asset inventory (1.1), the secure configuration process for network infrastructure (4.2) and the architecture diagrams (12.4) that the assessment specification treats as prerequisites.

Before engaging anyone, confirm that a named owner can explain each design decision and sign each exception.

Where 12.3 programs usually fall short and how to close each gap

Most Safeguard 12.3 programs fail on the same few points: changes made outside version control, partial coverage, plaintext management paths, stale documentation, unowned exceptions and missing evidence at audit time. Each card below names the cause, the fix and the evidence an assessor would expect to see, measured against the Encrypted Session Coverage and Infrastructure-As-Code Coverage metrics.

Direct changes outside version control

Engineers often fix a switch, firewall or router by logging in and typing commands, so the running configuration drifts from anything in the repository. Under 12.3, that drift makes the Infrastructure-As-Code Coverage metric look better than the real state of the network. Fix it by making the repository the only change path, with device access restricted to pipeline service accounts and emergency changes committed back within a set window. Evidence: a commit history for each change, and a periodic comparison between the repository and the running configuration.

IaC covering only some segments

A repository often starts with core routing and leaves branch sites, lab segments or cloud virtual networks managed by hand. The metric counts the share of network segments covered by version-controlled code, so every unmanaged segment lowers the score. Start by reconciling the repository against the asset inventory from Safeguard 1.1, then bring each remaining segment under code or record it as an approved exception. Evidence: a segment-by-segment coverage report tied to the inventory.

Plaintext management interfaces

Device administration pages, Telnet, SNMP v1 or v2c and unencrypted HTTP consoles often stay enabled after installation because they were never removed from the default build. The Encrypted Session Coverage metric counts only sessions that use encryption, so each plaintext path reduces the score. Disable plaintext services on every device, require SSH and HTTPS, and confirm the change on each platform's own configuration reference. Evidence: a configuration scan showing only encrypted management services listening.

Missing or stale architecture diagrams

Safeguard 12.4 is a prerequisite for measuring 12.3, so outdated or absent diagrams break the chain before any 12.3 test begins. Diagrams drawn once at deployment rarely reflect later segments, new cloud links or retired firewalls. Assign a named owner, tie each diagram to the repository so changes update it, and review it on the annual cycle the Safeguard describes. Evidence: a dated diagram that matches the current configuration and carries the reviewer's name.

Exceptions without owner or review date

Legacy devices that cannot run SSH or cannot be placed in code tend to accumulate as informal exceptions with no record of who approved them or when they will be retired. An assessor reads an undocumented exception as a failure, even when the device is in a justified state. Record each exception with an accountable owner, a business reason, a compensating control and a review date, then retire or re-review it on schedule. Evidence: an exception register with approvals and dated review entries.

No evidence snapshot at audit time

Teams often gather screenshots and exports in the final weeks before an assessment, which produces inconsistent data and gaps in the review period. Both metrics need values that hold for the whole period under review, not only on the day of testing. Schedule automated exports of repository coverage, encryption status and configuration checks, store them in a retained location, and keep dated copies. Evidence: a timestamped series of coverage and encryption reports that spans the assessment period.

What buyers ask before bringing in help for 12.3

Does Safeguard 12.3 apply to an IG1-only enterprise?

No. CIS places Safeguard 12.3 in Implementation Group 2, so it applies to IG2 and IG3 enterprises and is not part of the IG1 set. IG1 covers essential cyber hygiene, and the only IG1 safeguard in Control 12 is 12.1, which concerns keeping network infrastructure current. An IG1 organization can still adopt secure management practices voluntarily, and a customer contract or regulator may ask for them anyway. Confirm your implementation group on the CIS Implementation Groups page, then check whether any framework you are measured against requires 12.3 in your specific case.

How much effort does an infrastructure as code migration take?

No duration or cost figure applies across environments, so the effort depends on your own estate. The main drivers are the number of device types and vendor configuration formats, how much configuration exists only on the devices, how many network segments must be covered, how much configuration drift has built up, and how strict your change approval process is. One-time work includes designing templates, importing current configurations, testing in a lab, and cutting over segment by segment. Recurring work includes maintaining the pipeline, reviewing changes and keeping the repository aligned with production. Ask for a quote built from a written scope that lists devices, segments, vendors, environments and deliverables.

Can our internal team implement 12.3 without an outside partner?

Yes. The CIS Controls are free for any organization to use to improve its own cybersecurity, so an internal team can design and build the practice without a partner. The questions to answer honestly are capacity and skills: whether engineers can write and test templates for every device family, maintain a version-controlled repository, and run the change process without slowing operations. Many organizations split the work, keeping ownership and approvals internal while bringing in specialists for the migration. Whoever does the work, the organization owns the control and the evidence, and an independent assessor is still needed for any formal result.

What does the work need from our internal network and security team?

The assessment specification lists Safeguards 1.1, 4.2 and 12.4 as prerequisites for measuring 12.3, so your team needs those in place first. That means an enterprise asset inventory (1.1), a documented secure configuration process for network infrastructure (4.2), and architecture diagrams (12.4). Your team also needs named owners who approve changes, administrative access to devices and a place to host the version-controlled repository, plus confirmed use of SSH or HTTPS for management sessions. Expect to schedule change windows and to involve the people who currently make manual changes, because their knowledge is the source of most of the configuration you must capture.

How are the two coverage metrics for 12.3 calculated and reported?

The assessment specification defines two metrics. Encrypted Session Coverage is the share of network infrastructure assets that use encrypted sessions. Infrastructure-As-Code Coverage is the share of network segments covered by version-controlled infrastructure as code. Both are shares, so the denominators come from your asset inventory (1.1) and your segment list (12.4 diagrams), and the numerators come from configuration evidence and repository records. The specification says what to measure but not how, so agree the method, data sources, scope and reporting frequency with your assessor before you start. Record the results with dates so you can show the trend over time.

Can a consultant issue the assessment result for Safeguard 12.3?

No. A consultant or implementation partner can prepare systems, configurations and evidence, and can help you test readiness, but only an independent assessor or auditor can issue an assessment result. DeployOpen works this way: it prepares systems and evidence for compliance assessments and does not issue reports, attestations or certifications. Separately, CIS Controls Accreditation, run with CREST, accredits CIS SecureSuite member organizations that provide implementation, auditing or assessment services, so ask any firm whether it holds that accreditation and which services it provides. Confirm the assessor's independence and the form of its output before the engagement starts.

How DeployOpen scopes and prepares 12.3 evidence

DeployOpen works on Safeguard 12.3 as an implementation partner: we prepare the network management systems, infrastructure as code and secure access paths that produce the evidence, while your organization owns the control. Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.

How we scope

Confirm which network devices, segments and management paths fall under the written scope for 12.3.
Check the prerequisites the assessment specification names: asset inventory (1.1), secure configuration process (4.2) and architecture diagrams (12.4).
Record which management protocols are in use today and which devices still rely on unencrypted sessions.

How we build

Place network device configuration under version control so each change has an author, a review and a history.
Configure management access over SSH and HTTPS only, with encrypted session coverage tracked per infrastructure asset.
Test rule sets and configuration changes in a non-production environment before they reach production devices.

How we hand over

Deliver the infrastructure as code repository, configuration baselines and documented change procedure for your team to operate.
Provide reports showing encrypted session coverage and infrastructure as code coverage, the two metrics the assessment specification uses.
Document each step so your auditor can trace the evidence back to the Safeguard, with the assessment left to the independent assessor.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer after handover.
Review coverage metrics and configuration drift on a schedule agreed in the written scope.
Ask your assessor or certification body early which evidence formats they accept, and confirm that scope with us before work starts.