SNMP Security Guide: SNMPv3, Communities and Exposure

SNMP runs on almost every router, switch, firewall, printer and UPS in the estate, and in most of them it still authenticates with a shared community string sent in clear text. That string often unlocks the full configuration MIB, and a read-write string can change routing, ACLs and interface state. SNMP has also been the entry point for exploited remote code execution flaws in network operating systems, most recently CVE-2025-20352 in Cisco IOS and IOS XE. This guide covers how SNMPv1, v2c and v3 differ, how to configure SNMPv3 with modern algorithms, how to restrict views and sources, how to find exposure and how to migrate without breaking monitoring. It is written for network engineers, monitoring owners and security architects who run or audit network management.

Key takeaways

• Community strings are passwords in clear text. SNMPv1 and v2c send them unencrypted in every packet, so anyone who can sniff the management path or read a configuration backup can reuse them.
• SNMPv3 at authPriv is the only acceptable baseline. Use HMAC-SHA-2 authentication (RFC 7860) and AES privacy (RFC 3826); retire MD5, SHA-1 only profiles and DES where the platform allows.
• Restrict what and from where, not only who. Bind every community or user to a source ACL and a read view that excludes sensitive and vulnerable MIBs, and filter UDP 161 and 162 at the edge.
• Read-only is not harmless. CVE-2017-6736 and CVE-2025-20352 are in the CISA KEV catalog and both needed only a read-only community string or SNMPv3 credentials to reach the vulnerable code.
• SNMP credentials are non-human identities. Monitoring platforms hold them for thousands of devices, so they need an owner, a vault, rotation and alerting like any other machine credential.

How SNMP works and where the risk sits

SNMP is a manager and agent protocol. The manager (the monitoring platform) polls agents on devices with Get, GetNext, GetBulk (v2c and v3) and Set requests, normally to UDP 161, and agents send unsolicited notifications (traps, or acknowledged informs) to the manager, normally on UDP 162. Data is organised in the Management Information Base (MIB), a tree of object identifiers (OIDs) under 1.3.6.1.

• Read access is reconnaissance: the system, interfaces, ARP, routing and entity MIBs describe the device, its neighbours, its software version and the network around it. ATT&CK tracks this as T1602.001 SNMP (MIB Dump), a sub-technique of Data from Configuration Repository (T1602).
• Write access is control: a Set request can shut interfaces, change configuration objects and, on many platforms, trigger a configuration copy to or from a TFTP server.
• The agent is attack surface: SNMP parsing code runs with high privilege on the device. Cisco's 2017 advisory covered nine buffer overflows (CVE-2017-6736 to CVE-2017-6744) across all SNMP versions, most of them exploited in the wild.
• Open agents are amplifiers: a small spoofed GetBulk request can return a much larger response, so internet-reachable v2c agents are abused for T1498.002 Reflection Amplification.

SNMP versions compared

RFC 3414 defines the User-based Security Model (USM). Each message carries the authoritative engine's snmpEngineBoots and snmpEngineTime, and the receiver rejects messages outside a 150 second window, which limits replay and delay attacks. Keys are localised: the user's password is turned into a key Ku, then hashed with the authoritative engine's snmpEngineID, so the same password produces a different key on every device. A key stolen from one device does not work on another, but the password itself still does, which is why a shared SNMPv3 password across the estate is still a single point of failure.

Configuring SNMPv3 properly

Algorithms

RFC 7860 makes the SHA-256 variant mandatory to implement and SHA-512 recommended, with keys of 32 and 64 octets instead of the 16 and 20 octets used by the MD5 and SHA-1 protocols. Support varies by platform and software train, so inventory what each device family supports before writing the standard, and remember that AES-192 and AES-256 for USM are vendor extensions rather than an IETF standard: test interoperability with the monitoring platform.

Users, groups and views

The View-based Access Control Model (VACM, RFC 3415) maps a user to a group, and the group plus security level to read, write and notify views. Design it so that the default is nothing.

