CIS Benchmark for Cisco Switches: Level 1 and Level 2 Hardening Guide

If you manage Cisco IOS XE switches, applying the CIS Benchmark is one of the most practical ways to strengthen security, reduce attack surface, and align device configurations with widely accepted hardening standards. The CIS Benchmark for Cisco IOS XE 17.x provides actionable recommendations across the management plane, control plane, and data plane to help organizations secure switch infrastructure against unauthorized access, weak services, protocol abuse, and logging gaps.

This article summarizes the CIS Cisco IOS XE 17.x Benchmark v2.2.1 recommendations for Cisco switches at Level 1 and Level 2, with a brief explanation of each command and its corresponding recommendation number. This article is written as a reference guide for engineers, security teams, auditors, and compliance stakeholders involved in Cisco switch hardening.

What Is the CIS Benchmark for Cisco Switches?

The CIS Benchmark for Cisco IOS XE 17.x is a prescriptive security configuration standard published by the Center for Internet Security. It outlines best practices for hardening Cisco network devices through settings related to AAA, SSH, SNMP, logging, NTP, access control, routing security, and unused service reduction.

Level 1 vs Level 2

• Level 1 recommendations are intended for broad use in production environments and focus on essential security hardening with lower operational risk.
• Level 2 recommendations are more security-stringent and may require additional planning, testing, or architectural considerations before deployment.

CIS Benchmark Recommendations for Cisco Switches

1 Management Plane

1.1 Local Authentication, Authorization, and Accounting (AAA)

1.1.1 – Enables the AAA framework on the switch. This is the foundation for centralized authentication, authorization, and accounting.

aaa new-model

Defines the RADIUS server: Sets the external RADIUS server details, including IP address, authentication/accounting ports, shared secret, timeout, and retransmit values, to support centralized AAA services.

radius server RADIUS01
address ipv4 [RADIUS SERVER IP ADDRESS] auth-port 1812 acct-port 1813
key 0 [RADIUS SHARED SECRET]
timeout 5
retransmit 3

Creates the AAA server group: Groups the configured RADIUS server into an AAA server group so it can be referenced by authentication and accounting policies as supporting configuration for centralized access control.

aaa group server radius RADIUS-GRP
server name RADIUS01

1.1.2 – Defines how users are authenticated when logging in. It helps enforce consistent login control, often using RADIUS/TACACS+ with local fallback.

aaa authentication login default group RADIUS-GRP local

1.1.3 – Controls authentication for entering privileged EXEC mode with the enable command. This adds protection around administrative privilege escalation.

aaa authentication enable default group RADIUS-GRP enable

1.1.4 – Applies AAA authentication to remote VTY sessions. It ensures SSH logins follow the defined authentication policy.

line vty 0 4
 login authentication default
line vty 5 15
 login authentication default

1.1.5 – Requires authentication for HTTP/HTTPS management access when web services are enabled. This protects browser-based administration.

ip http secure-server
ip http authentication default

1.1.6 – Logs all privilege level 15 command activity. This creates an audit trail for highly privileged administrative actions.

aaa accounting commands 15 default start-stop group RADIUS-GRP

1.1.7 – Records outbound connection activity from the device. Useful for monitoring remote sessions and suspicious access behavior.

aaa accounting connection default start-stop group RADIUS-GRP

1.1.8 – Tracks EXEC shell sessions, including session start and stop events. Helpful for accountability and forensic review.

aaa accounting exec default start-stop group RADIUS-GRP

1.1.9 – Logs network service requests. This supports visibility into network-related AAA events.

aaa accounting network default start-stop group RADIUS-GRP

1.1.10 – Records system-level events such as reloads. This improves auditability of device operations.

aaa accounting system default start-stop group RADIUS-GRP

1.2 Access Rules

1.2.1 – Assigns local users least privilege by default. This reduces risk by preventing direct administrative-level access unless elevation is required.

username opsuser privilege 1 algorithm-type scrypt secret [USER SECRET]

1.2.2 – Restricts remote management access to SSH only. This disables insecure plaintext protocols like Telnet.

