10 network device hardening checks most audits skip

Password complexity, banner text, NTP sync — every audit checks these, and they should. But a lot of real exposure hides in the checks that don't make the standard list. Here are ten that consistently get missed, and why each one is worth the five minutes it takes to fix.

1. IP source routing and directed broadcast

ip source-route and ip directed-broadcast are legacy features that let a packet dictate its own path through the network, or let a single packet fan out to every host on a broadcast segment. Neither has a legitimate modern use case, and both are classic amplification/spoofing primitives. They're off by default on current IOS releases — but "default" configs inherited from a device imaged years ago, or migrated from an older platform, often still have them explicitly enabled.

2. CDP/LLDP running on external-facing interfaces

Cisco Discovery Protocol and its standards-based cousin LLDP broadcast the device's model, software version, and hostname to anything on the same segment — genuinely useful on internal trunk links, and genuinely a reconnaissance gift on any interface facing a partner network, a colo cross-connect, or the internet. It's rarely disabled per-interface because it's rarely reviewed per-interface.

3. SNMP community strings without an ACL

Everyone checks for public/private as the community string. Fewer check whether a properly renamed, non-default community string is still reachable from anywhere on the network. A strong community string with no source restriction is still fully exposed to anyone who can reach the device on UDP 161 — the string being hard to guess doesn't help if it can be sniffed or brute-forced at leisure.

4. Console and AUX ports without a session timeout

VTY (remote) lines almost always get an exec-timeout review. Console and AUX ports — physical access points — get skipped far more often, on the assumption that physical access is already a trust boundary. It isn't always: shared colo racks, branch offices with less physical security, and third-party maintenance access all make an unattended, un-timed-out console session a real risk.

5. NTP without authentication

Time sync itself gets checked constantly — "is NTP configured" is table stakes. Whether that NTP session is authenticated is checked far less. An attacker who can spoof your time source can push a device's clock backward or forward enough to break certificate validation, desynchronize log correlation across devices, or undermine time-based access controls — all without touching the device's actual config.

6. Local logging with no remote syslog destination

Logging enabled, buffer size configured, severity level set — all standard checks. Whether those logs actually leave the device is checked less. A local buffer wraps under load (or a targeted flood), and once it wraps, that history is gone. If the only copy of "what happened right before this incident" lived on the device that got compromised, you likely don't have it anymore.

7. Legacy services left on by inheritance

Smart Install client, the TCP/UDP "small servers," BOOTP server, PAD, Finger — a long tail of protocols that shipped enabled on older IOS defaults and get carried forward every time a config is copied to a new device rather than rebuilt from a current hardening baseline. Smart Install specifically has a well-documented history of remote code execution vulnerabilities (this is the same feature behind CVE-2018-0171). None of these have a reason to be on in a modern network, and most administrators don't know they're on until something checks for them explicitly.

8. Missing or weak Control Plane Policing (CoPP)

CoPP protects the device's own management and control plane from being overwhelmed by traffic arriving on the data plane — without it, a flood of traffic (malicious or just a misbehaving host) can starve the CPU resources the device needs to keep routing protocols up and remain manageable. It's an advanced, easy-to-forget control precisely because its absence doesn't cause a problem until the day something needs it.

9. VTY lines without an access-class restriction

AAA and strong authentication on VTY lines gets checked. Whether the VTY lines are additionally restricted, via access-class, to only accept connections from a defined management subnet gets checked less. Authentication answers "can you log in." An access-class ACL answers "can you even attempt to" — a second layer that matters a great deal when the first one has a bad day (a leaked credential, a brute-force attempt, a bug in the auth flow itself).

10. SNMPv1/v2c left enabled alongside SNMPv3

Migrating to SNMPv3 is a common hardening project, and audits typically confirm "SNMPv3 is configured" and stop there. Whether the older, unauthenticated v1/v2c community-string access got explicitly turned off afterward is a separate question, and the answer is often no — the new, secure configuration was added, but the old, insecure one was never removed. An attacker doesn't care which version you intended to use; they'll use whichever one still answers.