Safeguard 12.6: Use of Secure Network Management and Communication Protocols

To meet the safeguard 12.6: use of secure network management and communication protocols requirement, you must ensure that administrative access and device management traffic use secure, encrypted protocols (and that insecure legacy options are disabled) across your environment. Operationalize it by standardizing approved protocols, enforcing them through configuration and network controls, and retaining repeatable evidence that the control operates. ¹

Key takeaways:

• Define “secure” for your environment as an approved protocol baseline (for example, SSH, HTTPS/TLS, SNMPv3) and ban cleartext management.
• Enforce the baseline with technical guardrails (device configs, NAC, firewall ACLs, management-plane segmentation, scanner checks).
• Collect evidence that proves both design (standards) and operation (configs, scans, logs, exceptions).

Safeguard 12.6 sits in a part of the CIS Controls where auditors and assessors routinely look for a simple story: “Show me that device management and administrative communications are encrypted, authenticated, and consistently enforced.” If you cannot show that story with evidence, teams end up debating intent, arguing over edge cases (printers, OT gear, legacy network appliances), and accumulating unmanaged exceptions.

For a Compliance Officer, CCO, or GRC lead, the fastest path is to treat this as a management-plane hardening requirement with three deliverables: (1) a clear standard of approved network management and communication protocols, (2) enforcement points that prevent drift, and (3) recurring evidence capture. CIS Controls v8 is a framework, not a law, so success is measured through demonstrable implementation and repeatability rather than legalistic interpretation. ¹

This page gives requirement-level guidance you can hand to network, infrastructure, and security engineering teams, then translate into audit-ready artifacts.

Regulatory text

Framework excerpt (provided): “CIS Controls v8 safeguard 12.6 implementation expectation (Use of Secure Network Management and Communication Protocols).” ¹

Operator interpretation (what this means in practice):

• For any network management or administrative communication path (human-to-device or system-to-device), you need secure protocols that provide encryption in transit and strong authentication.
• You need to avoid insecure management protocols that transmit credentials or management content in cleartext (or with weak/obsolete cryptography).
• You must be able to prove enforcement and ongoing operation, not just publish a standard. ¹

Plain-English interpretation of the requirement

Safeguard 12.6 expects you to prevent administrative and management traffic from happening over insecure protocols. If an engineer manages network gear, servers, cloud control planes, hypervisors, or security tools, the connection method must be secure by default. If a device cannot support secure management, it becomes an exception that must be isolated, time-bound, and tracked to remediation.

Think in terms of “management plane hygiene”:

• Protocols: What methods are allowed (secure) vs disallowed (insecure).
• Paths: Where management is allowed from (jump hosts, admin subnets, VPN, ZTNA).
• Proof: Configs, scan results, and logs that show the environment matches the standard.

Who it applies to (entity and operational context)

Applies to enterprises and technology organizations implementing CIS Controls v8. ¹

Operationally, it applies wherever you have:

• Network devices (switches, routers, firewalls, load balancers, WAFs)
• Server and endpoint administration (Windows admin, Linux admin, hypervisor management)
• Security tooling management (EDR consoles, SIEM forwarders, scanners, PAM systems)
• Cloud management channels (cloud console access patterns, API management endpoints)
• Third-party managed services where the third party administers your environment (you still need protocol requirements in contracts and technical enforcement where possible)

What you actually need to do (step-by-step)

Step 1: Set the “secure management protocol” baseline (documented standard)

Create a short, enforceable standard that answers:

• Allowed protocols for interactive admin: SSH, HTTPS/TLS-based admin portals, RDP protected with TLS and restricted paths (only if your security architecture permits), VPN or ZTNA for access brokering.
• Allowed protocols for network management/telemetry: SNMPv3 for polling, TLS-protected syslog where supported, API access over HTTPS/TLS.
• Banned or restricted protocols: Telnet, HTTP admin portals, SNMPv1/v2c, cleartext LDAP binds, FTP/TFTP for config transfers (unless tightly controlled and justified).
• Cryptography floor: Define minimum TLS versions/ciphers per your org crypto standard (tie to your broader cryptographic policy).

Artifact: Network Management & Administrative Protocol Standard (versioned, approved, with “allowed/banned” table). ¹

Step 2: Identify management-plane entry points and inventory scope

You cannot enforce 12.6 on assets you cannot name. Build a working scope list:

• Network device inventory from NMS/CMDB
• Server inventory from EDR/MDM
• Cloud administrative endpoints (which consoles/APIs, and how admins reach them)
• “Odd stuff” list: printers, building systems, OT/IoT gateways, storage arrays

Deliverable: Management Plane Asset Register (can be a CMDB export plus a tagged view).

Step 3: Enforce secure protocols at the device configuration layer

Engineering actions (examples; adapt to platform):

• Disable Telnet and enable SSH on network gear; require SSHv2.
• Force HTTPS for web management; disable HTTP redirect-only modes if they still accept cleartext sessions.
• Configure SNMPv3 and disable SNMPv2c where feasible.
• Disable weak/legacy crypto settings on management interfaces where devices support modern options.
• Ensure admin interfaces bind only to management VRFs/VLANs where possible.

Evidence: configuration snippets, golden templates, and “desired state” configuration baselines.

Step 4: Enforce secure protocols at the network layer (guardrails)

Assume configs drift. Add network-level controls that make insecure management harder:

• Segmentation: Put management interfaces in dedicated admin networks.
• ACLs/firewall rules: Permit management protocols only from jump hosts/PAM, admin workstations, or management subnets.
• Egress controls: Block outbound cleartext management protocols from user networks.
• Remote access controls: Require VPN/ZTNA to reach management plane; block direct exposure.

Evidence: firewall policy extracts, network diagrams, change tickets for rule deployment.

