AI in ICS/OT Cybersecurity: Adopting AI with Safety Top of Mind (Part 2)

In part 1 of this series on ICS/OT and AI, ICS/OT Cybersecurity and AI: Considerations for Now and the Future, we explored where AI may provide value in industrial environments while keeping engineering and human expertise in the lead.

The key takeaway from Part 1 is that AI should augment, not replace, experienced ICS/OT security and engineering teams. Potential use cases include threat and anomaly detection, vulnerability prioritization, predictive engineering asset maintenance, and overall engineering process optimization.

We also highlighted that leaders responsible for ICS/OT cybersecurity and risk management should prioritize the SANS Five ICS Cybersecurity Critical Controls as rapidly as possible, first. Then leaders should consider how AI will be sourced, deployed, monitored, secured, and maintained for engineering assistance.

In Part 2, we’ll build on that foundation and explore how AI can be introduced safely — through a practical engineering use case, and as a risk that is managed to assist engineering, maintaining engineering as the leaders, not AI.

AI, Leadership, and Adapting New Tech

When I teach ICS418: ICS Security Essentials for Leaders, we cover the differences between IT and ICS/OT, as well as incident response, building the right teams, and prioritizing specific and realistic ICS/OT controls to manage unique operational cyber risks.

Also, through our in-class discussions and a leadership level lab we focus on adapting to emerging technology. Today that discussion increasingly centers on AI: how it is being used, how adversaries may use it, and where it can responsibly support engineering, ICS/OT security, and critical infrastructure protection.

The figure being presented above (and shown in detail below) is one way we frame AI adoption in the ICS418 leadership lab to consider realistic AI deployment states so leaders can prepare for both opportunity and risk. Now that AI adoption and improvements and updates to its accuracy are being made at a rapid pace, the timeframe may as soon as 3, 6, or 8 months out from a planning perspective.

Today, industrial organizations — power utilities, water management plants, manufacturing plant floors, and more critical infrastructure sectors — face increasing pressure to use AI for engineering productivity, predictive maintenance, cybersecurity advancements, and operational efficiency. Before adoption, leaders should first understand the problem AI is intended to solve, what data it requires, what the system connectivity risk is, and how AI can or should be used securely to reduce risk rather than introduce risk. Additionally, the operational impact or production and safety of an incorrect output used from an AI instance must be top of mind.

Referencing the figure below, the desired state should never just be “more AI” in this case, nor “more of that new technology.” Over the next 12–24 months, or on an even shorter timeframe like 3–6 months, AI can be deliberately phased into established mature workflows where it provides measurable value without unnecessarily increasing safety or operational risk.

Expanding an Engineering AI Use Case

Nearly every industrial sector relies on equipment that degrades, requires inspection, and follows scheduled maintenance. Pumps, motors, compressors, turbines, transformers, valves, and drives all change as components wear and operating conditions shift. This makes predictive maintenance one of the most practical industrial use cases for AI. AI can augment traditional schedules, OEM guidance, condition monitoring, alarms, and engineering experience by rapidly analyzing large operational datasets for patterns that may otherwise be difficult to detect for just manual process and physical engineering inspection alone.

Consider a fleet of industrial pumps and motors in oil and gas, water management, etc. A facility may already collect data on vibration, bearing temperature, motor current, pressure, flow, runtime, starts/stops, maintenance history, and engineering alarms. A private AI model could analyze these time-series datasets, equipment models, and operating conditions, including the OEM maintenance guidance to establish a baseline of normal operations.

For vibration monitoring, for example, changes in frequencies, harmonics, etc., could mean imminent imbalance, misalignment, or bearing degradation that could lead to faults and safety concerns. With AI augmenting existing monitoring programs, it could help engineering staff make decisions proactively before faults occur. But today, AI should generally inform, not control, engineering operations. Engineers and maintenance teams should validate AI recommendations against process conditions, physical inspection, measurements, maintenance history, and OEM guidance before acting.

System architecture matters more now than ever inside a control system network. AI platforms may not require direct access to a control system; data can instead be provided from historians, replicated sources, or controlled secure connections or interfaces, keeping AI isolated from the core control system networks.

Predictive Maintenance and Managing AI Potential States

Referring to the figure above from ICS418, in Potential 1, organizations can use a closed, private AI instance with historical engineering data to measure accuracy and false positives and negatives, and to establish how engineers will validate recommendations through operational data and physical inspection.

In Potential 2, we know AI is already arriving through OEMs, vendors, cloud platforms, maintenance tools, and internal teams. Leadership needs to understand what data is used, where it is processed, who has access, and whether the platform creates connectivity between IT, the Internet, and OT engineering systems.

In Potential 3, attackers can poison AI models and data (or connected systems!), manipulate sensor or historian inputs, exploit prompt injection, or alter configurations to create false maintenance alerts or hide real equipment degradation. This reinforces why engineering personnel and physical inspection must remain authoritative and always in the loop.

Overall, one could make the case for protecting the full decision chain on AI being adopted into ICS/OT environment as follows:

Sensor/data → PLC/RTU → control network → historian/data platform → AI model → recommendation → engineer

ICS/OT cybersecurity here should start with the Five ICS Cybersecurity Critical Controls and extend to least privilege, data protection, logging, integrity monitoring, and read-only or one-way data flows where possible. AI models also require ongoing validation as equipment, processes, and operating ranges change.

Main Takeaways

AI is already moving into ICS/OT through engineering teams, vendors, and OEM technologies.

1. Deploy the Five ICS Cybersecurity Critical Controls, first.
2. Then use AI to augment, not replace, engineering decisions or resources.
3. Protect the data, models, and decision chain, keeping AI outside the control network as feasible, without action privileges, not connected to ICS/OT assets/networks.

The goal is not AI adoption everywhere just because it’s new and can have some benefits. Mature organizations and facilities are using it to fix the right problems, at the right time, with the right safeguards, in the right order of maturity, and with engineering in the lead.

In Part 3, we’ll explore additional practical ICS/OT AI use cases and the risks that come with them.

Join me in class as I teach ICS418: ICS Security Essentials for Leaders in January 2027 at the SANS Stay Sharp Event, LIVE ONLINE, and stay tuned for Part 3 coming soon!