Simple Network Management Protocol (SNMP) is a standard way for a management station to read status from, and sometimes change settings on, network devices such as switches, routers, printers and UPS units. Run SNMPv3 with authentication and encryption, limit who can poll, and disable write access unless you need it.
How does SNMP actually work?
Three roles matter. A manager is the tool that asks questions. An agent is the software on the device that answers. The data lives in a Management Information Base (MIB), a tree of numbered objects such as interface counters, uptime or the device description. Each object has an object identifier, a dotted number like 1.3.6.1.2.1.1.5 for the system name.
The operations are small. The protocol operations document, RFC 3416, defines Get, GetNext, GetBulk and Set for requests and responses, plus traps and informs for notifications that a device sends on its own when something happens, such as a link going down. An inform is a trap that expects an acknowledgement.
By convention, agents listen on UDP port 161 and managers receive notifications on UDP port 162. Because UDP carries no connection state, SNMP traffic is easy to spoof unless the protocol itself adds protection.
Why do the versions matter so much?
SNMPv1 and SNMPv2c secure access with a community string. That string is a shared password sent in every packet without encryption. Anyone who can capture traffic on the path can read it, and many devices ship with well-known defaults such as public for read and private for write.
SNMPv3 changed the security model. The architecture document, RFC 3411, describes a modular design where security is a pluggable subsystem. The User-based Security Model in RFC 3414 adds per-user authentication, which proves who sent a message and that it was not altered, and optional privacy, which encrypts the payload. It also includes protection against message replay through timeliness checks.
SNMPv3 offers three levels: no authentication and no privacy, authentication only, and authentication plus privacy. Only the last one hides the data. Which algorithms your devices support depends on the firmware, so check the vendor documentation rather than assuming current ciphers.
What goes wrong in practice?
A constructed example. A mid-size company monitors 400 devices with one polling server. Two old switches still answer SNMPv2c with the default read community, and one printer has a write community left at its default. Nobody remembers enabling it.
The read community alone leaks the device inventory, interface descriptions, routing tables and ARP caches, which is a map of the internal network. The write community on the printer is worse, because Set operations can change configuration. Neither device appears in an asset list, so nobody reviews them.
The fix is not exotic. It is inventory, version control and access control, applied to a protocol most teams treat as background noise.
How to check or apply this
- Inventory every device that answers on UDP 161. A scan from inside each network segment is more honest than the asset spreadsheet.
- Prefer SNMPv3 with authentication and privacy for every device that supports it. Create one user per monitoring system, not one shared account.
- Where v2c cannot be removed, replace default community strings with long random values, make them read-only, and treat them as secrets.
- Restrict by source. Allow only the polling servers to reach UDP 161, using device access lists and network firewalls. Also block 161 and 162 from the internet edge.
- Disable Set access and any SNMP service that no tool uses. Most monitoring needs reads only.
- Poll only the objects you need. Smaller MIB views reduce what a stolen credential reveals.
- Log authentication failures from agents and alert on spikes, which usually mean scanning.
- Rotate credentials when staff or tools change, and record the owner of each SNMP user.
Is SNMP still worth using?
Yes, for a lot of equipment it is the only common interface for health and capacity data, and it is cheap to poll. The goal is not to remove it but to stop treating it as harmless. Streaming telemetry and vendor APIs are alternatives on newer gear, but they have their own credentials to manage.
Quick check
Is SNMPv2c encrypted?
No. v2c sends the community string and the data in clear text. Use SNMPv3 with privacy enabled if you need confidentiality, or confine v2c to an isolated management network.
Does a read-only community string pose a risk?
Yes. It can expose device details, interface and routing information and network topology, which helps an attacker plan. Treat it as a secret and limit which hosts may use it.
Sources
- RFC 3411, An Architecture for Describing SNMP Management Frameworks
- RFC 3414, User-based Security Model for SNMPv3
- RFC 3416, Protocol Operations for SNMP
Last reviewed: 18 October 2026.