Step 5: Detect drift continuously (scans + monitoring)

Build repeatable checks:

• Authenticated configuration checks (where possible).
• Port/protocol scanning focused on management services.
• Log-based detection for prohibited management protocols (for example, detection of Telnet sessions, HTTP admin access, SNMP community strings).

Minimum evidence set:

• A scheduled scan job definition
• The latest results
• A ticket trail showing remediation or exception handling

Step 6: Handle exceptions with a real process (not a spreadsheet graveyard)

Some devices cannot support secure protocols. Your exception process must require:

• Business owner, system owner, and security approval
• Compensating controls (isolation, jump host, time windowing, monitoring)
• Sunset date and remediation plan (upgrade/replace)

Evidence: approved exceptions with review cadence and closure criteria.

Step 7: Map the control to recurring evidence capture (make audits easy)

CIS assessments often fail on evidence hygiene rather than technical intent. Make evidence capture part of operations:

• Monthly or quarterly “management protocol compliance” report
• A standard evidence packet per network segment or device class

If you use Daydream, store the standard, the scan outputs, the exception approvals, and the recurring attestations in one control record so audits do not turn into a scavenger hunt. ¹

Required evidence and artifacts to retain

Keep artifacts that prove design, implementation, and operation:

Design

• Network Management & Administrative Protocol Standard (approved)
• Cryptographic standard (TLS/SSH/SNMP guidance) referenced by the protocol standard
• Network segmentation standard for management-plane access

Implementation

• Device hardening templates / golden configs
• Firewall/ACL change records limiting management access
• PAM/jump host architecture diagram (if used)

Operation

• Latest management-plane scan results (ports/protocols)
• Monitoring alerts or SIEM queries for prohibited protocols
• Exception register with approvals and compensating controls
• Remediation tickets showing closure

Common exam/audit questions and hangups

Expect these questions:

• “Show me which protocols are approved for device management and where that’s documented.” ¹
• “Prove Telnet/HTTP/SNMPv2c are disabled across in-scope devices.”
• “How do you prevent an engineer from managing devices from an untrusted network?”
• “How do you detect drift or re-enablement after a break/fix event?”
• “How are exceptions approved, reviewed, and retired?”

Common hangup: teams show a policy but cannot show enforcement artifacts or scan results.

Frequent implementation mistakes and how to avoid them

1. Policy-only compliance. Fix: tie the standard to config templates and a recurring scan report.
2. Forgetting the management plane in cloud. Fix: define how admins reach consoles and APIs, and what “secure” means in your access pattern (VPN/ZTNA, SSO, MFA, device posture).
3. Allowing “temporary” Telnet during outages. Fix: create an emergency access procedure that still uses secure paths (break-glass through PAM/jump hosts).
4. Exception sprawl. Fix: require compensating controls and a retirement date; review exceptions on a fixed cadence.
5. No ownership. Fix: assign a control owner in Network/Infrastructure and a GRC owner for evidence and testing.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this safeguard, so treat it as a widely accepted security expectation rather than a standalone enforcement trigger. ¹

Risk implications are straightforward:

• Cleartext management increases the chance of credential capture, session hijack, unauthorized configuration changes, and lateral movement.
• Weak management protocols undermine incident containment because attackers target the management plane to persist and disable controls.

A practical 30/60/90-day execution plan

First 30 days (stabilize scope and standards)

• Publish the approved protocol baseline (allowed/banned) and exception workflow.
• Identify in-scope management-plane assets and networks.
• Choose enforcement points: device configs, jump hosts/PAM, firewall rules, and scanning tool coverage.
• Produce a first “current state” report: where insecure management is present.

Days 31–60 (enforce and reduce exposure)

• Disable banned protocols on high-risk/high-value device classes first (edge, core, identity, security tooling).
• Implement management-plane segmentation and restrict sources to admin networks and jump hosts.
• Start recurring scans and a standard remediation ticket workflow.
• Create the exception register and move unavoidable legacy devices into it with compensating controls.

Days 61–90 (operationalize and make it audit-ready)

• Expand enforcement to remaining device classes (including “odd stuff”).
• Add SIEM detections for prohibited protocol use and track to closure.
• Run a tabletop: “device replacement needed due to insecure management protocol support.”
• Package evidence in a repeatable format (policy, scan results, exceptions, remediation metrics) and store it in your GRC system (Daydream or equivalent). ¹

Frequently Asked Questions

Does Safeguard 12.6 require specific protocols like SSH or SNMPv3?

CIS v8 12.6 is framed as an implementation expectation to use secure network management and communication protocols, so you should define an approved set for your environment and ban insecure alternatives. Your approved list becomes the audit anchor. ¹

What counts as “network management” traffic for evidence purposes?

Include interactive admin sessions, web admin consoles, API administration, device configuration transfers, and management telemetry where misconfiguration exposes credentials or control. If it can change system state, treat it as management-plane. ¹

How do we handle legacy devices that only support insecure protocols?

Put them into a formal exception with compensating controls such as isolation to a restricted subnet, jump-host-only access, and heightened monitoring. Track a remediation plan to upgrade or replace. ¹

Is a written policy enough to pass an assessment?

No. Assessors typically expect proof of implementation and operation such as configs, scan results, and remediation records. Build recurring evidence capture into operations. ¹

How do third parties fit into this requirement?

If a third party manages your systems, you still need protocol requirements in contracts and technical controls that constrain how management access occurs (for example, via your jump host/ZTNA). Capture third-party access patterns in scope and evidence. ¹

What’s the fastest “proof” we can generate for auditors?

A tight protocol standard plus a current scan report showing absence of banned management services on in-scope networks, paired with tickets for any findings and an exception register for known gaps. ¹

Footnotes

1. CIS Controls v8; CIS Controls Navigator v8