Router Security Audit Checklist: 60 Checks to Harden Your Cisco IOS Device
This router security audit checklist covers every major configuration area that should be reviewed on a Cisco IOS or IOS-XE device. Each check maps to the CIS Benchmark, DISA STIG, or NSA Router Security Configuration Guide and includes the specific IOS command you need. Work through it section by section, or run your config through the free automated audit tool to get results instantly.
Table of Contents
- How to Use This Checklist
- Section 1: Authentication & Password Security (12 checks)
- Section 2: Management Plane Security (12 checks)
- Section 3: Unnecessary Services (10 checks)
- Section 4: Routing Protocol Security (8 checks)
- Section 5: Logging & Monitoring (10 checks)
- Section 6: Control Plane & Data Plane (8 checks)
- After the Checklist: What to Do with Your Results
- Frequently Asked Questions
How to Use This Checklist
Each check below has a severity rating (Critical, High, Medium, or Low) and the IOS command or configuration pattern to look for. To use it manually:
- Run
show running-configon your router and save the output. - Work through each section, searching the config for the relevant command or pattern.
- Mark items as Pass, Fail, or N/A, and note the remediation command for each failure.
- Prioritize Critical and High failures for your next maintenance window.
To run all 60 checks automatically in seconds, paste your configuration into the free router audit tool — it parses your config and evaluates every check instantly, with no data leaving your browser.
N/A vs. Fail: Some checks may not apply to your environment. For example, BGP authentication is only relevant if you run BGP. Mark these as N/A rather than Fail so your score reflects actual applicability. Document your N/A justifications for audit evidence.
Section 1: Authentication & Password Security
Authentication is the first line of defense. A misconfigured or weak authentication setup means all other hardening measures can be bypassed. This section covers how the router stores and enforces credentials.
Auth Authentication & Password Security 12 checks
| # | Check | Severity | What to Look For |
|---|---|---|---|
| 1.1 | Enable secret configured (not enable password)enable secret [hash] | Critical | Config must contain enable secret. enable password alone is a failure. |
| 1.2 | Enable secret uses strong algorithmenable algorithm-type scrypt secret | High | Type 5 (MD5) is acceptable minimum; scrypt (Type 9) preferred on IOS 15.3+. |
| 1.3 | Service password-encryption enabledservice password-encryption | High | Must be present in global config to obscure plaintext passwords. |
| 1.4 | Local usernames use secret not passwordusername [name] privilege [x] secret [hash] | High | Every username entry must use secret, not password. |
| 1.5 | Minimum password length enforcedsecurity passwords min-length 10 | Medium | Must be at least 10 (CIS) or 15 (DISA STIG) characters. |
| 1.6 | Authentication failure rate limiting configuredsecurity authentication failure rate 3 log | Medium | Must be present in global config. |
| 1.7 | AAA new-model enabledaaa new-model | High | Must appear in global config. Without this, AAA policies are ignored. |
| 1.8 | AAA authentication login configuredaaa authentication login default [method] | High | A default authentication list must be defined. |
| 1.9 | AAA authorization exec configuredaaa authorization exec default [method] | Medium | Required for privilege-level authorization to work correctly. |
| 1.10 | AAA accounting exec configuredaaa accounting exec default start-stop [method] | Medium | Required for logging all privileged sessions. |
| 1.11 | No privilege 15 accounts with blank passwordsusername [name] privilege 15 secret [hash] | Critical | Any privileged account must have a secret configured. |
| 1.12 | No default/test accounts presentshow running-config | section username | High | Review all usernames — remove any that aren’t explicitly authorized. |
Section 2: Management Plane Security
The management plane controls how administrators access the device. Every weakness here is a direct path to full device compromise.
Mgmt Management Plane Security 12 checks
| # | Check | Severity | What to Look For |
|---|---|---|---|
| 2.1 | SSH version 2 enabledip ssh version 2 | Critical | Must be explicitly set. SSH v1 is insufficient. |
| 2.2 | RSA key size 2048 bits or greatercrypto key generate rsa modulus 2048 | High | Check show crypto key mypubkey rsa — key must be ≥2048 bits. |
| 2.3 | All VTY lines restrict transport to SSH onlytransport input ssh | Critical | Every VTY line block must have transport input ssh. Any other value is a failure. |
| 2.4 | VTY lines require login authenticationlogin local or login authentication [list] | Critical | No VTY line can have no login. |
| 2.5 | Exec timeout on all VTY linesexec-timeout 10 0 | High | exec-timeout 0 0 or no timeout at all is a failure. |
| 2.6 | Exec timeout on console lineexec-timeout 5 0 | Medium | Console line must have a non-zero timeout. |
| 2.7 | Access-class ACL applied to VTY linesaccess-class [ACL] in | High | VTY lines must restrict source IPs via ACL. |
| 2.8 | HTTP server disabledno ip http server | High | ip http server must not appear in config (unless explicitly required). |
| 2.9 | HTTPS server disabled or properly securedno ip http secure-server | Medium | Disable unless actively used by a management platform. |
| 2.10 | SSH timeout configuredip ssh time-out 60 | Medium | Default is 120 seconds; set to 60 or lower. |
| 2.11 | SSH authentication retries limitedip ssh authentication-retries 3 | Medium | Limit to 3 retries to slow brute-force attempts. |
| 2.12 | Login banner configuredbanner login ^…^ | Medium | Must warn of unauthorized access. Must not reveal device details. |
Run All 60 Checks Automatically
Paste your config into the free tool and get every result in seconds — no login, nothing sent to any server.
Run Free Router Audit →Section 3: Unnecessary Services
IOS enables a number of services by default that have no place on a production router. Each one is an additional attack surface. Disable anything you don’t explicitly need.
Services Unnecessary Services 10 checks
| # | Check | Severity | What to Look For |
|---|---|---|---|
| 3.1 | IP source routing disabledno ip source-route | High | Must appear in global config. Default is enabled on older IOS. |
| 3.2 | TCP small servers disabledno service tcp-small-servers | Medium | Required on IOS 11.x and 12.x; off by default in 15.x+. Explicitly disable regardless. |
| 3.3 | UDP small servers disabledno service udp-small-servers | Medium | Same as above — explicitly disable. |
| 3.4 | IP finger service disabledno ip finger | Medium | Discloses usernames and active sessions to unauthenticated requesters. |
| 3.5 | BOOTP server disabledno ip bootp server | Low | Not needed on routers; can be exploited for reconnaissance. |
| 3.6 | Service config disabledno service config | Medium | Prevents the router from loading its config from a TFTP server — a legacy attack vector. |
| 3.7 | CDP disabled on external interfacesno cdp enable (per-interface) | Medium | Check all WAN/external-facing interfaces. |
| 3.8 | IP proxy-ARP disabled on external interfacesno ip proxy-arp | Medium | Must be explicitly disabled on untrusted interfaces. |
| 3.9 | IP directed broadcasts disabled on all interfacesno ip directed-broadcast | High | Must appear under every interface. Prevents Smurf amplification attacks. |
| 3.10 | LLDP disabled if not neededno lldp run | Low | Like CDP, LLDP discloses device information. Disable if not used for management. |
Section 4: Routing Protocol Security
Unauthenticated routing protocols allow an attacker with network access to inject false routes, redirecting traffic through a controlled hop. Every routing protocol you run should require authentication.
Routing Routing Protocol Security 8 checks
| # | Check | Severity | What to Look For |
|---|---|---|---|
| 4.1 | OSPF neighbor authentication configuredip ospf authentication message-digest | High | Every OSPF-enabled interface must have authentication. MD5 minimum; SHA preferred on IOS-XE. |
| 4.2 | EIGRP neighbor authentication configuredip authentication mode eigrp [asn] md5 | High | Key chains must be configured and applied to every EIGRP interface. |
| 4.3 | BGP neighbor authentication configuredneighbor [ip] password [key] | High | Every eBGP and critical iBGP peer must have a password configured. |
| 4.4 | BGP TTL security configured for eBGP peersneighbor [ip] ttl-security hops 1 | Medium | Prevents spoofed BGP packets from remote hosts from reaching the router. |
| 4.5 | Passive interface configured on non-peering interfacespassive-interface [interface] | Medium | Routing updates should not be sent out interfaces facing end users or the internet. |
| 4.6 | RIPv1 not in use (use RIPv2 or eliminate)version 2 under router rip |
High | RIPv1 has no authentication support. Replace with RIPv2 or a better protocol. |
| 4.7 | RIPv2 authentication configured if RIP is in useip rip authentication mode md5 | High | Key chains must be applied to all RIP-enabled interfaces. |
| 4.8 | Route filtering in place for external routing peersneighbor [ip] prefix-list [name] in | Medium | Inbound prefix filtering on BGP and redistributed routes prevents route injection attacks. |
Section 5: Logging & Monitoring
Without logging, you have no visibility into what’s happening on the device — and no forensic evidence after an incident. Logs must be sent off-device immediately so they can’t be tampered with if the router is compromised.
Logging Logging & Monitoring 10 checks
| # | Check | Severity | What to Look For |
|---|---|---|---|
| 5.1 | Remote syslog server configuredlogging host [ip] | High | At least one external syslog destination must be configured. |
| 5.2 | Logging level set to informational or higherlogging trap informational | Medium | Too low a level misses security-relevant events. |
| 5.3 | Local logging buffer configuredlogging buffered 32768 | Low | Minimum 32KB. Useful for quick on-device troubleshooting. |
| 5.4 | Timestamps enabled on log messagesservice timestamps log datetime msec | High | Without timestamps, log entries are useless for incident correlation. |
| 5.5 | Timestamps enabled on debug messagesservice timestamps debug datetime msec | Low | Useful during active troubleshooting and incident response. |
| 5.6 | NTP server configuredntp server [ip] | High | Accurate timestamps require NTP. Without it, logs from different devices can’t be correlated. |
| 5.7 | NTP authentication enabledntp authenticate | Medium | Prevents time-spoofing attacks that could corrupt your audit trail. |
| 5.8 | SNMP not using default community strings | Critical | snmp-server community public or private must not appear in config. |
| 5.9 | SNMPv3 used if SNMP is requiredsnmp-server group [name] v3 priv | High | SNMPv1 and v2c transmit community strings in cleartext. Use SNMPv3 with auth+priv. |
| 5.10 | SNMP access restricted via ACLsnmp-server community [string] [rw/ro] [acl] | Medium | SNMP access should be limited to specific management hosts. |
Section 6: Control Plane & Data Plane
The control plane handles routing protocol traffic and management traffic destined for the router itself. Without protection, attackers can flood the CPU with crafted packets, causing a denial-of-service. These checks verify that appropriate rate limiting and protection are in place.
Control Plane Control Plane & Data Plane 8 checks
| # | Check | Severity | What to Look For |
|---|---|---|---|
| 6.1 | Control Plane Policing (CoPP) configuredcontrol-plane / service-policy input [policy] | High | A CoPP policy must be applied under control-plane. Protects router CPU from flood attacks. |
| 6.2 | IP CEF enabledip cef | Medium | CEF should be enabled on all production IOS devices. Check show ip cef. |
| 6.3 | Unicast RPF (uRPF) configured on external interfacesip verify unicast source reachable-via rx | Medium | Strict uRPF on internet-facing interfaces blocks spoofed source IP packets. |
| 6.4 | IP unreachables rate-limited or disabled on external interfacesno ip unreachables | Medium | Uncontrolled ICMP unreachables can be used for scanning and information disclosure. |
| 6.5 | IP redirects disabled on external interfacesno ip redirects | Medium | ICMP redirects can be used to alter routing decisions on connected hosts. |
| 6.6 | IP mask-reply disabledno ip mask-reply | Low | Prevents subnet mask disclosure via ICMP address mask requests. |
| 6.7 | TCP synwait time configuredip tcp synwait-time 10 | Low | Reduces the window for TCP SYN flood attacks targeting the router itself. |
| 6.8 | Gratuitous ARP disabled where not neededno ip gratuitous-arps | Low | Gratuitous ARPs can interfere with ARP tables on connected switches and hosts. |
After the Checklist: What to Do with Your Results
A completed checklist is only useful if it drives action. Once you’ve worked through all 60 checks:
- Count your failures by severity. Prioritize — Critical failures first, then High, then Medium. Low-severity items are worth fixing but shouldn’t delay critical work.
- Schedule a maintenance window. Apply Critical and High remediations within days, not weeks. Medium items within a sprint. Low items in the next quarterly hardening cycle.
- Re-run the audit after changes. Confirm every remediation actually fixed the issue. Misapplied commands are common.
- Document your baseline and improvements. Save the checklist with pass/fail results, timestamps, and before/after scores. This is your compliance evidence.
- Schedule recurring audits. Configuration drift is real. Audit quarterly at minimum, and immediately after any significant change.
Pro tip: The fastest way to run this entire checklist against a real config is the automated tool at RouterAuditTool.com. Paste your config, click Run Audit, and every one of these checks is evaluated in under a second — with specific remediation commands for each failure.
Frequently Asked Questions
What is a router security audit checklist?
A router security audit checklist is a structured list of configuration checks used to verify that a router meets established security standards. Each item specifies what to look for in the configuration, the severity of the risk if it’s missing, and the IOS command needed to fix it. The checks are typically derived from frameworks like CIS Benchmark, DISA STIG, and the NSA Router Security Configuration Guide.
How many checks should a router security audit cover?
A thorough Cisco IOS security audit covers at minimum 40–60 checks across authentication, management access, unnecessary services, routing protocol security, logging, and control plane protection. The free tool at RouterAuditTool.com runs 60+ checks automatically.
How do I use this checklist for compliance documentation?
Work through each check, marking Pass, Fail, or N/A with justification. Document the config evidence for each Pass (e.g., which line in the running-config shows the control). For each Fail, note the remediation plan and timeline. Save the completed checklist as your audit evidence, with a timestamp and the auditor’s name. This format satisfies most compliance auditor requests for network device hardening evidence.
Does this checklist apply to Cisco IOS-XE as well?
Yes. The majority of checks apply identically to both classic IOS and IOS-XE. IOS-XE uses the same configuration syntax for most security features. A small number of checks have IOS-XE-specific enhancements — for example, OSPFv3 authentication uses a different syntax, and some newer hardening features are IOS-XE only.
What should I do if I can’t fix a Critical finding immediately?
Document it as an accepted risk with a remediation deadline and compensating controls. For example, if you can’t immediately disable Telnet on a legacy device, document that the device is protected by a firewall ACL that restricts management access to a jump host, and set a firm deadline to migrate to SSH. Most compliance frameworks accept documented risk acceptance with compensating controls.
Skip the Manual Work — Run All 60 Checks Instantly
Paste your Cisco IOS config and get a full scored audit report in seconds. Free. No login required.
Run Your Free Audit Now →