A critical security advisory lands in your inbox.
The vulnerability affects technology somewhere within your network. The vendor has published details of the exposure and a software release is available to address it. How quickly can you respond?
Recent Cisco security advisories have brought this challenge into focus. In September 2026, Cisco published advisories covering products including Identity Services Engine (ISE), Nexus Dashboard and Secure Firewall, recommending customers upgrade to the fixed software identified in the relevant advisories. For IT teams, however, receiving the advisory is the easy part.
The harder challenge is knowing whether you’re affected, understanding the risk, establishing the right remediation and getting a change safely into production. That makes patching a much bigger question than simply keeping software up to date.
When a critical vulnerability is disclosed, can your organisation move from advisory to remediation quickly enough?
The gap between knowing and fixing
Security teams have access to more vulnerability information than ever.
Cisco maintains its Product Security Incident Response Team (PSIRT) advisories, while resources such as the National Vulnerability Database provide information organisations can use to monitor vulnerabilities.
Yet visibility of the vulnerability doesn’t automatically translate into visibility of your own exposure. You still need to establish what is deployed across your estate, which software releases are running and whether those systems are affected. Then you need a way to remediate them.
For a relatively simple environment, that process might be well understood. Across a larger estate containing switching, firewalls, identity infrastructure and management platforms, there can be more to consider. And every delay leaves one fundamental question unresolved:
How long is your organisation comfortable carrying a known security risk?
Patching is ultimately a risk decision
There is a legitimate tension at the centre of patch management. Move too slowly and a known vulnerability can remain unresolved. Move without the appropriate controls and a poorly managed change can create operational problems of its own.
The answer isn’t simply to patch everything immediately. Organisations need a process that can respond at a speed appropriate to the severity of the risk while still protecting the stability of the environment. This is becoming increasingly important as security disclosure and remediation continue to evolve.
Cisilion’s discussions with Cisco have also highlighted the growing importance of regular patching, observability and the ability to recover effectively when a software change causes an issue.
The focus therefore needs to shift from “Do we patch?” towards “How capable are we of patching safely when we need to?”
What happens when a critical advisory lands?
This is where organisations can test the maturity of their process. Imagine a vendor releases a Critical advisory this morning.
Your first task is understanding whether the affected technology exists within your environment. That requires reliable knowledge of your infrastructure, including the products and software releases you are running. If you’re affected, somebody then needs to interpret the advisory and determine the appropriate remediation.
Next comes the operational work. The software needs to be available through the appropriate vendor entitlement, the change needs to be assessed and testing may be necessary before deployment.
More complex platforms can add further considerations. Cisilion’s Network Infrastructure service documentation, for example, recognises that major releases for platforms including Cisco ISE can require detailed analysis plus pre and post-testing.
This means the speed of your response depends on much more than the security team spotting a CVE. It depends on the health of the process surrounding it.
Where does patching get stuck?
For some organisations, the first obstacle is visibility.
If there isn’t a reliable view of the infrastructure estate, identifying affected assets can become a task in itself. Elsewhere, remediation can become caught between teams and processes. Security may identify the vulnerability. Network teams need to understand its infrastructure impact. Change processes govern deployment. Maintenance and entitlement determine access to vendor software.
This is why ownership matters.
A mature process should make it clear who monitors vulnerabilities, who assesses exposure, who owns remediation and how decisions are made if patching needs to be delayed. A Critical advisory is a poor time to discover that an important piece of infrastructure is outside the support position you thought it was in.
How much risk are you prepared to carry?
This is where patching moves out of the server room and into a wider business conversation. Security risk never disappears completely. Organisations make decisions about risk every day.
The important part is understanding when you are making one. If remediation is delayed for days or weeks because of testing, ownership, entitlement or change control, the business should understand that a known vulnerability remains unresolved during that period.
That creates a more useful discussion than simply measuring how many patches have been deployed.
Ask instead:
- How long does it take us to identify our exposure?
- How quickly can we establish a remediation plan?
- What prevents us from moving faster when the risk requires it?
- Who accepts the risk when remediation is delayed?
The answers provide a much clearer picture of patching health.
Moving from reactive patching to continuous vulnerability management
The strongest patching strategy is one that doesn’t need to be invented every time an advisory appears.
Asset and software visibility should already exist. Vendor support and software entitlement should be understood. Vulnerability monitoring should have defined ownership. Testing, change control and remediation should follow an established process.
That creates the foundation for moving away from one-off responses towards ongoing vulnerability management. This is also where external support can add value, particularly where internal teams have limited capacity or are managing increasingly complex infrastructure
Where Cisilion fits
Cisilion can support clients at several points in that lifecycle.
A Professional Services engagement can help assess security posture, review relevant PSIRT information and support software upgrades and remediation.
Maintenance and support reviews can help establish whether appropriate vendor coverage and software entitlement are in place.
For organisations that want vulnerability management to become part of the ongoing operation of their network, it can also sit within a Managed Service.
Cisilion’s Network Infrastructure Managed Service includes Critical vulnerability management within its Manage service level. Cisilion reviews vendor Critical vulnerability notifications and provides plans to mitigate the risk of known vulnerabilities within supported devices, with Critical vulnerability patching included in the service and subject to the agreed change process.
That is ultimately the shift organisations should be considering. Instead of waiting for a Critical advisory and then working out what to do, build vulnerability and patch management into the way the network is operated.
If a critical advisory landed tomorrow, would you be ready?
The next significant security advisory shouldn’t come as a surprise. Its timing might. The affected product might. The remediation required might.
Your response process shouldn’t. Understanding your estate, maintaining the right vendor coverage and establishing a reliable route from identification to remediation can put your organisation in a much stronger position when vulnerabilities emerge.
Because good patching health isn’t measured simply by whether you’re currently up to date.
It’s measured by how effectively you can respond when you’re suddenly not. Cisilion can help you assess your existing network security posture, address vulnerabilities and establish an ongoing approach to vulnerability and patch management.
FAQ
Network security patching is the process of applying vendor-supplied software fixes or updates to address known vulnerabilities within network infrastructure.
Organisations should establish whether affected technology and software versions are present within their environment, review the vendor’s advisory and recommended remediation then follow their established security, testing and change processes.
Cisco’s Product Security Incident Response Team publishes security advisories explaining vulnerabilities affecting Cisco products and relevant remediation information.
Network changes can require assessment, testing and change control to protect the stability of critical infrastructure. More complex platforms and major software releases can require deeper analysis and pre and post-testing.
Vulnerability management deals more broadly with identifying and responding to vulnerabilities affecting an environment. Patching is one potential remediation used to address those vulnerabilities.
Yes. Cisilion’s Network Infrastructure Managed Service includes Critical vulnerability management, including vendor notification review, remediation planning and Critical vulnerability patching subject to the agreed change process.