I have known a number of Cisco customers who had not been rebooted at least one Cisco device in the last five years. Vulnerabilities have been discovered for these devices and these devices have never been patched, which is a security exploit in a company’s network.
In order to patch or replace an older device, you may have to consider disconnecting from the production network for a period of time.
Vulnerability management is a decision problem about what you are willing to take offline, and when, and who signs off for the outage.
AI has now discovered vulnerabilities which forces you patch your devices with urgency. The time is now.
The window closed, the process did not
I opened this series by arguing that AI has collapsed the time between a weakness/vulnerability being discovered and that weakness/vulnerability being used by a potential hacker to compromise your network. Note that attackers don’t have to worry about a change window, and its impact on production network.
Meanwhile most vulnerability programs still run on a rhythm that was designed for a slower adversary being discovered.
Here is the model currently being followed, not fit for AI-led vulnerability discovery:
- Scan vulnerabilities on a schedule.
- Produce a list.
- Rank the list.
- Wait for a maintenance window.
- Argue about the maintenance window.
In that model, the constraint was never information. It was time and risk of downtime, and AI just took most of the time away.
So the question I would put to a CIO is this: how many days pass between the day we learn about a new vulnerability and the day we actually patched it, and is that time gap measured in days or in months?
Compensatory control is the part I got excited about
This is why “Cisco Live Protect” is the thing I keep bringing up with customers. Cisco has gotten good at finding vulnerabilities that carry real risk, but the more useful part is what comes next. It can put a compensatory control in place immediately that protects the environment in the short term, which gives the organization breathing time to plan how to patch properly instead of scrambling.
That matters because of the Cisco network devices I described earlier. In the real world you cannot patch a clinical system, a payment environment, or a production line on demand. Being protected today and patched on a plan is a very different posture from being exposed today and patched eventually.
Coming out of Cisco Live 2026, this is my number one piece of advice to customers. Fixing the vulnerabilities that live in very old infrastructure that has been running quietly for years is very, very important, and I would encourage every CIO to move on it now, because it is the foundation that everything else is supported by.
The list is no longer only CVEs
AI changes the process through the introduction of models, data, agents, and the network itself.
Models. There are a lot of LLMs used by enterprises now, some large, some small. You do not know whether those models have been poisoned. You do not know whether they are giving you the right information. That is a vulnerability, and the way you find it is by red teaming through tools like Cisco AI Defense. AI Defense, as part of Cisco Secure AI Factory, brings huge value here. Almost every organization has an AI project, so this has become the natural entry point for the conversation.
Data. In a traditional application, if you have bad data, you store it in a relational database, you find it, and you clean it. At present, once an LLM has absorbed this bad data, there is no simple process to unlearn it. It is a huge issue. Think of it as a vulnerability class with no patch, which means the control has to move upstream to what you feed the model and where the model runs.
Agents. Agentic AI applications may end up outnumbering employees. A human has an identity when logging into a company. A passkey, maybe face recognition. What should an agent have as an identity? An agent does not have a face, and it may take actions on your behalf. Every credential an agent holds is in scope for vulnerability management, and most organizations have not realized the issue here.
The AI network itself. As a traditional network designer, I look at this and see something new. You now have a front-end network and a back-end network, because GPUs have to talk to each other faster than the normal data network. That back-end network never existed before. It is a new surface; it requires real skill to design correctly, and skill gaps may lead to vulnerabilities.
You cannot prioritize what you cannot see
When I look at security incidents, there are really only two types. Denial of service or identity comprise. Every single instance is one or the other. That is a useful lens for prioritization, because it forces the question of what an exposure would actually let someone do.
Answering that requires visibility inside the environment, not just at the edge. Somebody can spin off a process that later reaches your application or your valuable data, and the outside firewall is not going to know about it until the damage is done. This is what I like about Cisco Isovalent. It captures who is talking to who at the kernel level, and there is no other software that gives you that view.
Pair that with Splunk observability and it gives you the visibility you need to protect against potential attacks. Am I subject to a denial of service? Where is this identity being used, which parts of the application or infrastructure has it touched, and why? That is the input that turns a vulnerability list into a ranked set of decisions.
Production is where the profile changes
One more thing I see constantly. A finance department in an AI pilot may test the processing of hundreds invoices a day. When it goes into production, the question becomes whether it can do 10,000 or 100,000 or more. That is where the problems come in, and the security profile shifts with the volume. More connections, more credentials, more integrations, more exposure, and this is where denial of service attacks can impact production.
So start small. Identify one to five early pilots, make them successful, capture the lessons, and then scale the operation which can manage the risks resulting from AI vulnerabilities. Most AI programs stall at exactly this line, not because the model failed, but because the foundation underneath it was never built for production.
What I would ask
1. How many days pass between a vulnerability being identified and our environment being protected from it?
2. Which of our critical systems cannot be patched on demand, and what compensatory controls are available today?
3. Have our AI models been red teamed, and by whom?
4. What identity do our agents have, and what access do they have?
5. Can we see who is talking to who inside the environment or with external environment?
If those five have honest answers, the program is real.
The point
Vulnerability management used to be a list and a maintenance calendar. AI has significantly reduced the time to patch systems in response to new vulnerabilities being discovered. The question has turned into how fast can you protect?
The good news is that none of this requires waiting. Compensatory control exists. Red teaming exists. Kernel level visibility exists. What is usually missing is a sound plan for protecting emerging AI-based infrastructure. The decision is in your hands, and now is the time to make it.
Check all thoughts