• Separate users by purpose: one read-only polling user per monitoring platform, one notification user for traps and informs, and a write user only where automation genuinely needs Set (most modern automation uses SSH, NETCONF or APIs instead).
• Require authPriv in the group: on Cisco IOS this is snmp-server group <name> v3 priv read <view> access <acl>; on Net-SNMP the rouser <user> priv -V <view> directive refuses lower levels.
• Build an allow-list view: include only the subtrees monitoring uses (system, interfaces, IF-MIB, ENTITY-MIB, HOST-RESOURCES-MIB, vendor health MIBs) and exclude the rest. RFC 3415 resolves overlaps by the most specific subtree, so an exclude under a broad include works.
• Exclude vulnerable MIBs when an advisory says so: Cisco's 2017 mitigation was an snmp-server view excluding ten MIBs, including CISCO-AUTH-FRAMEWORK-MIB and CISCO-MAC-AUTH-BYPASS-MIB; for CVE-2025-20352 the mitigation is again a view that excludes the affected OIDs. Both advisories describe these as temporary until a fixed release is installed.
• Remove factory defaults: delete the default public and private communities and any vendor-created v3 users, and check that no RFC 3415 "minimum-secure" style profile leaves the whole tree readable at noAuthNoPriv.
• Use strong, unique passphrases: Net-SNMP's createUser enforces only an 8 character minimum. Use long random secrets generated and stored by a vault, unique per environment or device group.

Restrict sources and planes

• Community and group ACLs: bind every community string and v3 group to a standard ACL listing only the monitoring collectors. Cisco's IOS hardening guide shows read-only access limited to a management subnet and read-write limited to a single host.
• Infrastructure ACLs: permit UDP 161 only from collectors to device management addresses and deny it everywhere else, including from user VLANs.
• Management plane binding: listen only on the management interface or out-of-band network (Cisco Management Plane Protection, agentaddress in Net-SNMP, which otherwise listens on UDP 161 on all IPv4 interfaces).
• Edge filtering: block UDP 161, 162 and the TLSTM ports (10161, 10162) inbound at the internet edge and in cloud security groups. There is almost never a reason for an agent to answer the internet.

See the Network Segmentation Guide for out-of-band management design and the CIS Control 12 Network Infrastructure Management Guide for the wider device baseline.

Finding and reducing SNMP exposure

1. Inventory agents: scan internal ranges for UDP 161 responders with an authorised scanner, then compare against the CMDB and monitoring platform. Printers, UPS units, storage controllers, BMCs (iDRAC, iLO) and building systems are commonly missed.
2. Record the version and credential type per device: v1, v2c, v3 level and algorithm. Flag any device answering to public, private or a vendor default.
3. Check external exposure: scan your internet-facing ranges and cloud public IPs from outside, and subscribe to free exposure notification services offered by national CERTs and research organisations.
4. Grep configuration backups: search for snmp-server community, rwcommunity and read-write strings. Every hit is a credential that must be rotated once the backup store is in scope.
5. Prioritise: internet-reachable first, then read-write anywhere, then v1 or v2c on core and perimeter devices, then everything else.

Migrating to SNMPv3 without breaking monitoring

1. Confirm platform support: list which device models and software versions support SHA-2 and AES, and whether the monitoring and NMS tools, NetFlow collectors and capacity tools that poll SNMP can use them.
2. Define the standard: authPriv, approved algorithms, user naming, view names, ACL names and trap destinations, written as a configuration template.
3. Add v3 alongside v2c on a pilot ring: a handful of devices per family, with v2c restricted to the collectors only. Compare polled values and trap delivery for one to two weeks.
4. Switch the monitoring platform to v3 per device group: watch for gaps in graphs and failed polls (usmStatsWrongDigests, usmStatsUnknownUserNames and usmStatsNotInTimeWindows counters on the agent help diagnose).
5. Remove community strings: delete snmp-server community lines and v1/v2c trap hosts once v3 is stable. Keep the removal in a change that can be reverted from the configuration backup if monitoring breaks.
6. Rotate and vault: load v3 secrets into the vault the monitoring platform reads from, and rotate any community string that ever appeared in a backup, ticket or script.
7. Enforce: add configuration compliance rules that fail a device with any community string, any noAuth or authNoPriv group, MD5 or DES.

Rollback is simple while both versions run: point the collector back to v2c. That is also the risk: set a date to remove v2c, because "temporary" dual configuration tends to become permanent.

Decision guidance

Where identity fits

An SNMP community string or v3 user is a machine credential shared between a monitoring service and every device it polls. Monitoring platforms, NMS tools, network automation scripts and configuration backups all hold copies, usually without a named owner, an expiry or a rotation process. Treat them like other non-human identities: an inventory entry with an owner, storage in a secrets manager, rotation after staff changes and after any exposure, and alerting when a credential is used from an unexpected source. See the Secrets Management Guide and the AAA Security Guide for the interactive administrator side of device access.

