SNMP Security Hardening: From Default Community Strings to SNMPv3

SNMP on Cisco devices was exploited as a zero-day in 2025, and most networks still run it with plaintext community strings.

If you manage Cisco infrastructure, SNMP is probably the most dangerous protocol running on your devices right now. Not because SNMP is bad. Because the way most networks configure it is.

This guide gives you the exact commands to audit and harden SNMP on IOS and IOS-XE. No theory. Just what to type and why.

Why SNMP Is a Priority Target in 2026

One CVE and one old habit define the SNMP risk:

Default community strings (public, private) - not a CVE, a misconfiguration, and the more common problem. A read-write community reachable from an untrusted network lets an attacker change the running configuration. The NSA Network Infrastructure Security Guide (section 7.8) recommends removing read-write community strings altogether.

CVE-2025-20352 (CVSS 7.7) - Stack overflow in the SNMP subsystem of Cisco IOS/IOS-XE. Even a read-only community string is enough to crash the device. With admin credentials on IOS-XE, it escalates to remote code execution as root. Exploited as a zero-day: Trend Micro's Operation Zero Disco report describes Linux rootkits installed on the Cisco devices themselves (Catalyst 9400, 9300 and legacy 3750G). Listed in CISA KEV.

Step 1: Audit Your Current SNMP Configuration

Before you change anything, understand what you have. Run these commands on every device:

show snmp community
show snmp group
show snmp user
show snmp host

What to look for:

• public or private in the community list - default strings, the first thing any scanner tries
• Any community string without an ACL applied — open to any source IP
• SNMPv1 or v2c groups without corresponding v3 groups — no encryption
• SNMP hosts pointing to decommissioned NMS servers

If show snmp community returns public or private, stop reading and go fix it. Right now.

Step 2: Remove Default Community Strings

This is the single most impactful change you can make:

configure terminal
no snmp-server community public
no snmp-server community private
end
write memory

Step 3: Migrate to SNMPv3 with authPriv

SNMPv3 adds authentication and encryption. The authPriv security level means both are active — credentials are verified and traffic is encrypted.

configure terminal

! Create SNMPv3 group with privacy (encryption)
snmp-server group MONITOR-GRP v3 priv

! Create SNMPv3 user with SHA auth + AES-256 encryption
snmp-server user MONITOR-USER MONITOR-GRP v3 auth sha MyAuthPass2026! priv aes 256 MyPrivPass2026!

! Point SNMP traps/informs to your NMS
snmp-server host 10.0.0.50 version 3 priv MONITOR-USER

end
write memory

Key points:

• Use SHA for authentication (not MD5 — it is deprecated)
• Use AES-256 for privacy (not DES — it is broken)
• Passwords must be 8+ characters. Use 16+ for production
• Replace 10.0.0.50 with your actual NMS server IP

Step 4: Apply ACLs to Restrict SNMP Access

Even with SNMPv3, restrict which IPs can send SNMP queries. Defense in depth.

configure terminal

ip access-list standard SNMP-ACL
 remark Allow SNMP only from management subnet
 permit 10.0.0.0 0.0.0.255
 deny any log
exit

! Apply ACL to SNMPv3 group
snmp-server group MONITOR-GRP v3 priv access SNMP-ACL

! If you must keep v2c as fallback (not recommended):
! snmp-server community YOUR-STRONG-STRING RO SNMP-ACL

end
write memory

Replace 10.0.0.0/24 with your management subnet. The deny any log line helps you catch unauthorized SNMP probes in your syslog.

Step 5: Disable SNMPv1 and v2c

Once your NMS is working with SNMPv3, kill the old versions:

configure terminal
! Remove all v2c community strings
no snmp-server community YOUR-OLD-STRING
end
write memory

Removing all community strings disables SNMPv1 and v2c entirely. SNMPv3 continues to work because it uses user-based authentication, not community strings.

Step 6: Check for Active Exploitation

CVE-2025-20352 was exploited in the wild. If you were running a vulnerable version with SNMP exposed, check for compromise indicators:

show logging | include SNMP
show users
show privilege
show running-config | include snmp-server

Red flags:

• Unexpected SNMP activity in logs
• Unknown users or sessions
• Privilege escalation you did not configure
• SNMP community strings or hosts you did not add

If you find signs of exploitation, treat the device itself as compromised. In Operation Zero Disco the rootkit lived on the switch: it set a universal password and hooked into IOSd memory. Reimage, do not just patch, and review what that device could reach.

Hardening Checklist

Run through this before you close the maintenance window:

• [ ] Default community strings removed (public, private)
• [ ] SNMPv3 group created with priv security level
• [ ] SNMPv3 user created with SHA auth + AES-256
• [ ] ACL applied to SNMP group (management subnet only)
• [ ] All v2c community strings removed
• [ ] SNMP hosts point to current NMS servers only
• [ ] IOS XE upgraded to the fixed release for your train (for CVE-2025-20352; 17.15.4a on 17.15)
• [ ] Syslog checked for exploitation indicators
• [ ] Downstream hosts checked for compromise
• [ ] Config saved (write memory)

Misconfigurations That Audits Miss

After years of managing Cisco infrastructure, these are the SNMP gaps I keep finding:

• ACL-less community strings. A community string without an ACL is reachable from any IP. Most configs omit the ACL because "it's on the management VLAN." VLANs are not security boundaries.
• SNMPv3 without privacy. Configuring SNMPv3 with auth but no priv means credentials are verified but traffic is cleartext. An attacker on the wire sees everything.
• Stale SNMP hosts. snmp-server host entries pointing to decommissioned servers. The device sends traps to an IP that someone else now controls.
• SNMP enabled on non-management interfaces. If your device listens for SNMP on all interfaces, any interface facing an untrusted network is an attack surface. Use ACLs or control-plane policing.

What This Means for Your Monday Morning

Pick one device. Run show snmp community. If you see defaults, you know where to start.

The full migration (audit, SNMPv3 config, ACL, verification) takes about 15 minutes per device manually. With automation, you can template it and deploy to your entire fleet in one session.