Guide
Cisco Live Protect: Closing the Patch Gap With In-Kernel Protection
Live Protect puts validated eBPF policies — shields — into the kernel of a running switch, recording and, in enforce mode, blocking a disclosed vulnerability's exploit path while the fixed release is still in the change queue.
Every network team knows the uncomfortable stretch between a security advisory and the maintenance window that resolves it. Exploit activity often begins within days of a disclosure, while validating and scheduling an infrastructure upgrade is commonly measured in weeks. Cisco Live Protect is built for exactly that stretch: Cisco-validated runtime policies — shields — that execute inside the kernel of a supported switch, watching for and, in enforce mode, blocking the runtime behavior of a specific disclosed vulnerability’s exploit path until the fixed release is installed. It is a compensating control with a planned retirement date, not a new way to avoid patching.
The Window Between Advisory and Patch
The patch gap on network infrastructure is structural, not a sign of a lazy operations team. A core switch upgrade needs a qualified target release, lab validation, a change approval, and a window the business will tolerate — discipline covered in our change-management guide — and none of that compresses just because an advisory is critical. Security teams have long answered this on servers with compensating controls: a rule that blocks the exploit path while the real fix works through the pipeline. What has been missing is a way to do the same inside the network operating system itself, with the vendor’s own validation behind the rule. That is the slot Live Protect fills. When Cisco discloses a vulnerability on a supported platform, it can publish a corresponding shield — a policy validated against that specific threat vector — and the operator chooses whether and how to run it. Coverage is selective, per advisory and per platform: an advisory does not imply a shield exists for it.
Shields Are eBPF Policy in the Switch Kernel
Under the hood, Live Protect is an application of technology this site has covered from the Linux side. It is built on eBPF and Tetragon from Cisco’s Isovalent team: a Tetragon agent is built into NX-OS, and a shield’s logic runs as eBPF programs in the kernel of the switch control plane. That vantage point is the product’s argument. A shield observes the kernel events Cisco has instrumented for it — such as process execution, privilege changes, file I/O, and control-plane API and CLI activity, depending on the shield — with the context the kernel holds, so it matches the runtime behavior of an exploit path where that behavior happens rather than inferring it from external telemetry, and in enforce mode it can block the matching activity outright. It is the same in-kernel observation-and-enforcement model Tetragon brings to containerized workloads, pointed at the network device itself — and because eBPF programs load dynamically, a shield applies to a running switch with no reboot and no NX-OS upgrade.
Monitor First, Then Enforce
In-kernel enforcement on a production switch deserves the same respect it earns anywhere else, and the shield lifecycle is built around that caution. Cisco’s published flow runs advisory, validated policy, monitor or enforce, then patch and retire. Monitor mode records the events a shield would have matched without acting on them, which lets an operator assess operational impact against real control-plane behavior before committing to enforcement — the observe-first discipline that every enforcement technology rewards. Enforcement is also release-dependent: the NX-OS release that introduced Live Protect, 10.6(1)F, runs shields in monitor mode only, and enforce mode becomes available beginning with 10.6(2)F. The end of the lifecycle matters as much as the start: once the fixed software is installed and validated, the shield has done its job and Cisco’s guidance is to retire it. A compensating control that quietly becomes permanent is how environments accumulate unexplained policy, so treat each shield like the temporary object it is designed to be.
Where It Runs Today
Live Protect arrived first in the data center, and the eligibility list is narrower than “Nexus 9000.” Support debuted on a defined subset of Nexus 9300 switches with a 24 GB memory minimum, and later 10.6 releases broadened it to the smart-switch line and additional models; the Nexus 9500 and 9800 are not supported. The release-specific hardware matrix in Cisco’s NX-OS security configuration guide is the authority, not the series name. Shields are managed locally through the NX-OS CLI or API, or centrally through Nexus Dashboard for fleet-scale orchestration, which is what makes the monitor-everywhere-then-enforce pattern practical beyond a handful of devices. The honest scope statement is that this is a young capability on a defined platform set — check Cisco’s current documentation for what your hardware and release support before building it into an operational runbook.
Live Protect itself is not a certification blueprint topic. The concepts underneath it are: SCOR 350-701 v2 objective 3.6 names eBPF among the application and workload security concepts a core-exam candidate describes, and the vulnerability-and-exploit concepts a shield mitigates sit in the Security Concepts domain. The SCOR course builds that foundation hands-on — and when a vendor puts a runtime-security agent inside a switch kernel, the engineers who already understand the model are the ones who get to say yes or no with confidence.
Frequently Asked Questions
Is Live Protect a replacement for patching?
No, and Cisco is explicit about this. A shield is a temporary compensating control that narrows the exposure window between a vulnerability's disclosure and its permanent fix. Once the fixed software is installed, the shield's job is over and Cisco's guidance is to retire it — the patch remains the remediation of record.
How does Live Protect relate to eBPF and Tetragon?
Live Protect is built on eBPF and Tetragon technology from Cisco's Isovalent team. A Tetragon agent is built into NX-OS, and each shield is policy that executes as eBPF programs in the kernel of the switch control plane — the same runtime-security model used for Linux workloads, applied to network infrastructure.
Does applying a shield disrupt the switch?
A shield is applied to a running system with no reboot required. The cautious path is the default: monitor mode records the events a shield would have acted on without enforcing anything, so you can watch a candidate policy against real control-plane activity first. Enforcement is release-dependent — the debut NX-OS release runs shields in monitor mode only, with enforce mode arriving in the following release.