Cisco Live Protect has arrived on Catalyst. With IOS XE 26.2.1, Cisco has introduced eBPF-based runtime protection on the new C9350, C9550 and C9610 Smart Switches. This is a significant development in how network operating systems can defend themselves against known vulnerabilities without requiring an immediate software upgrade.
This post is not a security advisory write-up or a configuration guide. It explores the architectural shift behind Live Protect, how it changes the relationship between vulnerability disclosure and remediation, and what its introduction means for operating enterprise campus networks. The August 2026 IOS XE advisory provides a useful illustration of the problem being solved.
The problem Live Protect exists to solve
The patching gap is not a new concept, but its shape has changed. Cisco's own eBPF engineering blog, written by Thomas Graf and Dan Wendlandt and published in March 2026, puts the compression plainly: exploitation timelines have compressed dramatically, while remediation across a real estate may take thirty days or more. The August 2026 IOS XE hardening advisory is a concrete example of how this plays out. Cisco's internal security testing, using existing testing processes as well as frontier AI models, found seven CVE classes, the highest rated at CVSS 9.8, and published the advisory on 5 August 2026. No workarounds were listed. First-fixed releases span multiple trains. On a campus estate with change control processes, wireless dependencies, and a finite number of maintenance windows, closing that gap in days is not a realistic engineering answer.
The instinct is to say "patch faster," and the instinct is wrong as an operational target. A C9300 running in an SD-Access fabric as an embedded wireless controller carries additional constraints that a data centre upgrade does not. Maintenance windows are booked weeks in advance. A staged upgrade across hundreds of access layer switches is not a weekend task. The gap between disclosure and completion is measured in weeks, not hours, and it is not going to shrink to the point where runtime protection becomes irrelevant. Live Protect is Cisco's structural contribution to closing that gap, though shield availability depends on the nature of the vulnerability, the platform, and the release, so it addresses a defined subset of advisories rather than all of them.
What eBPF actually is, and why it belongs in a switch
eBPF stands for extended Berkeley Packet Filter, though the name is somewhat misleading at this point: it is a general-purpose sandboxed execution environment in the Linux kernel. Programs are compiled to a bytecode, verified by the kernel before they run (the verifier enforces memory safety, loop bounds, and other constraints), and loaded without modifying kernel source or rebooting. Cisco announced its acquisition of Isovalent, the company behind Cilium and Tetragon, in December 2023 and completed it in April 2024. Tetragon is a Kubernetes-aware runtime security tool built on eBPF that also runs on any Linux system, and it provides the lineage for what became Live Protect.
In the context of a network operating system, this means a shield can be loaded against a specific advisory without a code change and without an OS reload. The shield does not fix the flaw. It blocks the execution path the flaw is reachable through. That distinction matters: once a shield is deployed in enforce mode, traffic or control-plane interactions that would reach the vulnerable code path are intercepted at the kernel level before that code executes. The flaw remains in the binary. The validated exploitation path to it is blocked — subject to documented platform, release, mode, and boot-time limitations.
The operational model, as documented on Nexus today
Live Protect was initially introduced on Nexus 9000 platforms, where the NX-OS Security Configuration Guide for release 10.6(x) documents the operational model in detail. With the introduction of Live Protect in IOS XE 26.2.1, the same underlying approach is now available on selected Catalyst Smart Switches. The implementations differ in their configuration and installation workflows, but both use Cisco-validated vulnerability shields to provide runtime protection without requiring an operating system upgrade.
The feature is enabled with feature nxsecure. Shields are distributed as packages and added to policy with nxsecure policy add <package>. Each policy entry supports three modes: monitor, enforce, and disable. Monitor mode is the correct starting point. The show nxsecure policy status output includes a Hits column that shows how many times a shield has intercepted an execution path. Running monitor mode before committing to enforce gives an operator evidence that the shield is firing where expected, and not firing in unexpected places. Cisco is explicit on the sequence: the NX-OS Security Configuration Guide 10.6(x) recommends installing policies in monitoring mode, which is also the default, for a short duration before moving them to enforce. Tom Gillis described the same monitor-then-act behaviour in a June 2026 blog post.
Shields are tied to specific advisories. They are not general hardening. When a full software upgrade supersedes the advisory a shield was issued for, the shield is retired, although what retirement means differs by platform. The NX-OS Solution Overview states the principle: "SMUs (shields) are removed once a full PSIRT-bundle upgrade is applied." In practice "removed" is looser than the observed behaviour, and the two platforms differ in the mechanics, and the difference matters operationally. On NX-OS, an upgrade past the fixed release leaves the shield installed but transitions its operational mode to N/A. On SD-WAN, upgrading the control-component software removes installed shields outright, and they must be reinstalled if the vulnerability still applies after the upgrade. The SD-WAN documentation adds further lifecycle detail: shields carry a six-month download and support period that begins when the software fix is released. After that window closes, an installed shield continues operating but Cisco withdraws support for it. Retiring shields on upgrade is a deliberate design choice and the right one. Shields that persist indefinitely after a patch is applied become hidden state, invisible to auditors and forgotten by operators. Whether the shield is disabled in place or removed, the upgrade ends its role, which enforces the intended model: shields cover the window, patches close the flaw.
One caveat is documented explicitly in the SD-WAN implementation and should be expected in any Catalyst deployment: "Live Protect and its Vulnerability Shields may not fully mitigate risks during the device boot process." A shield loaded into a running kernel is not present until after boot completes. This is not a defect. Cisco has not published the mechanism behind the gap, and the SD-WAN guide says only that systems may remain temporarily exposed until security policies are initialised. Our own reading is that it follows from when the eBPF environment becomes available during boot, but treat that as inference rather than documented behaviour. Either way it needs to be factored into any risk model that uses Live Protect as a compensating control.
A worked example: CVE-2026-20212
This is no longer a hypothetical workflow. On 2 September 2026, Cisco published a critical advisory for CVE-2026-20212, a remote code execution vulnerability in the Silicon One integration of Nexus 9000 switches, rated CVSS 9.8. Two TCP ports reachable in the default VRF allow an unauthenticated attacker to send input that executes as root. Alongside fixed software and an infrastructure ACL workaround, the advisory lists a Live Protect shield as a temporary mitigation, and Cisco is explicit about its role: it bridges the gap until a software upgrade can be scheduled.
The shield, lp00031, is supported on NX-OS 10.6(3) only, and it is not supported on the Nexus 9804 and 9808, even though both are affected by the vulnerability. That detail matters more than it first appears. Cisco validates each shield for a specific platform and software release, so an estate running several releases, or a mix of platforms, cannot assume that one shield covers every affected device. Once the shield is in enforce mode, the shield release notes show what the operator sees:
switch# show nxsecure policy status
Id Name Package Original Override Current Hits
lp00031 lps-sone-secure lp00031.lps-sone-secure-v1.lps enforce none enforce 1
switch# show nxsecure log lp00031
Policy Id : lp00031
Policy Name : lps-sone-secure
Policy Severity : CRITICAL
Policy Event : Hit for CVE-2026-20212: Cisco Nexus 9000 Series Switches Silicon One Remote Code Execution Vulnerability
Policy Event History(last 20 events):
SNo Time Mode Process
1 2026 Aug 25 01:02:38 enforce /usr/bin/nc
Two details matter operationally. The Hits column is what makes monitor mode worth running: in monitor mode a shield records matching events without blocking them, which tells you whether the path it targets is actually being exercised in your environment before you commit to enforcement. And every hit also raises a critical syslog message (%APPMGR-2-NXSECURE_CRIT_THREAT), so shield activity can be forwarded and alerted on alongside the rest of the device's logging, rather than living only in a show command.
There is one edge to that retirement model worth building into change plans. For lp00031, Cisco documents that upgrading to NX-OS 10.6(4) or later transitions the shield's operational mode to N/A, which is the retirement behaviour described above. Downgrading is different: moving back to 10.6(2) does not remove the shield, and Cisco instructs operators to remove it with nxsecure policy remove before the downgrade. In other words, retirement follows the upgrade path. A rollback procedure needs its own explicit step for any shield that is in place.
The constraints, stated honestly
On Nexus 9000, Live Protect has real platform constraints. The NXOS_ESSENTIALS licence is required from NX-OS 10.6(2)F onwards. A minimum of 24 GB RAM is required. The Nexus 9500 and 9800 chassis are not supported. Supported platforms include the Nexus 9300-FX, FX2, FX3, GX, GX2, H1, and H2R series, along with the N9300 Smart Switches and the N9K-C9408 Cloudscale switch from 10.6(2)F, and the Solution Overview additionally lists the N9400 Series and the N9200 fixed platforms. It would be a mistake to read those constraints straight across to campus. They describe the Nexus implementation, not the Catalyst one, and the requirements do not transfer directly. The C9350, for example, has 16 GB of DRAM, below the Nexus memory requirement of 24 GB.
Cisco has now formally introduced Live Protect on Catalyst with IOS XE 26.2.1. The Trustworthy Systems Guide, updated on 28 September 2026, confirms support for three platforms: the C9350, C9550 and C9610 Smart Switches.
The implementation uses a Tetragon agent embedded within IOS XE, providing kernel-level runtime protection through eBPF. Cisco-validated Vulnerability Shields can be installed without upgrading the operating system or reloading the switch. Each shield targets a specific vulnerability and is subject to platform and software compatibility requirements.
An important limitation remains. Cisco has only documented Live Protect support for the new Catalyst Smart Switch generation. Existing Catalyst C9200, C9300, C9400, C9500 and C9600 platforms are not included in the published support list. Cisco has not announced whether Live Protect will eventually become available on these platforms.
For organizations operating large installed Catalyst 9000 estates, this distinction is significant. The architectural benefits of runtime protection are clear, but their practical reach will depend on whether Cisco extends the capability beyond the new Smart Switch generation.
Live Protect implementation on IOS XE
The Catalyst implementation provides an interesting insight into how Cisco has integrated runtime protection into the existing IOS XE software architecture.
Rather than introducing an entirely separate installation mechanism, Cisco uses the existing IOS XE software installation framework to deploy Vulnerability Shields. Shields are distributed as software packages that undergo platform and software compatibility checks before activation.
The installation workflow supports both a single-step operation using install add file <filename> activate commit and a three-step process using install add, install activate and install commit.
Once installed, a shield operates in monitoring mode by default. In this mode, matching activity is recorded without being blocked. Administrators can inspect installed shields, their operational modes and associated hit counters using show platform software live-protect shield.
Enforcement is enabled separately through the platform security live-protect shield <shield-id> enforcing configuration command.
This separation between installation and enforcement is important. It allows network operators to observe whether a shield matches activity in their environment before enabling active protection. Monitoring does not guarantee that every possible side effect will be detected, but it provides an additional validation step before enforcement.
The operational model is therefore familiar to engineers accustomed to managing IOS XE software packages, while introducing a fundamentally different security capability. Instead of replacing vulnerable software, a validated shield can intercept the specific execution path associated with a vulnerability.
The distinction remains essential: Live Protect provides a compensating control, not a permanent software fix. The underlying vulnerability remains present until the affected software is upgraded.
What this changes about how we plan
The shift is not tactical. It is conceptual. Today, when a high-severity advisory lands with no listed workaround, the conversation at a customer site is about emergency change windows: which devices are most exposed, which maintenance windows can be brought forward, which risks can be accepted and documented for how long. That conversation happens under pressure, often with incomplete information about the estate's actual software versions, and it produces plans that are either too aggressive (and risk introducing instability) or too conservative (and leave documented exposure on the table).
If a validated compensating control can be deployed to cover the window, the shape of that conversation changes. The question is no longer solely "how quickly can we complete the upgrade" but "we have a validated interim control in enforce mode while we execute a scheduled upgrade." That is a meaningful change to risk acceptance. It is also a change to how maintenance plans are written, because a "patch by next scheduled window, with a documented interim control" plan is categorically different from an "accept the risk until the next window" plan. Regulators and auditors understand the difference.
There is a second-order effect worth planning for: centralized visibility and lifecycle management of vulnerability shields.
On Nexus, shield activity can be inspected through the CLI and forwarded through syslog. On Catalyst, IOS XE now provides commands to inspect installed shields, their operational modes and associated hit counters.
Cisco has also described centralized shield management through Catalyst Center and the Meraki Dashboard. Catalyst Center 3.3.1 documentation includes workflows for deploying and managing shields across supported devices. However, Cisco’s October 2026 networking update still describes Catalyst Center management as forthcoming, so operational availability should be verified against the deployed management release.
This management integration matters because deploying a shield on an individual switch is only part of the challenge. Across a large campus estate, operators need to establish which devices are affected by an advisory, whether a compatible shield exists, where it has been deployed, which mode it is operating in, and whether it has intercepted any activity.
A per-device answer is useful. A fleet-wide view, correlated with software versions, security advisories and planned maintenance activities, is what makes compensating controls operationally scalable.
At Entek IT, we see this as an important development in network infrastructure security. Runtime protection introduces an additional operational layer between vulnerability disclosure and permanent remediation.
It also creates new responsibilities. Shield deployment, monitoring, enforcement, compatibility validation and eventual retirement need to become part of the existing vulnerability management process.
The objective is not to replace software upgrades. It is to reduce exposure while those upgrades are prepared, validated and executed through normal change management.
Where it stands today
As of October 2026, Cisco Live Protect is available on Nexus 9000, supported Catalyst SD-WAN control components, and selected Catalyst Smart Switches.
With IOS XE 26.2.1, the C9350, C9550 and C9610 have become the first Catalyst switching platforms with documented Live Protect support. Cisco has published the installation, monitoring and enforcement procedures, moving the capability beyond its initial announcement into a supported software implementation.
The next important developments will be the availability of vulnerability-specific shields for Catalyst, the operational rollout of centralized management through Catalyst Center, and whether Cisco extends support to existing Catalyst 9000 platforms.
For network architects, the significance goes beyond the supported hardware list.
Live Protect introduces the possibility of separating immediate vulnerability mitigation from the software upgrade lifecycle. When a compatible shield is available, organizations can potentially reduce exposure without forcing an emergency infrastructure upgrade.
That does not eliminate patching, maintenance windows or change management. It changes the options available while those processes are carried out.
The vulnerability still needs to be fixed. But the period between disclosure and remediation no longer necessarily has to remain unprotected.
That is the architectural shift that makes Live Protect worth following.
Our Experience
The patching-gap conversation comes up regularly at customers, and it rarely resolves cleanly. Change control processes exist for good reasons. Maintenance windows are booked around business cycles. A campus estate with hundreds of switches, wireless controllers, and embedded WLC configurations is not patched on a Tuesday afternoon. The realistic timeline between advisory publication and a completed upgrade across a mixed estate, done carefully, is two to six weeks. That window is the exposure Live Protect is designed to cover.
At Entek IT, we are following the introduction of Live Protect on Catalyst closely, particularly its implications for vulnerability management across large enterprise campus environments. As customers evaluate the new Catalyst Smart Switch generation, runtime protection becomes another capability to consider alongside traditional availability, security and lifecycle requirements.
Official sources to add to the article
Cisco Live Protect Configuration Guide
Cisco IOS XE 26.2.1: What's New for Switching
Cisco Networking October 2026 Update