line vty 0 4
 transport input ssh
line vty 5 15
 transport input ssh

1.2.3 – Disables EXEC access on the auxiliary port. This closes an often-unused entry point that could be abused.

line aux 0
 no exec

1.2.4 – Defines which IPs or networks are allowed to initiate remote management sessions. This limits administrative access to trusted sources.

ip access-list standard MGMT-ACL
 permit [MGMT HOST IP ADDRESS]
 deny any log

1.2.5 – Applies the VTY ACL to the VTY lines. Without this step, the ACL exists but does not protect remote access.

line vty 0 4
 access-class MGMT-ACL in
line vty 5 15
 access-class MGMT-ACL in

1.2.6 – Automatically closes idle auxiliary sessions. This helps prevent misuse of abandoned sessions.

line aux 0
 exec-timeout 5 0

1.2.7 – Disconnects inactive console sessions after a defined period. Important for protecting local access in shared or onsite environments.

line con 0
 exec-timeout 5 0
 login authentication default
 authorization exec default

1.2.8 – Terminates idle remote admin sessions. This reduces the risk of unattended SSH sessions being hijacked.

line vty 0 4
 exec-timeout 5 0
line vty 5 15
 exec-timeout 5 0

1.2.9 – Limits concurrent HTTP/HTTPS management sessions. This reduces denial-of-service and admin session abuse risk.

ip http max-connections 2

1.2.10 – Sets HTTP session timeout to 10 minutes or less. This protects web management sessions from being left open.

ip http timeout-policy idle 300 life 86400 requests 10000

1.3 Banner Rules

1.3.1 – Displays a legal notice after login when an EXEC session begins. Supports acceptable use and monitoring warnings.

banner exec ^
This device is monitored. Commands and configuration changes are logged.
^

1.3.2 – Shows a warning message before login. Often used for legal consent and unauthorized access notices.

banner login ^
Authorized users only. Disconnect immediately if you are not an authorized user.
^

1.3.3 – Presents a message of the day to all connecting users. Useful for legal notice or operational alerts.

banner motd ^
WARNING: This system is for authorized use only.
All activity may be monitored and recorded.
Unauthorized access is prohibited.
^

1.3.4 – Sets a web authentication banner for HTTP access. Useful when browser-based access is enabled.

ip admission auth-proxy-banner http ^
WARNING: This system is for authorized use only.
All activity may be monitored and recorded.
Unauthorized access is prohibited.
^

1.4 Password Rules

1.4.1 – Configures a hashed password for privileged access. This is more secure than enable password.

enable secret [ENABLE SECRET]

1.4.2 – Obfuscates passwords in the configuration. It does not provide strong cryptographic security, but it helps prevent casual disclosure.

service password-encryption

1.4.3 – Uses encrypted secrets for local user accounts. CIS prefers stronger password types such as type 8 or 9 where supported.

