Auditing Legacy Configs When You Inherit a Network
Taking over a network from a previous team, departed employee, or expired MSP contract is one of the most common ways engineers end up staring at years of undocumented configuration decisions. Here's a practical starting point.
Start With Discovery, Not Assumptions
Documentation handed over during a transition is almost always incomplete or out of date — that's normal, not a red flag on its own. Before changing anything, build your own current-state picture:
- Pull a fresh backup of every reachable device's running-config, not just what's in the existing documentation repository.
- Diff running-config against startup-config on each device — unsaved changes are extremely common and hint at recent, possibly undocumented, work.
- Build (or regenerate) a topology map from CDP/LLDP neighbor data rather than trusting an old Visio diagram.
Credential Audit: The Uncomfortable Part
Almost every inherited network has at least one of these waiting to be found:
- Shared local accounts with a password nobody currently on the team actually knows — usually stored only as a Type 7 hash in the config
- Enable passwords (not secrets) left over from before Type 8/9 support was available on that hardware
- SNMP community strings still at vendor defaults
- A "temporary" contractor account from a project that ended a year ago
For any device still showing password 7 ... or enable password 7 ..., you can recover the plaintext with a Type 7 decoder to confirm what's actually configured — then treat it as compromised by default and rotate it as part of the migration, following the process in Migrating from Type 7 to Type 9. Don't just silently re-encode the same value you found.
Prioritizing Remediation
You won't fix everything in week one, and trying to will likely cause an outage. A reasonable order of operations:
- Internet-facing and perimeter devices first — anything reachable without already being inside the network carries the most external risk.
- Shared/unknown credentials next — these are the ones most likely to have leaked or been reused elsewhere.
- Internal core and distribution devices — lower external exposure, but still worth clearing on a defined timeline rather than indefinitely.
- Access-layer and edge switches last — typically the lowest individual risk, but don't let "last" become "never."
Document As You Go
The single highest-leverage habit during this process is writing down what you find and why you made each change, in something more durable than tribal knowledge. Future-you (or whoever inherits the network after you) will be doing this exact exercise again someday. At minimum, track:
- What credential type was found on each device, and the date it was remediated
- Who has access to the new credentials, and where they're stored
- Any device that couldn't be remediated yet, and why (end-of-life hardware, maintenance window pending, etc.)