Cyber security | 05 November 2026
AI and OT Security: Are Industrial Operators Ready?
Published by Asset Guardian
The NCSC expects AI to speed up how quickly vulnerabilities are found and exploited, but industrial systems can’t always be patched at the same pace. This article looks at what that means for legacy equipment, risk decisions made years ago and recovery, and ends with a short exercise to test one critical system.
AI and OT Security: Are Industrial Operators Ready?
On 3 November 2026, the UK's National Cyber Security Centre (NCSC) warned that AI-powered malware is highly likely to feature in a ransomware attack against UK critical national infrastructure by 2028. Its latest assessment also suggests that AI will accelerate vulnerability discovery and exploitation, potentially reducing the time organisations have to respond.
For industrial operators, this raises a difficult question: what happens when vulnerabilities can be discovered and exploited faster than industrial systems can safely be updated?
Engineering assessments, vendor approvals, compatibility testing and planned shutdowns are often necessary before changes can be made to operational technology (OT). Some systems depend on software that is no longer supported, while others cannot be patched without significant operational disruption.
These constraints are familiar to OT teams. What may be changing is the time available to manage the risks around them.
What changes when attackers move faster?
One of the most significant points in the NCSC's assessment is that AI is expected to accelerate existing cyber attack methods rather than necessarily introduce entirely new ones. AI can assist with reconnaissance, software analysis, vulnerability discovery and exploit development, allowing certain activities to be carried out faster and potentially at greater scale. The NCSC also acknowledges that these capabilities are developing unevenly. AI does not automatically turn an inexperienced attacker into an expert, and human involvement remains important.
Nevertheless, even a reduction in the time required to identify and exploit vulnerabilities could have significant implications for industrial environments.
Consider a newly disclosed vulnerability affecting engineering software used to maintain a production control system. In a conventional IT environment, the response might involve identifying affected machines, testing an update and deploying it across the network. For an OT operator, the process can be much more involved. The affected software may only be compatible with a particular operating system, the equipment manufacturer may need to approve changes, testing may require a representative control system, and installation may need to wait until the next scheduled shutdown. An update that can be deployed to an office workstation in hours might take weeks or months to implement safely in an industrial environment.
That difference already exists, but the concern is that AI-assisted vulnerability discovery and exploitation could make it more consequential.
If attackers can develop working exploits more quickly, operators may have less time to assess their exposure and establish effective protection while permanent remediation is being prepared.
Are previously accepted OT cyber risks still acceptable?
Industrial equipment is often designed to remain operational for decades. As a result, organisations may depend on older operating systems, proprietary technologies or software that is no longer supported by its original supplier.
These systems do not automatically become more vulnerable because AI exists. Their risk still depends on factors such as network exposure, available vulnerabilities, access controls and the consequences of compromise.
However, AI could change how easily certain weaknesses can be discovered or exploited.
The NCSC’s chief executive framed it in similar terms: the concern is not that AI has invented new ways to attack, but that vulnerabilities tolerated for too long can now be found and exploited at far greater scale. The NCSC’s earlier guidance on a coming ‘patch wave’ adds that patching alone will not always be enough, because some technical debt sits in legacy technology that is out of support and cannot receive updates.
Consider an unsupported engineering workstation that has remained in service because replacing it would require substantial modifications to the wider control system. The organisation may have previously assessed the risk and concluded that existing protections were sufficient. Perhaps the workstation is restricted to a dedicated network segment, with controlled access and limited external connectivity. That may still be an entirely reasonable decision.
But what assumptions supported the original assessment?
Was the risk considered acceptable because exploitation required specialist knowledge? Because no working exploit was publicly available? Or because the workstation was sufficiently isolated from other networks?
If AI makes a previously difficult vulnerability easier to exploit, could a risk decision made several years ago become outdated even though nothing about the equipment itself has changed? That is worth examining.
An unsupported workstation within a properly controlled industrial network presents a different risk from an identical workstation accessible through poorly secured remote connections. Both may contain the same vulnerabilities, but their exposure and the opportunities available to an attacker differ considerably.
For operators, this means understanding why a vulnerability remains unresolved, what compensating controls are in place and when those arrangements were last reviewed. Network segmentation, restricted remote access, monitoring and limits on privileged accounts may all help manage vulnerabilities that cannot be patched. Their effectiveness, however, depends on the individual system and its operational requirements.
Introducing additional controls also requires care. A hastily implemented security measure that interrupts a critical industrial process can create problems of its own.
Organisations with long-standing OT vulnerabilities may also want to look at when their risk assessments are revisited. A vulnerability might remain unresolved for years, with the original decision based partly on the difficulty of exploitation. If credible threat intelligence suggests that exploitation has become easier, should that trigger a reassessment rather than waiting for the next scheduled review? The equipment may be unchanged, but the assumptions supporting the original decision may no longer hold.
Preparing before the next vulnerability is disclosed
Traditional vulnerability management often begins with a security advisory.
A vendor announces a vulnerability, the organisation determines whether it uses the affected product, and the relevant teams assess the risk and decide what action is necessary.
That process remains important, but it can be slow where software inventories are incomplete or information is spread across multiple sites.
If AI reduces the time between vulnerability discovery and exploitation, operators may need to complete more of the preparation before an advisory is published.
Consider two industrial sites running the same vulnerable engineering software. At the first site, the engineering team has an accurate software inventory, knows which controllers the workstation can access and has documented the relevant network restrictions.
At the second, the software version must be confirmed manually, configuration records are held by a contractor and nobody is immediately certain which controllers could be affected.
Both sites face the same vulnerability, but the second has far more work to complete before it can make an informed decision.
This is where the quality of OT asset and configuration information becomes important. Knowing which software versions are installed, where they are running and which systems they support allows teams to assess exposure more quickly. It also helps them distinguish between vulnerabilities that require urgent attention and those where existing protections may be sufficient.
A severity score alone cannot establish operational risk. Operators need to consider exploitability, network exposure, asset criticality and the potential consequences of remediation. As AI capabilities develop, previously accepted assumptions about exploit difficulty may need to be reconsidered. For systems that cannot be patched quickly, organisations should also understand which temporary protections could be introduced if a serious vulnerability emerges.
Could remote maintenance access be restricted? Could unnecessary connections be removed? Could additional monitoring be introduced without affecting normal operations?
These decisions may still require engineering approval, but identifying the available options in advance can reduce delays when a vulnerability is disclosed. The objective is to spend less time establishing what is affected and more time making informed decisions about the response.
Could AI-enabled attacks complicate recovery?
The NCSC's warning about ransomware affecting critical national infrastructure also raises questions about how industrial organisations would recover from a successful attack. Ransomware incidents are often discussed in terms of encrypted files, unavailable servers and disrupted business systems. In industrial environments, recovery can involve additional complications.
Engineering workstations may contain controller project files, configuration data, specialist software and licensing information required to maintain production equipment. If those systems are compromised, restoring the workstation itself may only be the beginning.
There is also the possibility of an attacker gaining sufficient access to make unauthorised changes to industrial configurations. This is a separate scenario from a conventional ransomware incident, but it illustrates why recovery requires confidence in the integrity of the information being restored.
Consider an attacker who modifies a controller configuration without authorisation. The change may not be immediately obvious, particularly if the controller continues operating. When the incident is discovered, engineers need to determine what has changed and which configuration can be trusted. The most recent backup is not necessarily the correct one to restore. If it was created after the unauthorised modification, it may contain the same compromised configuration.
A reliable recovery process therefore requires more than a collection of backup files. Engineers need to identify the last approved version, examine the change history and establish whether the configuration is suitable for restoring the system. Depending on the circumstances, this may involve comparing controller configurations with approved engineering records, validating application logic and carrying out additional testing before equipment is returned to service. These activities take time and require appropriate technical expertise.
AI may help attackers conduct certain activities more efficiently, but it does not remove the engineering work required to verify that an industrial system is safe to operate following an incident.
For operators, that makes the quality of configuration records, approved backups and recovery procedures particularly important.
It also raises a practical question: could the organisation restore a critical system if the corporate network were unavailable or the engineer who normally manages it could not be reached?
Recovery arrangements should account for those dependencies before an incident occurs.
What about AI for OT cyber defence?
AI also presents opportunities for organisations defending industrial environments. AI and machine learning already support activities such as anomaly detection, event analysis and identifying suspicious behaviour. Further developments may help security teams analyse larger volumes of information and prioritise vulnerabilities more efficiently.
However, industrial environments introduce particular challenges for automated decision-making.
An unexpected change in network traffic may indicate malicious activity, but it could also result from legitimate maintenance, commissioning or an operational change. Likewise, automatically isolating a suspicious device might prevent an attack from spreading, but could have serious consequences if that device supports a critical industrial process.
Any use of AI-assisted security tools in OT therefore needs to account for the operational function of the affected equipment.
There is also the question of information quality. An AI system analysing vulnerability data cannot reliably assess the operational importance of an asset if the underlying records are inaccurate or incomplete. Similarly, a security tool may detect a configuration change without knowing whether it was authorised. AI can assist with analysis, but organisations still need reliable asset information, established change procedures and engineers who understand the systems involved.
As AI becomes more widely used in cyber defence, the accuracy and availability of that underlying operational information will remain essential.
What should industrial operators reconsider now?
The NCSC's assessment is a warning about how cyber threats are expected to develop. It does not mean every industrial organisation is already facing autonomous AI-powered attacks.
It does, however, provide a reason to examine whether existing security arrangements can respond quickly enough to emerging risks.
One useful exercise would be to select a critical industrial system that contains a known vulnerability or relies on unsupported software.
- Start by reviewing the original decision to keep that system in service. Why was the risk accepted? Was the decision based on limited network exposure, the absence of a known exploit or the difficulty of applying a patch?
- Then consider whether those assumptions remain valid. Could changes in attacker capabilities affect the likelihood of exploitation? Are existing compensating controls still appropriate When were they last reviewed?
- Next, imagine that a serious new vulnerability affecting the system's engineering software is disclosed tomorrow. How quickly could the organisation establish whether it is affected? Would engineers know which software versions are installed and which controllers could be accessed from the affected workstation? If patching were not immediately possible, could the available compensating controls be confirmed and strengthened safely?
- Finally, consider recovery. Could the team identify unauthorised configuration changes, locate the last trusted and approved version, and restore the necessary engineering environment?
These questions can reveal weaknesses without requiring organisations to predict exactly how AI-enabled attacks will develop. They also help distinguish between delays that are unavoidable and those that can be addressed.
Engineering validation, vendor approval and maintenance windows may remain necessary. Time lost searching for software records, confirming configuration versions or locating recovery files is something organisations can work to reduce.
Preparing for the next stage of OT cyber security
The NCSC's warning gives industrial operators a reason to look again at how quickly they could respond to a serious vulnerability. Most OT teams already know which systems are difficult to patch and which will remain in service for years. The question is whether the risks associated with those systems are still being managed on the basis of up-to-date information.
The practical response is to examine where unnecessary delays can be reduced while maintaining the controls required for safe operation. Asset Guardian supports industrial organisations through centralised OT software and configuration information, vulnerability and obsolescence visibility, controlled change histories and backup management.
If a serious vulnerability affected one of your critical control systems tomorrow, how much of your response time would be spent managing the risk, and how much would be spent trying to establish what you actually have?
How prepared is your OT environment?
Asset Guardian helps industrial operators maintain visibility of their OT software, configurations, vulnerabilities and change histories, with controlled backups to support recovery when it matters.
Explore how Asset Guardian supports OT cyber security >