username breakglass privilege 15 algorithm-type scrypt secret [USER SECRET>

1.5 SNMP Rules

1.5.1 – Disables SNMP entirely if it is not required. This eliminates a management protocol exposure.

no snmp-server

1.5.2 – Prevents use of a default well-known read-write community string. Attackers often try these defaults first.

no snmp-server community private

1.5.3 – Prevents use of a default well-known read-only community string. This reduces trivial SNMP exposure.

no snmp-server community public

1.5.4 – Avoids read-write SNMP access. Read-write communities can allow remote configuration changes.

no snmp-server community [RW COMMUNITY]

1.5.5 – Restricts which management stations can use the SNMP community. This limits SNMP access to trusted systems.

snmp-server community [COMMUNITY] ro SNMP-ACL

1.5.6 – Builds the access list referenced by SNMP community settings. It is a foundational control for SNMP restriction.

ip access-list standard SNMP-ACL
 permit [SNMP MANAGER IP ADDRESS]
 deny any log

1.5.7 – Defines authorized destinations for SNMP traps. This ensures notifications go only to approved monitoring systems.

snmp-server host [SNMP MANAGER IP ADDRESS] version 3 priv SNMPV3USER

1.5.8 – Enables specific SNMP trap types. This improves monitoring while avoiding overly broad trap behavior.

snmp-server enable traps snmp authentication linkdown linkup coldstart warmstart
snmp-server enable traps config
snmp-server enable traps syslog
snmp-server enable traps envmon

1.5.9 – Requires encryption for SNMPv3 group traffic. This is a major improvement over SNMPv1/v2c.

snmp-server group SNMPV3-GRP v3 priv

1.5.10 – Requires at least AES 128 encryption for SNMPv3 users. This helps secure monitoring traffic in transit.

snmp-server user SNMPV3USER SNMPV3-GRP v3 auth sha [AUTH PASS] priv aes 128 [PRIV PASS] access SNMP-ACL

2. Control Plane

2.1 Global Service Rules

2.1.2 – Disables Cisco Discovery Protocol globally unless needed. CDP can expose device details useful to attackers.

no cdp run

2.1.3 – Prevents the device from acting as a BOOTP server unless necessary. This reduces unnecessary service exposure.

ip dhcp bootp ignore

2.1.4 – Disables DHCP server functionality on the switch if not required. Best practice is to use dedicated DHCP infrastructure.

no service dhcp

2.1.5 – Enables keepalives for inbound TCP sessions. Helps clean up dead connections.

service tcp-keepalives-in

2.1.6 – Enables keepalives for outbound TCP sessions. Reduces stale session buildup.

service tcp-keepalives-out

2.1.7 – Disables the legacy X.25 PAD service. This is an unnecessary and outdated protocol on modern networks.

no service pad

2.1.1 SSH Setup

2.1.1.2 – Forces SSH version 2. SSHv1 is deprecated and insecure.

ip ssh version 2

2.1.1.1.1 – Sets the device hostname. Required as part of SSH identity configuration.

hostname [HOSTNAME]

2.1.1.1.2 – Defines the domain name used with key generation. Required before generating RSA keys for SSH.

ip domain name [DOMAIN NAME].local

2.1.1.1.3 – Creates RSA keys of at least 2048 bits. Strong keys are essential for secure SSH.

crypto key generate rsa general-keys modulus 2048

2.1.1.1.4 – Limits how long the switch waits for SSH authentication completion. Helps reduce abuse of incomplete sessions.

ip ssh time-out 60

2.1.1.1.5 – Restricts the number of SSH login attempts per session. This limits brute-force attempts.

ip ssh authentication-retries 2

2.2 Logging Rules

2.2.1 – Enables configuration change logging. Useful for auditing who changed what on the device.

archive
 log config
  logging enable

2.2.2 – Stores logs in local memory. Useful for short-term troubleshooting and operational review.

logging buffered 64000 informational

2.2.3 – Limits console logging to critical messages. Helps avoid performance impact and console flooding.

logging console critical

2.2.4 – Sends logs to a remote syslog server. Critical for long-term retention and centralized monitoring.

logging host [SYSLOG SERVER IP ADDRESS]

2.2.5 – Sets remote log severity to informational. This balances visibility with noise control.

logging trap informational

2.2.6 – Adds detailed timestamps to debug logs. Important for incident timelines.

service timestamps debug datetime msec localtime show-timezone
service timestamps log datetime msec localtime show-timezone

2.2.7 – Pins syslog messages to a consistent source interface. Makes filtering and correlation easier on the log server.

logging source-interface Loopback0

2.2.8 – Logs authentication successes and failures. This improves visibility into access attempts.

login on-failure log
login on-success log

2.3 NTP Rules

2.3.2 – Configures one or more NTP servers. Time synchronization is critical for reliable logs and authentication systems.

ntp server [NTP SERVER IP ADDRESS]

2.3.1.1 – Enables NTP authentication. This helps prevent rogue time sources from influencing the device.

ntp authenticate

2.3.1.2 – Defines the cryptographic key used for NTP authentication.

ntp authentication-key 1 md5 [NTP KEY]

2.3.1.3 – Marks which configured NTP keys are trusted. This ensures the device accepts time only from approved peers.

ntp trusted-key 1

2.3.1.4 – (Level 2) Associates each configured NTP server with an authentication key so the switch only accepts time updates from trusted NTP sources. This improves the integrity of system time and logs.

ntp server [NTP SERVER IP ADDRESS] key 1

2.4 Loopback Rules

2.4.1 – Creates a loopback interface for stable device identity. Useful for management traffic and protocol consistency.

interface Loopback0
 ip address [LOOPBACK IP ADDRESS] [SUBNET MASK]

2.4.2 – Binds AAA traffic to a specific source interface, usually loopback. This improves server-side policy matching.

ip radius source-interface loopback0

2.4.3 – Sends NTP traffic from the loopback interface. Helps NTP servers identify the device consistently.

ntp source loopback0

2.4.4 – Sets the source interface for TFTP sessions. Useful in controlled environments where TFTP is still used.

ip tftp source-interface Loopback0

3. Data Plane

3.1 Routing Rules

3.1.1 – Disables IP source routing. This prevents packets from specifying their own route, which can be abused.

no ip source-route

3.1.2 – (Level 2) Disables Proxy ARP on Layer 3 interfaces so the switch does not answer ARP requests on behalf of other hosts. This helps preserve proper network segmentation and reduces the risk of unintended communication across subnets.

interface GigabitEthernet1/0/1
 no ip proxy-arp
interface Vlan100
 no ip proxy-arp

3.1.3 – Ensures unnecessary tunnel interfaces are not present. Tunnel interfaces can create hidden or unmanaged paths.

no interface tunnel

3.1.4 – Enables unicast Reverse Path Forwarding (uRPF). This helps block spoofed traffic on selected interfaces.

interface GigabitEthernet1/0/48
 ip verify unicast source reachable-via rx allow-default

3.3 Neighbor Authentication

EIGRP

3.3.1.6 – Associates a key chain with EIGRP. This helps verify trusted routing peers.

key chain EIGRP-KEYS
 key 1
  key-string [EIGRP SECRET]

3.3.1.7 – Enables MD5 authentication for EIGRP adjacencies.

router eigrp EIGRP-PROD
 address-family ipv4 autonomous-system 100
  af-interface GigabitEthernet1/0/1
   authentication mode md5

3.3.1.8 – Applies an EIGRP key chain at the interface level.

interface GigabitEthernet1/0/1
 ip authentication key-chain eigrp 100 EIGRP-KEYS

3.3.1.9 – ip authentication mode eigrp … md5
Requires MD5 authentication for EIGRP packets on the interface.

OSPF

3.3.2.1 – Enables OSPF MD5 authentication for the area.

router eigrp EIGRP-PROD
 address-family ipv4 autonomous-system 100

3.3.2.2 – Applies the MD5 key on the participating interface.

router eigrp EIGRP-PROD
 address-family ipv4 autonomous-system 100
  af-interface default

BGP

3.3.3.1 – Enables MD5 authentication for BGP sessions. This helps prevent unauthorized peers.

router bgp 65001
 neighbor [BGP NEIGHBOR IP ADDRESS] password [BGP SECRET]

Why the CIS Benchmark Matters for Cisco Switch Security

Applying the CIS Benchmark to Cisco switches helps organizations:

• Reduce exposed services and weak default settings
• Secure administrative access with AAA and SSH
• Improve accountability with logging and accounting
• Strengthen SNMP and NTP security
• Limit spoofing and insecure routing behavior
• Align network device hardening with compliance and audit expectations

For many teams, the biggest value is consistency. The benchmark provides a repeatable hardening baseline that can be rolled into switch templates, golden configs, and compliance checks.

Final Thoughts

The CIS Benchmark for Cisco Switches Level 1 and Level 2 offers a practical roadmap for hardening Cisco IOS XE devices. Level 1 recommendations establish a strong baseline across AAA, SSH, SNMP, logging, NTP, and service reduction, while Level 2 introduces stricter anti-spoofing and protocol authentication controls for more security-sensitive environments.

If you are implementing these recommendations, validate each setting against your operational requirements before deployment—especially for AAA, SNMP, routing authentication, and management access restrictions.