Cisco IOS-XE Hardening: 8 Non-Negotiable Config Changes for Production in 2026

Let’s Be Real for a Second

Last month, a team in our org deployed a fresh ASR1000. Three weeks later, it got popped by a simple SSH brute-force. The root cause? They left enable password cisco in the running config. In 2026. I’m not making this up.

I’ve been digging through Reddit and HN discussions lately, and this isn’t an isolated incident. People are still treating IOS-XE security like it’s 2005. Management interfaces exposed to the internet. No ACLs. HTTP server running. It’s a mess.

So here’s the thing — this isn’t going to be some fluffy “enterprise digital transformation” garbage. This is the stuff you’ll actually hit in production, the configs that’ll save your ass when the next CVE drops.

1. Foundation: Stop Letting Attackers Walk In

SSH Key Generation 101

Half the people I see skip this step and wonder why SSH fails:

Router(config)# hostname CORE-1
CORE-1(config)# ip domain-name example.com
CORE-1(config)# crypto key generate rsa modulus 2048

No domain name? No key generation. IOS-XE needs an FQDN to build the RSA key pair. And for the love of god, stop using 1024-bit keys. That’s like locking your front door with a rubber band.

Password Encryption Isn’t Optional

CORE-1(config)# service password-encryption
CORE-1(config)# enable secret MyStr0ng!Pass

Look, service password-encryption uses type 7 — it’s obfuscation, not encryption. A 12-year-old with a Python script can crack it. But it’s still better than enable password which stores the password in plaintext in your running config. I’ve seen auditors walk into NOCs, glance at a terminal, and walk out with the enable password.

Kill the Dead Services

CORE-1(config)# no ip http server
CORE-1(config)# no ip http secure-server
CORE-1(config)# no ip finger
CORE-1(config)# no service tcp-small-servers
CORE-1(config)# no service udp-small-servers

HTTP Server is enabled by default on older IOS versions. Why? I genuinely don’t know. It’s an attack surface with zero upside for production. Use CLI like a real engineer.

2. SSH: Your Keys Are Not a Backdoor

Cisco’s own IOS-XE SSH best practices doc recommends multiple authentication methods. Yet most people only configure password auth and call it a day. That’s lazy.

CORE-1(config)# ip ssh version 2
CORE-1(config)# ip ssh authentication-retries 3
CORE-1(config)# ip ssh time-out 30
CORE-1(config)# ip ssh server algorithm encryption aes256-ctr aes192-ctr
CORE-1(config)# ip ssh server algorithm mac hmac-sha2-256 hmac-sha2-512
CORE-1(config)# line vty 0 15
CORE-1(config-line)# transport input ssh
CORE-1(config-line)# login local
CORE-1(config-line)# exec-timeout 5 0

Here’s the trap: exec-timeout. I’ve seen people set this to 1440 minutes (24 hours). That’s like leaving your laptop unlocked at a coffee shop. 5 minutes is reasonable. 10 is the absolute ceiling.

3. Management Plane Protection: Don’t Let Your Control Plane Get DDoSed

CORE-1(config)# control-plane
CORE-1(config-cp)# management-plane
CORE-1(config-cp-mgmt)# host 10.0.0.0 255.255.255.0
CORE-1(config-cp-mgmt)# allow ssh

This config is criminally underused. It tells the router to only accept SSH on the management interface. Even if someone configures SSH on a data-plane interface, it won’t respond. In production, this is a lifesaver.

4. AAA and Logging: Cover Your Ass

CORE-1(config)# aaa new-model
CORE-1(config)# aaa authentication login default local
CORE-1(config)# aaa authorization exec default local
CORE-1(config)# logging console warnings
CORE-1(config)# logging buffered 16384
CORE-1(config)# logging host 192.168.1.100

Pro tip: If you’re using TACACS+ or RADIUS, always configure a local fallback. When Cisco’s ACS went down a few years ago, entire NOCs lost access to their gear. The phone rang off the hook for 45 minutes. Don’t be that team.

Best Practices Comparison Table

FAQ

Is Cisco IOS XE end of life?

No. Cisco continues active development on IOS XE, with the 17.x series receiving regular updates. However, older trains like early 16.x releases have reached EOL. You should be running at least 17.6 or later for current security patches.

What’s the real difference between IOS and IOS XE?

Put simply: IOS is a monolithic OS running directly on hardware. IOS XE runs IOSd as a process on top of a Linux kernel. This means you get modern Linux tooling — Guest Shell, Python scripting, even container support. But it also means a larger attack surface. Linux kernel CVEs can affect IOS XE too. It’s a trade-off.

How do privilege levels work on IOS XE?

Default is Level 1 (user EXEC) and Level 15 (privileged EXEC). You can configure 0-15, but honestly? Most environments only need 1 and 15. I’ve seen teams create 6 different privilege levels and then spend hours debugging why someone can’t run show interface. Keep it simple.

What password hashing algorithm should I use?

Cisco supports type 9 (scrypt) from IOS 15.x onward. Use it. Type 5 (MD5) is broken — collision attacks are trivial in 2026. The command is enable algorithm-type scrypt secret. One line, massive security improvement.

Final Thoughts

I spent some time reading through Reddit threads while writing this. The sentiment is clear: Cisco’s documentation ranges from “meh” to “actively misleading.” But that’s not an excuse to skip hardening.

Here’s the thing — hardening isn’t a one-time event. Periodic auditing matters more than any single “best practice” config. Our team runs automated config scans every quarter. Python scripts check every device against our security baseline. Violations get flagged and tied to performance reviews. It sounds draconian, but it works.

IOS-XE is a solid platform. But only if you lock it down properly.