Why OT Security Resists the Commoditization Wave

Everything written about AI automating work has limits. Those limits are clearer in industrial security than anywhere else.

This whole internet discourse about AI absorbing engineering work has been mostly true: scaffolding gets automated, captured expertise diffuses to everyone, anything with a metric gets optimized overnight. I believe all of it.

Now let me tell you where it stops, because I’ve spent my career on the side of networking where the “computers” are pumps and turbines, and the wave behaves very differently there. This post is less jokes than the others, deliberately. The claims here are the ones I’d defend in a job interview.

Wall 1: The cost of being wrong is physical

In IT, a bad change means an outage, a rollback, and an awkward retrospective at 4 p.m. In OT, a bad change can mean equipment damage. It can mean environmental release. It can mean injury.

This isn’t cultural conservatism or vendor lock-in. It’s fundamental economics. It’s why safety-instrumented systems are engineered and certified entirely separately from control systems — the IEC 61508 / IEC 61511 world exists because atomically, the stakes are different. It’s why the answer to “can we just push the patch?” is a maintenance window measured in months, not minutes. It’s why change control in industrial settings involves people who have nothing to do with engineering and everything to do with liability.

Every AI optimization pattern I’ve described in this world — including the Karpathy Loop applied to firewall optimization — depends on one core assumption: reverting a bad change is cheap. Git reset takes 30 seconds. A config rollback takes five minutes. Even the worst-case scenario — a production outage — is basically a scheduling problem. The loop is designed for cheap reverts; commit if better, roll back if worse. On a live process network where “bad” means “the reactor is now at the wrong temperature,” cheap reverts don’t exist. Sometimes reverts aren’t physically possible.

This isn’t dramatic — it’s everyday. The facility control network runs 24/7 because the process runs 24/7. There is no maintenance window. Every change is a live change. The loop’s core economic premise breaks at the plant gate.

Lab optimization? Absolutely. Autonomous iteration against production control systems? Not in any near-to-medium future I’d bet on.

Wall 2: The knowledge that doesn’t compress

I wrote last time about the knowledge ratchet — expertise migrating irreversibly into documents and models. The honest asterisk: the ratchet only captures what can be written down, and OT is disproportionately made of what can’t.

Three categories genuinely resist compression:

Environment-specific state. The fact that this site’s historian drops under load at 150 simultaneous connections, and that site’s historian is fine at 200 simultaneous connections because it’s on a different (older) hardware revision, isn’t general knowledge. It’s not in training data because it exists in exactly one place. Multiply by every site on earth. A general model compresses general knowledge. It cannot learn that your Building 4 thing happens at 4:32 p.m. every Tuesday because of humidity unless you write it down explicitly. And even then, the model knows you wrote it down; it doesn’t know the same way Cliff knows by being there for 17 years.

Vendor-and-version-locked behavior. OT runs on long-lived, proprietary, locked-down ecosystems — Siemens, Rockwell, Schneider, Honeywell — with documentation behind support contracts, quirks that vary by firmware revision (and sometimes by serial number), and protocols implemented “creatively” in ways that would never pass a code review but have been frozen in silicon for 15 years. Public training data is thinnest exactly where OT knowledge is deepest. The canonical OT protocols — Modbus, Profibus, EtherCAT — have open specs. The actual implementations don’t. The gray area between spec and product is enormous, and it’s where all the real problems live. Slowly, some of this is leaking into public data. Slowly is bounded by hardware lifecycles that measure in decades.

Consequence intuition. Knowing that scanning this subnet with Nessus is fine and scanning that subnet will lock up a 1998-vintage PLC and stop a production line isn’t written anywhere. It’s embodied knowledge. It’s scar tissue. An AI can be told the rule once someone writes it down (e.g., “do not run network scans on the 192.168.12.0 subnet; it contains PLCs from 1998 that fault on ICMP packets above size 64”). But discovering that rule, safely, and early, requires being there, and being careful, and occasionally getting lucky. It requires skin in the game.

Wall 3: Verification requires presence

My entire argument from earlier — “evals for everything” — holds in OT with a catch that demolishes the automation. In IT, the eval is a script. You script the thing you care about, it runs, you get a 0 or 1.

In OT, a critical part of the eval is physical. Is the cabinet physically locked? Is the cellular modem someone installed “temporarily” still zip-tied to the DIN rail where it has been for two years? Does the network diagram match the actual wires? Are there unlabeled cables in the bundle that run to… where, exactly? Is the historian actually getting power, or is someone relying on a UPS that hasn’t been tested? Did the field technician actually install the IED where we specified, or did they mount it six feet to the left because the conduit was already there?

Standards like IEC 62443 and NIST SP 800–82 exist substantially because paper compliance and plant-floor reality diverge. Detecting the divergence requires boots on the ground, a flashlight, a multimeter, and written permission from someone in a control room. There is no API for “walk the site and look at the wires.”

The last mile of OT security verification is, and remains, a human physically standing somewhere asking “does this match what you told me?”

What this means — stated carefully

I want to be precise about the claim, because “AI can’t touch OT” is false. Here’s what’s actually true:

What gets commoditized: OT security content and scaffolding. The generic Purdue model explainers (commoditized — it’s a framework, not a secret). The standard segmentation reference architectures (commoditized). Compliance documentation (commoditized). Config generation for lab environments (commoditized). If your value proposition is “I can tell you what IEC 62443 says,” the wave is already at your feet.

What doesn’t: Site-specific judgment, consequence-aware execution, physical verification, and the trust relationship that lets you touch a control network. Nobody hires the cheapest option to be the last decision-maker before a safety system. Nobody trusts the optimization engine to rewrite the rules that protect a production process. The scarce asset isn’t knowledge anymore — it’s accountable judgment in an environment where mistakes are physical.

This is the honest synthesis. Learn the AI patterns — the loops, the evals, the capture habit — because they’re eating the scaffolding everywhere, including OT. Build institutional efficiency around them.

But build your career on the walls: the places where atoms, liability, and one-of-a-kind plants keep judgment scarce. That’s the enduring moat.