LLMs in OT Security: Translation Layer, Not Detection Layer

Dr. Rishabh Das

Critical Infrastructure Cybersecurity researcher at Assistant Professor, Ohio University || Web

Dr. Rishabh Das is an Assistant Professor at the Scripps College of Communication, Ohio University. Dr. Das has over a decade of hands-on experience in operating, troubleshooting, and supervising control systems in the oil and gas industry. Dr Das's research portfolio includes virtualization of Industrial Control Systems (ICS), threat modeling, penetration testing in ICS, active network monitoring, and the application of Machine Learning (ML) in cybersecurity.

If you have sat in a vendor briefing in the last eighteen months, you have heard the pitch: 

“AI-powered threat detection.” 

“AI-driven SOC.” 

“AI for OT security.” 

This implies that artificial intelligence is an entirely new asset that can be added to the defender’s toolkit. It isn’t. 

Machine learning has been quietly doing the heavy lifting in cybersecurity for well over a decade. In OT security, LLMs function best as a translation and synthesis layer that helps humans interpret existing detections faster. It’s been used to flag anomalous logins, score lateral movement, baseline process variables on a control network, and catch the long tail of attacks that no signature was ever written for. User and Entity Behavior Analytics (UEBA), statistical process control on historian data, autoencoder-based network anomaly detection, and supervised classifiers in endpoint agents are all “AI.” None of them are new. 

What is actually new in LLMs in OT security is not the detection math itself, but the language layer the models add on top. LLMs are not a faster version of the anomaly detectors defenders already run. Rather, they are an additional layer on top of already existing detection stacks that have the ability to understand, synthesize, and generate language.

The most interesting question in today’s cybersecurity landscape is not “will AI change defensive security.” It already has. The real question is what an LLM adds on top of two decades of statistical and behavioral ML, layer by layer, across the architecture defenders actually operate: the Purdue Enterprise Reference Architecture.

Walking the stack

Level 0/1 – Physical Process and Basic Control. These are sensors, actuators, PLCs, and RTUs talking Modbus, DNP3, or EtherNet/IP. Existing machine learning here is physics-aware residual-based anomaly detection, which compares expected versus observed process behavior and statistical deviation models on sensor streams. None of that involves language. What an LLM adds is interpretability and access. 

A control engineer can now ask, in plain language, “Why did the model flag pump 3’s pressure curve at 02:14?” and get a synthesized explanation pulled from the residual model’s output, plus the relevant IEC 61131-3 logic, instead of a data scientist translating complex mathematical outputs. LLMs are also proving useful for static review of ladder logic and structured text, flagging logic bombs or unauthorized timer manipulations that a signature-based check would miss.

Level 2 – Supervisory Control (HMI/SCADA). Operator behavior baselining and alarm-flood statistics are an integral part of the operational technology stack. Even non-security stack software uses these alarm statistics to guide operators and drive business decisions.  

The LLM enables alarm rationalization at scale. During a cascading event generating hundreds of alarms per minute, an LLM can cluster and summarize the flood into a coherent narrative for the operator in real time, something rule-based alarm management systems have never done well.

Level 3 -Operations Management (Historians, MES). Time-series anomaly detection, such as Long Short Term Memory (LSTMs), isolation forests, and autoencoders on historian tags, has been standard for years. 

LLMs add a query and synthesis layer on top. An analyst can now ask, “Has this vibration signature occurred before, and what was the root cause?” instead of writing a SQL query against a tag database. The answer they receive will be retrieval-augmented generation based on historian data, maintenance logs, and engineering change records.

Level 3.5 – Industrial DMZ. Network IDS tools like Suricata and Zeek have used ML-augmented protocol anomaly detection for ICS protocols for a long time. 

The LLM enhancement here is analyst-facing. It enables the generation of a Zeek connection log summary or a Suricata alert chain as a plain-language narrative, auto-enriching IOCs against threat intel, and drafting the first pass of an incident timeline. This work used to consume the first hour of an analyst’s triage but will now be vastly accelerated by LLMs.

Level 4/5 – Business Logistics and Enterprise IT. This is the most mature layer of PERA, and the cybersecurity industry has many large-scale solutions that collect, interpret, and provide incident insights at scale. This layer also has the largest amount of available compute.  Many of the available and widely-used solutions include SIEM correlation, SOAR playbooks, EDR classifiers, and phishing-detection models, all of which have run on supervised and unsupervised ML for fifteen years. 

Here, LLMs function as the orchestration and translation layer, converting a natural-language threat hunting question into a Sigma or KQL query, drafting SOAR playbook logic, auto-generating incident reports from raw log excerpts, and giving Tier 1analysts something close to Tier 3 reasoning support on their first pass through an alert queue.

LLMs in OT Security Across the Purdue Model

The detection math at each layer was already AI, the LLM adds the translation and synthesis layer on top of it.

Across every Purdue layer, the pattern remains the consistent: the detection math, or the part that decides something is anomalous, was already AI that stays in place. The LLM builds a bridge between a model’s output and a human’s understanding of it through translation based on common language.

That’s not a trivial addition. The mean-time-to-triage in a SOC is due less to detection latency than to the time an analyst spends reading logs, correlating context, and writing up what happened. Compressing that last step is a genuine force multiplier. This is particularly true at Level 0-3, where OT engineers are rarely trained as SOC analysts, and the gap between “the model flagged it” and “I understand why” has historically been where incidents go stale.

The risk is treating the LLM as a replacement for the detection layer rather than a complement to it. An LLM has no privileged access to ground truth about a control system’s physical state and only reason based on what the detection models and logs already tell them. 

Defensive security across the Purdue stack is not being reinvented by LLMs in OT security. But it is being made legible, faster to act on, and more accessible to the people standing closest to the process. That’s a meaningful acceleration that will help defenders across all layers.