Detection and measurement

• Authentication failure notifications: enable authentication failure traps (in Net-SNMP authtrapenable 1, which is disabled by default; on Cisco snmp-server enable traps snmp authentication) and send them to the SIEM. Bursts indicate guessing (T1110.001 Password Guessing) or a misconfigured collector.
• Unexpected sources: flow or firewall logs showing UDP 161 to devices from anything other than the collectors, and any UDP 161 crossing the internet edge.
• Set requests and configuration copies: alert on SNMP Set from any host, and on TFTP or FTP transfers of device configurations initiated outside change windows.
• Configuration drift: new community strings, new v3 users, changed SNMP ACLs or trap hosts detected by configuration compliance or backup diffing.
• Agent counters: usmStatsWrongDigests and usmStatsUnknownUserNames rising on a device are worth investigating.

Metrics:

• Percentage of SNMP-enabled devices on v3 authPriv only (target 100% excluding documented exceptions).
• Number of devices with read-write access enabled by any version.
• Number of internet-reachable SNMP agents (target zero).
• Median age of SNMP credentials and percentage rotated in the last 12 months.
• Time to apply an SNMP view mitigation or fixed release after a KEV listing.

See the Network Monitoring and Packet Capture Guide for flow collection.

Common failure patterns

• Default or guessable communities left on: public and private, or the company name, on printers, UPS units and lab equipment that never entered the hardening process.
• Credentials sitting in configuration backups: backups copied over TFTP, kept on file shares or emailed to vendors expose every community and weakly encrypted local password. In the Salt Typhoon telecom intrusions, Cisco Talos reported that exfiltrated device configurations held SNMP read-write communities, that the actors captured SNMP, TACACS and RADIUS traffic to harvest more secrets, and that they altered SNMP communities and ACLs to keep access.
• Read-only treated as safe: CVE-2025-20352 allowed a device reload with only a read-only community or v3 credentials, and code execution as root on IOS XE when the attacker also had privilege 15 credentials. Cisco reported exploitation after local administrator credentials were compromised.
• v3 configured but v2c never removed: the strong path exists, the weak one still answers.
• authNoPriv or MD5 and DES everywhere: SNMPv3 in name only, chosen years ago for compatibility and never revisited.
• Agent listening on every interface: including user-facing VLANs, cloud public addresses or the internet edge, making the device both a reconnaissance source and an amplifier.

Framework mapping

Practitioner checklist

• Inventory every SNMP agent, its version, security level, algorithms and whether write access is enabled.
• Close UDP 161, 162, 10161 and 10162 from the internet and from user networks; allow only collectors.
• Delete public, private and all read-write communities; replace Set-based automation with SSH, NETCONF or APIs.
• Standardise on SNMPv3 authPriv with SHA-2 authentication and AES privacy, with long vault-generated secrets.
• Apply an allow-list read view and per-group source ACLs on every device.
• Track SNMP advisories for each platform and apply view mitigations, then fixed releases, within KEV timelines.
• Protect configuration backups: encrypted storage, no TFTP over untrusted paths, and rotation of any secret found in a backup.
• Send SNMP authentication failure traps and configuration change events to the SIEM, and alert on Set requests.
• Assign an owner and rotation schedule to every SNMP credential, and rotate after staff or vendor changes.

Standards and references

• IETF: RFC 3414 User-based Security Model (USM) for SNMPv3
• IETF: RFC 3415 View-based Access Control Model (VACM) for SNMP
• IETF: RFC 7860 HMAC-SHA-2 Authentication Protocols in USM for SNMPv3
• IETF: RFC 3826 The AES Cipher Algorithm in the SNMP User-based Security Model
• IETF: RFC 6353 Transport Layer Security (TLS) Transport Model for SNMP
• Cisco: Security Advisory for SNMP Denial of Service and Remote Code Execution (CVE-2025-20352)
• Cisco: Guide to Harden Cisco IOS Devices
• CISA: Known Exploited Vulnerabilities Catalog

Related NHI Mgmt Group resources: Network Security Guide · Salt Typhoon Threat Actor Profile · NTP Security Guide · Top 10 Network Security Misconfigurations · Secrets Management Guide