Cisco IOS XE 26: New Versioning and Secure by Default

If you looked up a software release for a Catalyst switch recently, you probably noticed something unusual: the version number jumped from 17.18 to 26.1. This is not a typo, and it is not eight missing major releases. Cisco changed the way IOS XE is numbered, and the first release under the new scheme also happens to be the most significant security change the platform has seen in years.

In this article, we will look at what the new numbering means, what actually changed in IOS XE 26.1, and what you need to check before upgrading a device that is still running a 17.x image.

Cisco moved IOS XE to a Year.Release.Build numbering scheme. The first number is now the year of the release, so 26.1.1 reads as: the first release train of 2026, first build. There is no 18 through 25 — the version simply jumped to match the calendar.

The reason is practical. With the old scheme, knowing whether 17.9 was older or newer than 17.12, and where either sat in its support lifecycle, required looking up a table. With a year in front, the age of an image is obvious at a glance:

• 26.1.1 — first release train of 2026 (first Extended Maintenance Release under the new scheme)
• 26.1.2 — the maintenance build Cisco currently recommends on that train
• 17.18.x, 17.15.x, 17.12.x, 17.9.x — the long-lived 17 trains, still maintained in parallel

The headline change in IOS XE 26.1 is Resilient Infrastructure, Cisco's initiative to make secure-by-default the baseline. Historically, a factory IOS device would happily let you configure Telnet, SNMPv2c, and an HTTP server with no pushback at all. That is over.

Cisco is rolling this out in three phases:

1. Warning — the device logs a warning when an insecure feature is configured, but nothing is blocked. This started in 17.18.2.
2. Restriction — insecure features are refused by default and require the device to be explicitly placed in insecure mode. This starts in 26.1.1.
3. Removal — the feature is deleted from the codebase entirely, in a future release.

Starting with 26.1.1, the device runs in secure mode by default. Trying to apply a restricted configuration in that state gets rejected:

Switch(config)# line vty 0 4
Switch(config-line)# transport input telnet
%Error:Insecure configurations are not permitted in secure mode.

If you genuinely need one of those features during a migration, you can drop the device into insecure mode explicitly:

Switch(config)# system mode insecure

There is an important detail here for upgrades. When a device is upgraded to 26.1.1 or later, IOS XE scans the running configuration at boot and, if it finds any restricted configuration already in place, it transitions the device to insecure mode automatically. Your upgrade will not lock you out — but the device will quietly sit in insecure mode until someone cleans up the configuration.

These commands let you audit the state of a device:

Switch# show system security mode
Switch# show system insecure configuration
Switch# show system insecure profile
Switch# test system secure all

show system security mode tells you whether you are in secure or insecure mode. show system insecure configuration lists the restricted commands currently applied — this is the list you have to work through. show system insecure profile shows every pattern the system knows how to detect, and test system secure all forces an immediate rescan instead of waiting for the periodic one.

The list of features covered by Resilient Infrastructure is long, but most of it is predictable if you have ever run a hardening checklist. The main entries, with their secure replacements:

• Telnet → SSHv2
• ip http server → ip http secure-server (HTTPS)
• SNMPv1 and SNMPv2c → SNMPv3 with authentication and encryption
• TFTP, FTP, RCP and RSH transfers → SCP or SFTP
• TLS 1.0 and 1.1 → TLS 1.2 minimum, TLS 1.3 preferred
• CBC-mode ciphers → GCM-mode ciphers
• MD5 and SHA-1 → SHA-2 family (including NTP authentication, which should use hmac-sha2-256)
• DES and 3DES → AES
• service password-encryption (type 7) → AES-based password encryption
• RSA keys under 2048 bits → RSA 3072 bits or an EC key of 256 bits or more
• TCP and UDP small servers, IP finger, BOOTP server, IP source routing → disable
• Unencrypted RADIUS, TACACS+ and LDAP → run them over TLS

Warnings show up in the log under three distinct message types, which is useful when you are filtering syslog: %SYS-4-INSECURE_CONFIG for configuration that is restricted to insecure mode, %SYS-4-INSECURE_WARNING for insecure commands with no remediation path, and %SYS-4-INSECURE_DYNAMIC_WARNING for those where the device can suggest a fix.

Security dominates the release notes, but 26.1.1 is a full Extended Maintenance Release and brings other work on the Catalyst 9000 family:

• Post-quantum cryptography moves from a stated intent to working quantum-safe algorithms across the Smart Switch portfolio
• Granular energy telemetry on the C9200CX, reporting system and PoE power over 15-minute intervals aggregated into 3-hour windows, exposed through both CLI and streaming telemetry
• Support for newer hardware, including the C9350 Smart Switch series
• Continued expansion of automation and streaming telemetry across the platform

The energy telemetry is worth a look if you have any reporting obligation around power consumption — getting per-port PoE draw out of the switch itself is a lot cheaper than instrumenting the rack.

The pre-upgrade audit matters more than usual with this release. If you are already running 17.18.2 or later, the device can tell you what will break before you touch it:

Switch# show system insecure configuration
Switch# show running-config | include transport input|snmp-server community|ip http server

Work through whatever comes back, fix it on the current release, and confirm you can reach the device over SSH before you start. A minimum viable cleanup on a switch that has never been hardened looks like this:

Switch(config)# hostname SW1
SW1(config)# ip domain name lab.local
SW1(config)# crypto key generate rsa modulus 3072
SW1(config)# ip ssh version 2
SW1(config)# line vty 0 15
SW1(config-line)# transport input ssh
SW1(config-line)# exit
SW1(config)# no ip http server
SW1(config)# ip http secure-server
SW1(config)# no snmp-server community public
SW1(config)# end
SW1# write memory

On Catalyst 9000 switches running in install mode, the upgrade itself is unchanged. Clean up old packages, copy the image, confirm the boot variable, then add and activate:

SW1# install remove inactive
SW1# copy tftp: flash:
SW1# show boot

SW1(config)# boot system flash:packages.conf
SW1(config)# end
SW1# write memory

SW1# install add file flash:cat9k_iosxe.26.01.02.SPA.bin activate commit

The install add file ... activate commit command reloads the device and prompts for confirmation along the way, so run it from a console session or a connection you are willing to lose. After the reload, check where you landed:

SW1# show version
SW1# show install summary
SW1# show system security mode

If that last command reports insecure mode, the boot-time scan found something. Run show system insecure configuration to see what it was.

One more reason not to postpone this. In August 2026, Cisco published a security hardening release covering vulnerabilities found during internal testing — grouped by weakness class rather than individually, with a top CVSS base score of 9.8. There are no workarounds; the fix is an upgrade. The first fixed builds per train:

• 17.9 → 17.9.10
• 17.12 → 17.12.8
• 17.15 → 17.15.6
• 17.18 → 17.18.4 / 17.18.4a
• 26.1 → 26.1.2

Note that 26.1.1, the first build of the new train, is not on that list. If you are migrating to 26.x, target 26.1.2 directly rather than the initial release.

IOS XE 26 is two changes wearing one version number. The renumbering is cosmetic and genuinely helpful — a glance at the version now tells you how old an image is. The secure-by-default enforcement is not cosmetic at all, and it is the part that deserves your lab time before it reaches production.

The practical takeaway is unchanged from any hardening guide, only now the device enforces it: SSH instead of Telnet, HTTPS instead of HTTP, SNMPv3 instead of community strings, SHA-2 instead of MD5. If your configurations already look like that, upgrading to 26.1.2 is routine. If they do not, the pre-upgrade audit is where you find out.