Most organisations already have an established process for managing known vulnerabilities. Tools identify components associated with published Common Vulnerabilities and Exposures (CVEs), security teams assess the severity and vendors provide updates that can be tested and deployed.
Security researchers can now use specialist AI models to discover zero-day vulnerabilities at greater speed and scale. When these vulnerabilities are first identified, a vendor patch or established remediation route may not yet exist.
As comparable capabilities become more widely available, attackers will also be able to use AI to search for undiscovered weaknesses and exploit known vulnerabilities more quickly, shortening the time organisations have to respond.
CIOs must therefore manage two streams of work simultaneously:
- Established CVE-based vulnerability management and
- Newly discovered vulnerabilities that may require containment while an effective remediation is identified, tested and deployed.
Unmanaged technical debt makes both processes harder. Unsupported components, fragile dependencies and systems that are difficult to change can prevent organisations from applying available updates or developing safe fixes quickly.
AI is not replacing established vulnerability management. It is creating a second, faster-moving challenge that organisations must manage alongside it.
What the NCSC means by a vulnerability patch wave
In May 2026, the UK’s National Cyber Security Centre warned that AI is increasing the speed and scale at which vulnerabilities can be discovered and exploited across the technology ecosystem.
It expects this to lead to a vulnerability patch wave – a surge of software updates released as previously unknown vulnerabilities are identified across open-source, commercial, proprietary and software-as-a-service technology.
Technical debt is not the same as vulnerability management. However, it can determine how effectively an organisation responds. Unsupported software, outdated components, fragile integrations and poorly understood dependencies can delay an available update or make it considerably harder to develop and deploy an alternative fix when no patch exists.
- For a broader look at the options available when technology starts creating material constraints, see Catapult CX’s guide to legacy system modernisation.
AI has changed the speed of vulnerability discovery
The capability behind the NCSC warning is already being demonstrated.
Through Project Glasswing, Anthropic initially gave around 50 vetted organisations access to its Mythos Preview model to scan important codebases for vulnerabilities. In June 2026, Anthropic reported that participants had identified more than 10,000 high or critical-severity security flaws.
That figure needs context. It comes from Anthropic’s own programme rather than independent, industry-wide research and it does not mean every organisation should expect to uncover thousands of serious vulnerabilities.
What it demonstrates is how quickly the vulnerability landscape is changing.
Traditional CVE management starts once a vulnerability has been identified, assessed and published. Tools can then alert organisations to affected components, while vendors and maintainers work to provide updates.
AI-assisted discovery moves the starting point earlier. Specialist models can analyse large codebases to find previously unknown vulnerabilities before a CVE, vendor patch or established remediation route exists.
Access to Anthropic’s Mythos models remains limited to vetted organisations, but safeguarded versions of the underlying capabilities are becoming more widely available. Anthropic also expects comparable cyber capabilities to spread across the market.
CIOs should not therefore build their plans around one particular model becoming publicly available. The capability is what matters.
As AI accelerates zero-day discovery, organisations need the ability to investigate the vulnerability, assess their exposure and identify an effective response. That may involve working with a vendor or maintainer, developing a fix internally, using AI to support remediation or containing the affected system until a safe solution is available.
The bottleneck is moving from discovery to remediation
Discovering a vulnerability is only part of the problem.
Remediating it safely across a complex technology estate is considerably harder and the route depends on whether an established fix exists.
For a known CVE, the response may begin with a vendor or maintainer update. Even then, the organisation may be unable to apply it immediately. The affected software might first need to be brought onto a supported version, while dependencies and connected applications may also need to be updated.
A newly discovered zero-day presents a different challenge. With no established patch available, the organisation may need to work with the vendor or maintainer, develop its own fix, use AI to identify possible remediation or introduce temporary controls to contain the exposure.
In either case, the response may need to be:
- assessed against the asset’s exposure, criticality and existing security controls
- checked against software versions and support requirements
- tested across connected applications and dependencies
- approved for release
- scheduled around operational requirements
- deployed across multiple environments
- monitored for unexpected consequences
- reversed or restored to the previous stable version if it causes problems
Each stage requires engineering time, testing capacity and operational co-ordination.
The NCSC recognises these constraints in its vulnerability-management guidance. It recommends updating by default, while acknowledging that automatic or immediate updates may not be appropriate for operational technology, safety-critical systems or environments where changes require additional testing.
Anthropic has reached a similar conclusion from the discovery side, identifying verification, disclosure and patching as the emerging bottleneck as AI increases the volume of vulnerabilities being found.
The patch wave is therefore not simply a security-team workload problem. Organisations need the engineering capability to investigate vulnerabilities, identify or develop fixes and deploy them safely. That work will compete for many of the same people, environments and delivery capacity needed to maintain services and deliver roadmap priorities.
Responsibility will rarely sit with the CIO alone. CISOs, Heads of Architecture and Transformation Programme Directors may all be involved in deciding whether a vulnerable system should be updated, contained, remediated or modernised.
When the affected technology is unsupported, poorly understood or difficult to change, every part of that response becomes harder.
When vulnerability management becomes a modernisation problem
A missing patch does not automatically make a system legacy. Newly discovered zero-day vulnerabilities may affect modern, fully supported technology before a fix has been developed.
The modernisation problem arises when the underlying technology prevents the organisation from responding effectively.
The NCSC warns that patching alone will not always be enough. End-of-life or unsupported technology may no longer receive security updates. In other cases, a patch may exist but cannot be applied until the organisation upgrades an outdated operating system, runtime, framework or other dependency.
An organisation might be relying on:
- an unsupported operating system
- a discontinued vendor product
- an obsolete runtime
- an abandoned framework or library
- an application built around several unsupported dependencies
- a tightly coupled platform where changing one component affects multiple connected systems
The application may still appear to operate reliably. That does not mean it remains secure, supportable or safe to change.
The UK Government Legacy IT Risk Assessment Framework treats end-of-life and end-of-support status as explicit legacy risks. It also considers known security vulnerabilities, scarce skills, inability to meet business needs and dependencies on other systems.
The distinction is important. Vulnerability management identifies and addresses the immediate security risk. Technical-debt management deals with the underlying conditions that make that response slower, more difficult or, in some cases, impossible.
The question is no longer simply, how quickly can we install the update? It becomes, what must change before this system can be secured and supported effectively?
The answer might be to upgrade the underlying technology, restore it to a supported state, isolate it, wrap it with additional controls, migrate selected components, replace the constrained element or retire the system entirely.
- Catapult CX’s Legacy Systems work is built around this type of decision – identifying what genuinely needs to change without assuming that the entire platform must be replaced.
Unmanaged technical debt increases the cost of remediation
Technical debt has always carried a cost.
Slower releases, difficult integrations, scarce skills and greater security and compliance exposure all consume money and capacity. Because these costs often accumulate gradually, organisations can tolerate or defer them.
A newly discovered vulnerability changes the timing.
Technical debt scheduled for attention next year can suddenly restrict the response required today. Engineering capacity may need to be diverted, outdated software upgraded, vendors engaged and unsupported components replaced before the immediate vulnerability can be addressed.
The technical debt has not changed, but its operational significance has.
This does not make vulnerability management and technical-debt management the same discipline. The vulnerability may exist independently of the debt. However, unsupported technology, fragile architecture and poorly understood dependencies can determine how quickly and safely the organisation can remediate it.
The problem is compounded when the organisation has no established process for identifying, assessing and reducing technical debt. Security teams may know that a vulnerability requires action without having the ownership, architectural visibility or delivery capability needed to act.
Catapult CX’s guide to calculating technical debt in financial terms considers the wider cost of maintenance overhead, delivery delays, incidents, scarce skills and security exposure.
As AI increases the speed of vulnerability discovery and exploitation, organisations need to reassess those costs and risks. Technical debt that once appeared tolerable may now be constraining the organisation’s ability to respond.
Don’t modernise everything. Prioritise by exposure and remediation route
None of this means every old system suddenly needs replacing.
Old is not the same as legacy. A twenty-year-old system that remains secure, supported, reliable and fit for purpose can present considerably less risk than a five-year-old platform that is unsupported, poorly understood and difficult to change.
The right response is prioritisation.
The NCSC recommends starting with internet-facing and other externally exposed technology before working inwards. Where organisations cannot update everything, external attack surfaces and critical security systems should take priority.
Vulnerability severity alone does not determine the urgency. Organisations also need to understand:
- whether the affected asset is reachable in their environment
- how critical it is to operations
- whether the vulnerability is being actively exploited
- what security controls already surround it
- whether a vendor or maintainer fix is available
- whether the organisation can apply that fix safely
- whether an alternative remediation or containment route exists
The UK Government’s legacy framework takes a similarly risk-based approach by considering both the likelihood of a problem and its potential impact.
For legacy modernisation, Catapult CX would add another question – does the underlying technology enable or constrain the required response?
A simple decision framework looks like this:
| Situation | Immediate response | Wider implication |
|---|---|---|
| A fix is available and can be applied | Test and deploy it according to the level of exposure and criticality | Strengthen the delivery process if remediation cannot happen quickly enough |
| A fix is available but the existing technology prevents it being applied | Upgrade dependencies, restore support or introduce temporary controls | Consider targeted modernisation to remove the underlying constraint |
| No established fix is available | Assess exposure, isolate or contain the system and work with vendors, maintainers or internal teams to identify a safe remediation | Build the technical capability and processes needed to respond to zero-day vulnerabilities |
| The system is unsupported and has no viable remediation route | Reduce exposure while deciding whether the system can remain operational | Treat it as a priority architectural, modernisation or retirement decision |
This is a Catapult CX decision framework rather than an NCSC methodology, but the principle is consistent. Prioritise the systems where exposure, operational impact and limited remediation options combine to create the greatest risk.
Replacement is not the only response.
Modernisation may mean retaining the system with stronger controls, upgrading constrained components, wrapping it, replatforming, migrating, refactoring or retiring technology that no longer justifies its cost and risk.
- For a deeper look at these options, see Catapult CX’s guide to legacy software modernisation versus replacement.
Seven Questions CIOs Should Answer Before the Patch Wave
The wrong time to discover that an organisation cannot investigate, contain or remediate a critical vulnerability is after one has been disclosed or is already being exploited.
CIOs do not need to launch a wholesale modernisation programme in response to the NCSC warning. They do need answers to seven questions.
1. Do we know which technologies and dependencies are in use?
Look below the application level at operating systems, databases, runtimes, libraries, frameworks, third-party components and infrastructure.
A system described internally as ‘supported’ may still contain outdated or unsupported dependencies. Without an accurate view of the technology estate, tools cannot reliably identify which systems are affected by a known CVE or where a newly discovered vulnerability may exist.
2. Can we manage known CVEs and zero-day vulnerabilities at the same time?
The processes are related but different.
Known CVEs can usually be assessed against published information and addressed through an available or forthcoming vendor update. A newly discovered zero-day may have no established fix, severity rating or remediation guidance.
Organisations need clear ownership, decision-making and escalation routes for both.
3. Which systems and components are exposed?
The NCSC recommends prioritising internet-facing and other externally exposed technology because vulnerabilities become more dangerous when affected assets are reachable and attackers can exploit them.
Map the external attack surface first, including what security controls surround each asset. Then work inwards according to business criticality and potential impact.
4. Can we test and deploy fixes safely at the required speed?
Finding or receiving a fix is not enough.
For software they control, organisations need robust continuous delivery pipelines that can test changes against applications and dependencies, apply the necessary approvals and deploy them consistently across multiple environments.
Identify where remediation is constrained by:
- limited or unreliable automated testing
- lengthy test execution
- manual release processes
- significant maintenance windows
- vendor involvement
- downstream application changes
- complex recovery requirements
- partial or complete operational shutdown
A slow or fragile delivery process can turn an available fix into an unresolved risk.
5. What happens when no established fix is available?
Organisations need response options beyond waiting for a vendor patch.
Depending on the vulnerability and affected system, these may include restricting access, isolating the asset, changing its configuration, applying temporary controls or developing a fix internally.
AI can help security and engineering teams analyse the vulnerability, identify possible mitigations and develop remediation more quickly. Any proposed change must still be validated and deployed safely.
6. Which suppliers or open-source dependencies could limit our response?
Understand where remediation depends on a vendor, maintainer or delivery partner and whether they have the capacity and processes to respond to a rapid increase in vulnerability disclosures.
The NCSC specifically advises larger organisations to seek assurance from both commercial and open-source supply chains.
7. Is technical debt being actively managed?
An inventory of technical debt is not enough. Organisations need a repeatable process for assessing its operational and security impact, assigning ownership and prioritising remediation.
CIOs should revisit modernisation decisions based on whether existing technology would delay or prevent an effective vulnerability response.
If vulnerabilities can be discovered and exploited more quickly, does the original decision to defer that work still hold?
Build the capability before vulnerability management becomes crisis management
Preparing for the vulnerability patch wave does not require a wholesale replacement programme.
It requires the ability to manage known CVEs and newly discovered vulnerabilities at the same time.
That means understanding the technology estate, identifying where the organisation is exposed and knowing which systems will constrain the response. It also means having the engineering capability to develop or identify fixes, robust delivery processes to test and deploy them safely and effective containment options when no immediate fix is available.
AI has a role on both sides. As these capabilities become more widely available, attackers will be able to use AI to discover and exploit vulnerabilities more quickly. Defenders can use it to analyse weaknesses, identify possible mitigations and accelerate remediation. But AI-generated fixes still need to be understood, tested and deployed through a controlled delivery process.
Technical-debt management is part of that capability. Unsupported components, fragile dependencies and poorly understood systems should be identified and addressed before they prevent the organisation from responding to a serious vulnerability.
That response capability spans security, architecture, engineering delivery and technical-debt management. Where legacy constraints weaken any part of it, modernisation becomes part of the security response.
Catapult CX’s Modernisation Readiness Review assesses complex systems to identify where technical constraints create the greatest operational and security risk. It establishes what can be retained, what needs attention and where investment will have the greatest impact.
From there, our Legacy Systems team can help prove and deliver the right intervention, whether that means stabilisation, targeted replacement, migration, Minimum Viable Replacement or incremental modernisation.
Know how you will respond before the next vulnerability decides for you.
Vulnerability Patch Wave FAQs
What is a vulnerability patch wave?
The NCSC uses the term to describe an expected surge in software security updates following the disclosure of newly discovered vulnerabilities. AI-assisted discovery could increase both the volume and speed of disclosures, requiring organisations to assess and remediate vulnerabilities more frequently and at greater scale.
What is the difference between a CVE and a zero-day vulnerability?
A CVE is a publicly recorded vulnerability with a standard identifier that security tools can use to identify affected technology. Remediation guidance or a vendor update may already be available or under development.
A zero-day is a previously unknown or newly disclosed vulnerability for which defenders have had little or no time to prepare. At the point of discovery, no established fix may be available.
Why is AI increasing vulnerability-management pressure?
AI can analyse large codebases and identify weaknesses much faster than traditional approaches. This increases the pressure on organisations to verify findings, assess their exposure, identify or develop remediation and deploy changes safely.
Attackers can also use AI to discover zero-day vulnerabilities and exploit known CVEs more quickly, reducing the time available to respond.
Can AI help organisations develop fixes?
Yes. AI can help security and engineering teams analyse vulnerable code, identify possible mitigations and develop potential fixes more quickly.
However, AI-generated recommendations and code still need human oversight, appropriate security review and thorough testing before deployment.
Can legacy systems always be patched?
No. Some end-of-life or unsupported technology can no longer receive security updates. In other cases, an update exists but cannot be applied until the underlying operating system, runtime, framework or other dependencies have been upgraded.
What should an organisation do when no established fix is available?
The response depends on the vulnerability, the system’s exposure and its importance to operations. Options can include isolating the asset, restricting access, changing its configuration, applying temporary controls, working with a vendor or maintainer, or developing a fix internally.
Longer-term action may involve upgrading, migrating, modernising, partially replacing or retiring the affected system.
How does technical debt affect vulnerability management?
Technical debt and vulnerability management are different disciplines, but they are closely connected operationally.
Unsupported components, fragile dependencies, limited automated testing and poorly understood systems can delay or prevent remediation. Without an established technical-debt management process, organisations may not discover these constraints until they need to respond to a serious vulnerability.
Why are continuous delivery pipelines important to vulnerability remediation?
Finding or developing a fix is not enough. Organisations must be able to test it against applications and dependencies, apply the necessary controls and deploy it safely across relevant environments.
Robust continuous delivery pipelines reduce the manual effort and risk involved, allowing validated fixes to reach production more quickly and consistently.
How should organisations prioritise remediation?
Start with vulnerabilities and systems presenting the greatest combination of external exposure, active exploitation, business impact and limited remediation options.
The NCSC recommends prioritising internet-facing technology when organisations cannot update everything at once. The UK Government’s legacy framework similarly considers both the likelihood and impact of system failure.
How can organisations prepare for the vulnerability patch wave?
Organisations should:
- maintain an accurate view of their technology and dependencies
- operate processes for both known CVEs and zero-day vulnerabilities
- map externally exposed and business-critical systems
- establish containment options for vulnerabilities without an immediate fix
- use AI appropriately to support analysis and remediation
- strengthen automated testing and continuous delivery pipelines
- actively identify and manage technical debt
- seek assurance from critical vendors, delivery partners and open-source maintainers
