For thirty years we told you industrial cybersecurity was fundamentally different from IT cybersecurity. We were right. Then AI made us wrong, and it didn’t bother sending a memo.
By Matt Morris, VP of Security & Resilience, EverLine
If I had a dollar for every time I’ve explained to an IT security professional why OT/ICS cybersecurity is different, I could fund a respectable OT security program. Probably with money left over for better coffee in the SOC.
The explanation always went the same way. IT security protects data. When enterprise systems get hit, you lose records, you lose money, you take reputational damage, you have a rough quarter. Serious, and usually recoverable. OT and ICS security protects physical processes. The electricity moving through a substation. The pressure in a distribution main. The temperature in a reactor. When those fail, or when somebody forces them to fail, you’re not talking about a rough quarter.
That distinction was real, and it’s the whole reason this field was hard. OT practitioners were never just cyber people. We were part control engineer, part safety professional, part defender, working in environments where a routine patch could take a process offline and a well intentioned network scan could physically damage equipment. When I described it as the carpeted space versus the uncarpeted space, that wasn’t a rhetorical flourish. It was an accurate description of two worlds that happened to share a few acronyms.
I want to state something plainly, because I haven’t seen anyone put it this directly yet. That distinction is collapsing. AI is doing it. It happened gradually and then quickly, and most of the industry is still building programs, teams and budgets as though the two worlds remain separate.
I call the mechanism Model-Borne Consequence. Physical harm delivered through the data and model layer rather than the control layer. It’s new, it’s measurable, and almost nobody is watching for it.
“Model-Borne Consequence: physical harm delivered through the data and model layer rather than the control layer. The attack surface is data. The outcome is physical.”
How different these worlds actually were
You have to respect how genuinely separate these disciplines were, because those differences still shape how organizations hire, budget and govern today.
Traditional OT was built on three things IT security has never had to accommodate: long lifecycle, operational continuity, and physical consequence. A programmable logic controller is designed to run twenty years or more. Your enterprise endpoint refresh cycle is three to five years, and even that feels slow. PLCs don’t get refreshed. They get calibrated to a specific physical environment and then left alone, because the operational risk of touching them usually exceeds the security risk of not touching them.
The security model that grew out of that reality was physical isolation, network segmentation and operational discipline. The Purdue Model, which every ICS practitioner has effectively memorized, formalized the separation between the process world and the data world.[1] Keep control systems away from enterprise IT. Keep enterprise IT away from the internet. Treat physical access as the primary perimeter.
Stuxnet was the proof that this had limits. Discovered in 2010, it was the first known instance of a digital attack manifesting itself as a physical outcome. It crossed air gaps through USB media, embedded itself in Siemens S7 PLCs at Natanz, and drove centrifuges past their safe rotor speeds while feeding operators falsified all-normal readings.[2] In a dark way it was a masterpiece, because it understood that OT attacks are about physical process manipulation rather than data theft. The weapon was the gap between what the system appeared to be doing and what it was actually doing.
BlackEnergy against the Ukrainian grid in 2015, where attackers harvested credentials, pivoted into SCADA and remotely tripped breakers at more than thirty substations.[3] Triton in 2017, built specifically to defeat safety instrumented systems. PIPEDREAM in 2022, the most capable ICS attack framework ever publicly documented, able to scan for and reprogram controllers from multiple vendors out of the box.[4] Every one of them built on the same insight Stuxnet demonstrated. Attack the physical process, not the data about it.
Data security and process security were different problems. We were right to insist on it.
Then AI showed up in the uncarpeted space
AI has moved from something operators were exploring to something actively embedded in operational environments, usually without a clear decision point and frequently without governance that matches what’s actually happening. Predictive maintenance models forecasting equipment failure. Anomaly detection flagging deviation from normal process behavior. Optimization engines managing energy dispatch, chemical processing and water distribution.
In December 2025, CISA published joint guidance with the NSA, FBI and cyber agencies from Australia, Canada, the UK, Germany, the Netherlands and New Zealand on secure integration of AI in operational technology.[5] The document names a set of OT failure modes that had no place in traditional OT frameworks: model drift, data poisoning, prompt injection and limited explainability. It’s blunt about the stakes, warning that LLM based systems almost certainly should not be used to make safety decisions in OT environments.[5]
Read that list again. Model drift. Data poisoning. Prompt injection.
Those are data security concepts, and they’re now named operational technology risks in joint guidance from nine national cyber authorities. Stated differently, the presence of these vectors are not just a trend. They represent the boundary moving in an official document.
Meanwhile the underlying exposure keeps widening. Forescout logged 508 ICS advisories covering 2,155 vulnerabilities in 2025, the highest volume since tracking began, with 82 percent rated high or critical.[6] SANS found 19 percent of organizations reported at least one OT security incident in a single year.[7] And roughly half of manufacturing leaders surveyed planned to deploy AI or machine learning for cybersecurity within twelve months,[8] which adds fresh model surface to environments still working through OT security fundamentals.
The mechanism, precisely
Precision matters here, because it’s the difference between nodding at an idea and acting on it.
Traditional OT was deterministic. A PLC follows programmed logic. If pressure exceeds threshold, close valve. The security question was whether that logic had been tampered with, which is a process integrity question managed through access control, segmentation and change management. Sensor data fed the logic, but the logic itself was static, auditable, and independent of any ongoing data relationship.
An AI system making operational decisions is architecturally different. Its behavior is a function of training data, model weights and the live data it receives. Compromise the training data and you compromise behavior. Compromise the live sensor feed and you compromise output. Let the model drift as conditions change with nobody watching, and you get a system confidently recommending actions based on a physical reality that no longer exists.
A pipeline running AI anomaly detection on subtly manipulated pressure data will generate wrong alerts, or worse, fail to generate the right ones. A treatment plant whose optimization model was trained on poisoned data will recommend incorrect chemical dosing. A grid operator running AI assisted load balancing through a model that drifted after a generation mix change may push dispatch that works against frequency stability. None of these are hypothetical attack classes; they map directly to documented AI failure modes.[9]
In every one of those, the attack surface is data and the consequence is physical. That’s Model-Borne Consequence, and defending against it requires both disciplines at once, because the system under attack is itself integrated.
The conclusion most people are going to get wrong
Here’s where I expect the market to draw exactly the wrong lesson, and I’d like to get ahead of it.
If OT security now includes data security, the tempting conclusion is that the enterprise IT world has finally absorbed the industrial problem. Bring in the corporate SOC, layer on an AI governance framework, call it solved. I’ve already seen the outline of that pitch forming.
It’s wrong. Convergence didn’t hand the problem to IT. It created a capability gap that most of the market can’t cross from either direction.
The enterprise security world has real competence in model integrity, training data governance and drift detection. It has close to none in physical consequence. It doesn’t know what a twelve percent dosing error does downstream, which failure modes a safety instrumented system was designed to catch, or why isolating the asset is frequently the wrong response in a continuous process.
The traditional OT world understands consequence in its bones and has close to none in model governance. It has never had to reason about training data provenance, because until recently there wasn’t any training data to reason about.
The frameworks themselves tell the story. Current OT threat modeling guidance now recommends pairing MITRE ATT&CK for ICS with MITRE ATLAS, the adversarial AI framework.[5] You need both matrices open on the same desk. That’s the whole argument in one workflow change.
“Convergence didn’t hand the industrial problem to IT. It created a gap most of the market can’t cross from either direction.”
What this actually demands operationally
The useful news is that the required capabilities aren’t exotic. They’re disciplines mature operational security programs already run, extended to a new artifact class. Organizations that recognize this early will find they’re further along than they assumed. The ones treating AI governance as a separate greenfield program will spend more and get less.
Patch management becomes model revalidation. CISA recommends establishing safe operating bounds, monitoring for drift or abnormal behavior, and validating outputs in simulated environments before redeployment.[5] That’s a patch cycle applied to models instead of firmware. Same discipline, same cadence problem, same friction with operations.
Backup and restoration becomes model rollback and deterministic fallback. The guidance is explicit that operators should preserve the ability to revert to manual or deterministic control.[10] Known good model state, tested rollback, and a rehearsed path back to deterministic operation are restoration requirements with continuity attached.
Security operations adds model behavior as a monitored signal. Drift, anomalous inference patterns and poisoned input detection are telemetry problems. A SOC that already correlates operational telemetry against expected process behavior is the right home for them. A SOC that has never seen a process historian is not.
Incident response gets a new opening question. When something goes sideways in an AI influenced environment, the first question is no longer whether you were attacked. It’s whether this was an attack or drift, and how you tell the difference under time pressure with the process still running. Very few IR playbooks answer that today.
Lifecycle services extend to model lifecycle. The joint guidance recommends a secure AI system development lifecycle covering design, procurement, deployment and long term operation, with explicit shared responsibility allocation across owner, vendor and integrator.[10] Somebody has to own the question of who’s accountable when a vendor model behaves unexpectedly inside your process, and that answer needs to exist beforehand.
Compliance gains an entirely new surface. Joint national guidance, EU AI Act enforcement ramping through 2026, and sector specific expectations are all landing on organizations that in many cases haven’t finished their existing OT compliance work.
Why I’m writing this from where I sit
I’ve spent twenty five years arguing that OT security deserves its own seat, its own budget and its own career path. I still believe every word of that. But intellectual honesty means acknowledging when the ground moves.
It moved. AI didn’t ask permission before embedding itself in operational systems, didn’t wait for governance to catch up, and didn’t notify anyone that the separation between data security and process security was going obsolete. That’s just what transformative technology does. It shows up, and then it’s load bearing before anybody voted on it.
I’ve argued for a long time that probability is a guess and consequence is a fact, and that serious operators work the fact. Model drift is probabilistic. What a drifted model does to a physical process is not.
The most dangerous gaps in critical infrastructure are almost never the ones everyone is discussing. They’re the ones that opened while attention was somewhere else. This one opened while the industry watched AI arrive in the carpeted space. It arrived in the uncarpeted space too, and it brought the data security problem with it.
We should probably talk about that.
References
1. Splunk. “OT Security Is Different, Isn’t IT?” Overview of the Purdue Model as the architectural separation between enterprise IT and industrial process layers. splunk.com
2. SIGA OT Solutions. “Revisiting Stuxnet, 15 Years Later.” June 2025. Details on Natanz PLC compromise, malicious ladder logic injection, and falsified sensor reporting. Corroborated by HSToday, “Stuxnet and Beyond: The Origins of SCADA and Vulnerabilities to Critical Infrastructure.”
3. E-ISAC and SANS ICS. “Analysis of the Cyber Attack on the Ukrainian Power Grid.” 2016. Credential harvesting, lateral movement into SCADA, and remote breaker operation across more than thirty substations.
4. Dark Reading. “A Brief History of ICS-Tailored Attacks.” October 2023. Triton/TRISIS safety system targeting; PIPEDREAM native ICS device interaction. Corroborated by CISA advisory on PIPEDREAM/INCONTROLLER.
5. CISA, NSA, FBI, ASD’s ACSC, Canadian Centre for Cyber Security, BSI, NCSC-NL, NCSC-NZ and NCSC-UK. “Principles for the Secure Integration of Artificial Intelligence in Operational Technology.” December 3, 2025. Named OT-specific AI risks including model drift, data poisoning, prompt injection and limited explainability; LLM safety decision warning; recommended pairing of MITRE ATT&CK for ICS with MITRE ATLAS; safe operating bounds and pre-redeployment validation. cisa.gov
6. Forescout Technologies. ICS vulnerability research, 2025. 508 advisories covering 2,155 vulnerabilities, highest volume since tracking began, with 82 percent rated high or critical severity.
7. SANS Institute. “2024 ICS/OT Cybersecurity Report.” 19 percent of surveyed organizations reported one or more security incidents within a single year.
8. Rockwell Automation, via Solutions Review. “AI As a Double-Edged Sword for OT/ICS Cybersecurity.” September 2025. 49 percent of surveyed manufacturing leaders planned AI/ML cybersecurity deployment within twelve months.
9. Documented AI failure modes in operational technology environments, including data poisoning altering safety thresholds, model drift degrading recommendation accuracy as physical conditions change, and model evasion causing malicious commands to appear as normal operational behavior. See ISACA, “AI Security Risk and Best Practices” (2024), and CISA reference 5 above.
10. CISA et al., reference 5 above. Integration challenge mitigations including reversion to manual or deterministic control; secure AI system development lifecycle spanning design, procurement, deployment and long term operations with shared responsibility allocation across owners, vendors and integrators.
Matt Morris
VP of Security & Resilience, EverLine
