Auditing Legacy Network 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 is 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.)
Quick Triage From Your Workstation
Once you have a folder of fresh backups, a few searches show where the biggest problems are. These run in a normal terminal on your own machine against the downloaded files, not on the Cisco device:
The first finds weak or reversible credentials, the second lists SNMP community strings, the third finds lines that still allow Telnet, and the last lists configurations without password encryption. Sort the results by device role so that perimeter equipment comes first. Treat the output as a list of leads: a match tells you where to look, and you still need to understand why the line exists before you change it.
Handle the Backups Themselves Carefully
A folder of configurations is a folder of secrets. Keep it on an access-controlled system, limit who can read it, and avoid copying files into chat, tickets or shared drives. If you must share an excerpt, redact the credentials first. This also applies to anything you recover with a decoder: write it down only where it will be rotated, and never reuse it.
Keep a copy of each configuration before you change it. For the commands and the difference between merging and replacing a configuration, see backup and restore.
When You Cannot Fix a Device Yet
Some devices cannot be remediated straight away: the software is too old to support a stronger password type, a vendor contract blocks changes, or nobody dares to touch a production link. Do not leave them as they are without a plan. Common compensating steps are:
- Restrict management access to a small list of addresses with an access list on the VTY lines.
- Move management traffic to a dedicated network and stop it from being reachable from user segments.
- Replace Telnet with SSH where the software allows; see how to configure SSH.
- Record the device, the risk, the owner and a target date, so it stays on the list.
Where many devices share the same weaknesses, central login control through AAA with TACACS+ removes most of the per-device password work.
Working With Change Control
An audit finds many things at once, and fixing them one by one without coordination causes outages. Group the changes into batches by site or device role, schedule each batch in a maintenance window, and tell the people who depend on those devices, including monitoring, backup and automation owners. Test every batch on one device first, confirm that access still works through a second session, and keep the previous configuration so you can step back. Small, well-documented changes are slower to start but far safer than a single large sweep.
Summary
When you inherit a network, discover first, then audit credentials, then fix in order of exposure. Search the backups for weak password types, protect the files you collect, plan compensating controls for devices you cannot change yet, and write down everything you find and change. Use the password checklist to repeat the review on a schedule.