SNMP Security Hardening: From Default Community Strings to SNMPv3

2 million Cisco devices with SNMP exposed to the internet. Two critical CVEs published in the last 6 months. One of them actively exploited as a zero-day.

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

Two CVEs changed the SNMP threat landscape:

CVE-2026-28775 (CVSS 10.0) — Default SNMP community strings (public, private) on Cisco IOS/IOS-XE allow unauthenticated remote attackers to read and write device configurations. With write access, an attacker can modify running config, upload malicious firmware, or execute arbitrary commands. Over 2 million devices still have SNMP exposed with default strings.

CVE-2025-20352 (CVSS 8.8) — 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. This was a zero-day actively exploited in Operation Zero Disco, where attackers used compromised Cisco devices to deploy rootkits on connected systems. 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 — CVE-2026-28775 territory
• 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, check downstream Linux hosts too. Operation Zero Disco used compromised network devices as a pivot point to deploy rootkits on connected systems.

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 17.15.4a+ (for CVE-2025-20352)
• [ ] 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.