This post is not a security advisory write-up, and it is not a configuration guide for something you can enable on your Catalyst estate today. It is about a structural shift in how network operating systems defend themselves at runtime, and why that shift is worth understanding before it arrives. The August 2026 IOS XE advisory is a useful illustration of the problem being solved. It is not the subject of the post.
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 is shipping today on Nexus 9000 platforms, and the NX-OS Security Configuration Guide for release 10.6(x) documents the operational model in detail. It is worth understanding this workflow, because it is the model Catalyst operators should expect when the capability arrives on campus.
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. Check the current support matrix against your own hardware rather than relying on any list in an article.
It would be a mistake to read those constraints straight across to campus. They describe the Nexus implementation, not the Catalyst one, and the numbers do not transfer: the C9350 data sheet lists 16 GB of DRAM, below the Nexus memory floor. The better evidence is what Cisco has said about Catalyst directly. In its Cisco Live 2026 session on Live Protect for IOS XE (BRKENS-2615), Cisco lists three platforms: the C9350, C9550 and C9610 Smart Switches, each with IOS XE 26.2.1 as the minimum release and Network Essentials as the licence. The C9350 data sheet describes the platform as hardware-ready for Live Protect, and the C9550 data sheet positions it the same way. Cisco has announced only the new Smart Switch generation for the initial Catalyst rollout — the C9350, C9550 and C9610. Whether the feature will extend to existing C9300 deployments has not been addressed in any published Cisco documentation.
To be direct about what is and is not known: Cisco has named IOS XE 26.2.1 as the minimum Catalyst release in its Cisco Live material, but it has not given a date, and no published release notes carry the feature yet. Live Protect does not appear in the IOS XE 26.1.x release notes for the C9350, or in the IOS XE 26.2.x release notes for the C9550, where the only release listed so far is 26.2.1ea. The Cisco Trust Center page still lists Nexus as the only supported product, under the heading "coming soon across the Cisco portfolio." Some press coverage from Cisco Live US 2026, including a Heise Online report, described the Catalyst extension as already released. Cisco did announce the Catalyst platforms at the event; it has not yet shipped the feature on them. A conference session is a statement of intent, not a release note, and we are treating it that way.
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, and here we are describing what we expect rather than anything Cisco has committed to. On Nexus today, shield activity surfaces through the CLI and through syslog, which is enough to alert on but leaves the picture fragmented across an estate. In the campus we would expect that signal to become a first-class assurance input, with shield state and hit counts visible in Catalyst Center alongside the advisory and compliance views that already live there. A per-device answer to "is this shield installed, in which mode, and has it intercepted anything" is useful. A fleet-wide answer, correlated with the advisories a device is exposed to, is what turns compensating controls into something you can operate at scale rather than track in a spreadsheet. Anyone planning around this feature should be asking their account team about the management story, not only the platform support matrix.
At Entek IT, we are modelling this now, before Live Protect ships on Catalyst, because the operational patterns need to be in place before a high-severity advisory tests them. The Nexus implementation is documented in enough detail to build that model from. The Catalyst implementation will not be identical. The IOS XE session material from Cisco Live shows a command set modelled on the existing SMU workflow (compensating-control add, activate in audit or enforce mode, commit, deactivate and remove), with shields managed from Catalyst Center and the Meraki dashboard as well as the CLI. Cisco presented those commands as suggested syntax, so the exact form may change before release. The model underneath is the same: observe first, enforce second, retire once the upgrade is done, whether the platform disables the shield in place (NX-OS) or deletes it (SD-WAN).
Where it stands today
Live Protect is shipping on Nexus 9000 (NX-OS 10.6(1)F for monitor mode, 10.6(2)F for enforce mode and CVE compensating controls) and on SD-WAN control components from release 20.18.3, and Cisco has now attached a shield to a critical Nexus advisory. On campus, the C9350 and C9550 are documented as hardware-ready, and the Cisco Live 2026 session material names the C9350, C9550 and C9610 with IOS XE 26.2.1 as the minimum release. No published Catalyst release notes carry the feature yet, and no date has been given. Network World's coverage of the capability summarised the public position as campus and branch products expected later in 2026. We are taking Cisco's own language at face value.
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 watching this capability closely, and we are already working with customers planning Catalyst Smart Switch deployments where Live Protect will be a relevant operational tool. If you are thinking about how Live Protect fits into your patching model and risk-acceptance process, or if you are evaluating the C9350 or C9550 for your campus infrastructure, feel free to reach out to our team at Entek IT.
