AI implementation across OT (operational technology) and ICS (industrial control systems) environments is outpacing security measures that organizations have in place, despite most deployments remaining limited in scope and governance yet to catch up. Clearly, the question is no longer just whether AI can improve threat detection, predictive maintenance, or efficiency, but it now increasingly hovers around whether asset owners and operators can tell when the models and data behind those AI tools have been breached and then manipulated, and stop that compromise from reaching industrial processes.
Takepoint Research’s State of AI in OT Cybersecurity 2026 report discovered that 87.7% use AI in their OT cybersecurity efforts; however, only 7.9% have implemented AI for their OT security needs in all functionalities. The most pressing challenges include data quality (45.4%) and legacy integration (42.4%). In comparison, only 18.5% identified regulatory uncertainty as a major implementation challenge.
Confidence is thinner still, as close to two-thirds of respondents, 63.9%, consider attacks targeting AI systems or operational data either a top-tier operational risk (20.5%) or an emerging priority they are beginning to address (43.4%). Just over a third have controls against manipulation, adversarial inputs, or supply chain compromise. Only 7.6% are very confident because those controls have been tested.
Exposure is most likely to be found within organizational inputs. Industrial AI that powers operations uses sensor input and telemetry data. This was not designed to be protected against tampering by OT security systems. As a result, these operational sites can easily be manipulated and then exploited. This results in alerts being raised or wrong operational advice given. In December last year, U.S. cybersecurity agencies, along with their international partners, stated that manipulated data from AI, AI models, and the deployment of software can lead to results without any safety measures in place.
This comes as adversaries are already using AI to automate reconnaissance, generate polymorphic exploits, and poison the very models meant to automate the network. The same AI that automates and defends OT can be turned against it. Evidently, organizations must deploy AI behind a perimeter that ‘assumes the adversary has AI too.’
Detection is the harder test. A compromised model may trigger no conventional alert. Its effects can surface as odd equipment recommendations, unexplained process changes, or missed anomalies. That is a weak spot for many teams. Forescout’s 2025 benchmark, also run by Takepoint, found that nearly 60% of organizations report low to no confidence in their OT/IoT threat detection capabilities, while only 14% express high confidence; 57% of organizations deploy more than three separate tools to monitor IT, OT, and IoT environments, resulting in fragmented insights and elevated operational complexity.
Third parties tend to widen the gap, serving to increase the attack surface area, leading to increased exposure to cyberattacks and making it hard to detect, validate, and handle any incidents. Cloud, vendor-managed, external data pipeline, and software updates all sit beyond plant-visibility level.
Trust therefore takes more than accuracy testing. Operators require certified training and operational data, ongoing model monitoring, vendor responsibility, human intervention, and fail-safes. What really counts is that AI performs satisfactorily when it comes under attack.
Securing AI across industrial OT sites
Industrial Cyber reached out to industrial cybersecurity experts to look into what gives an industrial organization confidence, or concern, about its ability to secure AI systems used in OT environments.
Clint Bodungen, director of AI/ML engineering at Arcova, said that the concern comes from not thoroughly understanding the technology and how it might impact operations. “There is also a lot of misinformation out there about AI, regarding its capabilities as well as potential risks. It’s daunting to keep up with a technology that literally changes daily, and also filter through what is fact and what is exaggerated (or even outright false).”
“The confidence – or concern – industrial organizations feel regarding AI in Operational Technology (OT) stems from a fundamental reality: in OT, cyber risks directly manifest as physical risks to safety, reliability, and continuous operations,” Symonsen Acorroni, cyber IACS specialist at ERO, told Industrial Cyber. “The trust in the human factor is a ‘primary key.’”
He added that while IT security focuses heavily on data confidentiality and privacy, OT cybersecurity prioritizes Safety, Reliability, and Efficiency (SRE). Integrating AI introduces dynamic, probabilistic behavior into deterministic physical systems, which fundamentally alters the risk profile.
Confidence should come from governance and architecture, not model accuracy alone, Shaun Boggs, CTO at Cyber Eagle, told Industrial Cyber.
“Organizations should know what each model is, who trained it, what data it relies on, where it runs, what it can influence, and how changes in behavior would be detected,” he added. “They should also be able to verify provenance and roll back to a known-good version. AI should generally remain advisory unless deliberately engineered for greater authority, while safety systems and protective interlocks remain independent. The biggest concern is incomplete inventory and data lineage.”
Recognizing AI compromise before OT disruption
The executives address how a manipulated or compromised AI model could manifest in OT/ICS operations before being identified as a cybersecurity threat.
“The same way any cyber threat would,” Bodungen said. “Systems could start operating outside of intended parameters, unauthorized activity, etc.”
Acorroni identified that a compromised or manipulated AI model is unlikely to manifest as an obvious cyberattack at first. “Operationally, it will masquerade as a process inefficiency or instrument failure. If a sensor signal is subtly corrupted, manipulated, or out of calibration at Level 1, the AI model will make decisions that are perfectly ‘logical’ from a mathematical standpoint, yet entirely detached from the physical reality of the plant – a classic ‘Garbage In, Garbage Out’ scenario.”
He added that the model subtly adjusts process variables (pressure, temperature, flow rate) while remaining within SCADA (supervisory control and data acquisition) alarm limits, yet causes premature asset wear, loss of efficiency, or reduced product quality.
“A compromised AI model may first look like an operations problem rather than a cyber incident. A maintenance model might miss degrading equipment, an optimizer could slowly push setpoints toward harmful conditions, or an anomaly detector could become less sensitive or generate enough false positives to lose operator trust,” Boggs detailed. “Because those symptoms can also result from drift, sensor faults, process changes or bugs, they may never reach the SOC. Warning signs include more operator overrides, disagreement with independent sensors or physics, and unexplained changes in yield, energy use, or maintenance patterns.”
Industrial AI faces emerging attack vectors
The executives examine the AI attack vectors that pose greatest risks to industrial operators, including data poisoning, model manipulation, and adversarial inputs.
Bodungen mentioned that indirect prompt injection is going to be the most common vector. “This would be malicious ‘prompt’ instructions hidden in documents, websites, and even images. Model poisoning can be a concern if they are using local models obtained from sources like Hugging Face. Direct prompt injection is a concern where they have exposed user input fields.”
“From my perspective, the primary concern is triggering unsafe physical decisions within the plant,” according to Acorroni. “The human factor is a critical initial vector—such as a lack of operator training to detect anomalous AI decisions—as is model tampering stemming from supply chain risks (e.g., previously compromised third-party algorithms) or the compromise of sensor firmware or hardware. A ‘cyber-informed engineering’ or ‘security by design’ approach should be mandatory.”
Boggs said that the most practical risk is manipulation of the data a model trusts. “Attackers can spoof or replay telemetry, and low-and-slow poisoning can gradually shift what a retrained model considers normal.”
He added that “Supply-chain risk also matters: vendor updates, pretrained weights, dependencies and unsafe model-loading mechanisms should be treated like software inputs. LLM-based assistants add prompt-injection risk, especially when they can invoke tools or influence workflows. Adversarial examples remain relevant, but in OT, compromising trusted data paths may often be easier than attacking the model mathematically.”
Are OT teams ready to detect AI attacks?
The executives assess how prepared are OT security teams to detect attacks targeting AI models, operational data, or AI-driven workflows.
“From what I have seen, virtually nobody seems prepared yet. Not effectively, anyway,” Bodungen evaluated. “The technology moves so fast, changing weekly or even daily. Just keeping up with everything, let alone implementing detection and mitigation, can essentially be a full-time job.”
Analyzing that the honest answer is that the entire industry is still searching for that answer, Acorroni said that artificial intelligence technology is growing at an exponential rate, while cyber OT teams are still working hard – quite hard – to deliver a secure baseline featuring remote access controls, identity management, risk analysis, and incident response plans.
He added that this isn’t criticism, but a pragmatic observation of market maturity.
“AI-specific detection maturity in OT is still early. Traditional OT monitoring is strong at asset visibility, communications, and anomalous network behavior, but it may not determine whether a model’s interpretation of the physical process is trustworthy,” Boggs determined. “Organizations need telemetry on model versions, inputs, outputs and behavior changes, plus clear ownership across security, engineering, data science and vendors.”
He added that preparation should include cross-checking model outputs against physics and independent instrumentation, treating model behavior as a security signal, and using joint incident-response playbooks rather than simply retraining a suspicious model.
Building trust in industrial AI models
The executives look into what controls, testing, or validation processes are needed to establish trust in AI models and the data feeding them.
“First and foremost, you need to know and understand the technology, the capabilities, the risks, and the attack vectors. And I hate to say it, but you also need AI to fight AI threats, in many cases,” Bodungen said. “Governance alone is not enough. You need a technology that is as fast as the threat. From there, we go back to basic OT blocking and tackling. Treat AI as an untrusted vendor, utilize your DMZ and test and development labs, manage trust and access, make it part of your change process, engage HSE, and treat it as a hazard.”
At the end of the day, he suggests using AI as an advisor and to augment staff. Generative AI should not be given operational control or allowed to make changes.
Acorroni mentioned that security must be approached as physical engineering: continuous sensor calibration checks, out-of-bounds filtering, and cross-sensor validation prevent Level 1 data poisoning.
He added that a cyber-informed engineering approach/security-by-design ensures deterministic safety instrumented systems (SIS) and mechanical interlocks operate independently of AI logic and, last but not least, that AI governance and human-in-the-loop restrict AI to decision support with supervision, confined within strict zones and conduits.
“Treat consequential AI changes like management of change. Maintain an inventory or AI bill of materials covering model version, provenance, training-data lineage, dependencies, access and decision authority,” Boggs said. “Validate inputs using physics, process invariants and independent instrumentation; protect model and data provenance with hashes, signed releases and tamper-evident records. Test models in shadow mode or simulation against faults, poisoning, evasion and connectivity loss.”
He added to monitor drift, overrides and configuration changes at runtime, and maintain a tested rollback to a known-good version. NIST AI RMF, MITRE ATLAS, IEC 62443 and IEC 61511 provide useful guidance.
Industrial AI dependencies expand attack surfaces
The executives focus on blind spots introduced when industrial AI systems rely on third-party data pipelines, cloud services, vendor-managed models, or external updates.
“I don’t see this as being much different than those introduced by any other third-party vendors and cloud environments,” Bodungen said. “This is why SBOM’s are so important. And, of course, education about the technology.”
Acorroni said that addressing these blind spots requires shifting from cloud convenience to delivering a secure, resilient OT environment. “Third-party pipelines and cloud ETL obscure raw Level 1 signals, masking sensor tampering and making data poisoning untraceable. Persistent cloud dependencies erode ISA 95/Purdue model boundaries via unmonitored reverse conduits into Level 2/3 networks.”
He added that vendor updates also risk pushing unverified logic without local hardware-in-the-loop (HIL) validation. “To ensure an uncompromised plant, organizations must prevent knowledge leakage and preserve data integrity by favoring secure solutions that keep operational intelligence strictly within the business.”
“Third-party AI can create gaps in accountability, visibility, and resilience,” according to Boggs. “Operators may have limited insight into training data, model changes or validation, while vendor-managed or fleet-trained models can create correlated risk across many sites. Cloud inference also creates an OT trust-boundary and availability dependency, so degraded or disconnected behavior must be designed in advance. Detailed telemetry can expose intellectual property and useful reconnaissance.”
He concluded that procurement should address provenance, change notification, version control, rollback, assurance, incident reporting, data ownership, tenant isolation, and local or deterministic fallback where consequences justify it.
The post Industrial AI adoption outpaces security readiness, leaving OT environments exposed to emerging threats appeared first on Industrial Cyber.
