It No Longer Takes an Expert to Attack a Factory

Factories have never lacked attackers. Manufacturing has sat at or near the top of the attacked-industry rankings for years, and every plant leader has seen the ransomware headlines. But nearly all of it lands on the business side of the company - email, file servers, the systems that run the enterprise rather than the line.

The factory floors themselves were a different story. Writing a working exploit for an industrial controller - the small computers that open valves, run motors, and keep production lines moving - was specialist work. You needed to understand the protocol, the firmware, the quirks of a product family most software people have never touched. That knowledge was scarce, and the scarcity was a form of protection. An attacker who got into the business network usually stopped there - not out of restraint, but because going further took skills few people had.

That protection is dissolving. In April, Anthropic disclosed that its Claude Mythos model could take on much of the work of finding security flaws and turning them into working attacks - a capability the company restricted to vetted organizations rather than releasing broadly. Since then, published research has shown AI turning a released patch into a working exploit in hours. And open-weight models that anyone can download are estimated to trail that capability by only a few months.

On August 19, this stopped being a research story. A joint advisory from NSA, CISA, FBI, DOE, and EPA - AA26-231A - documented an active campaign using AI-generated scripts against Siemens S7 series controllers, disguised as monitoring tools. It is the first federal confirmation of AI-assisted exploit development targeting operational technology. CISA is explicit that the targeting is broader than one vendor: everyone running these controllers should assume they are in scope.

Put those together and the trend is hard to miss. The scarce skill that stood between the attacker in the business network and the machines on the floor is no longer scarce. What used to require a specialist now requires merely a subscription.

Why the plant can't just patch faster

For years, the standard answer to faster attackers was faster patching. Shrink the time between a fix coming out and the fix being installed. Whole industries organized themselves around that race - automatic updates, staged rollouts, patch Tuesdays.

AI is ending that race even where it was winnable. When a fix published on Monday can be a working attack by Tuesday, no patch cycle is short enough - and IT teams with modern tooling and weekly change windows are feeling that squeeze right now.

The plant floor was never in the race to begin with, and the reason is physical, not cultural. Walk through a factory and much of what you see has been running for ten or twenty years. It runs reliably in large part because nobody touches it. Change one piece and you put the whole line at risk, because everything downstream depends on it. "If it ain't broke, don't fix it" is the operating rule out there, and it earned its place.

And keep in mind what these places actually do. They make our food and medicine. They deliver our power and water. They build our cars. Stopping a line for an afternoon costs real money. A change that goes wrong and stops it for a week is the kind of event careers end over. So changes wait for planned maintenance windows, a handful of times a year, when the line is already down. Plants do patch - they simply patch on that schedule. If attackers have found a faster way to write exploits, changing that schedule is not a simple ask; every added window is a negotiation with production, with vendor support terms, and weighing the risk of stopping the line.

So the gap is widening from both ends. Attacks are getting faster everywhere, and the plant was never built to move fast at all. Any defense built on the plant getting quicker is built on something that won't happen.

"But our plants aren't on the internet"

Mostly true - but it still misses where the risk lives.

The plant as a whole is usually isolated, and deliberately so. But individual pieces of it often aren't, and almost always for a reason that made sense at the time. The chiller vendor needed remote access for service calls, so a connection was set up. A machine builder shipped equipment with a cellular modem for support monitoring. An integrator left a remote link in place after commissioning and nobody took it out. Each one was a practical decision. Nobody was keeping the list.

Some of those pieces end up directly visible from the internet. Research Forescout published on August 5 counted 4,407 Rockwell/Allen-Bradley controllers answering directly from the internet worldwide, 65% of them in the US - one vendor's platform, counting only the directly visible end of the problem.

The rest of the risk arrives indirectly. A controller doesn't need its own internet connection to be reachable - it needs a path from something that does. Most plant networks are flat - one big open floor where everything can talk to everything - a sensible choice when it was made: simple networks are predictable, predictable means dependable, and dependable means always up. The cost shows up when something hostile gets in and inherits that same simplicity. The scripts described in AA26-231A were disguised as monitoring tools - software that would look routine on exactly these networks.

So the question that matters isn't whether the plant is on the internet. It's how many of those connections exist, where they lead, and what happens when a bad actor gets access to them.

Won't AI help defenders too?

If controllers can't be fully isolated, the next hope is that the technology creating this problem can help solve it. Partly, it can.

NIST's SP 1353, a quick-start guide released in draft on August 19, shows how to use AI for Cybersecurity Framework 2.0 analysis, planning, and reporting. It is genuinely useful. It will help teams find gaps faster, document faster, report faster. What it does not do is solve for the maintenance window.

Defender-side AI, so far, speeds up the parts of the job that were never the bottleneck in a plant. The bottleneck is that fixing things means touching production, and touching production carries downtime risk that no analysis tool removes. AI hands attackers the thing they were short of - the skill to write exploits. It does not hand factory defenders the thing they are short of, which is safe chances to touch the machines.

Both sides get AI. Only one side's constraint dissolves. 

The defense that doesn't care how fast the exploit was written

You cannot slow down how fast exploits get written. You cannot safely speed up how fast the plant changes. What you can control is the number in between: how many things can reach a controller in the first place.

An exploit written in hours and an exploit written over months have identical value against a controller they cannot reach. Shrink that set and you have cut your exposure to every exploit against it - the ones published, the ones being generated right now, and the ones that don't exist yet. It is the rare defense whose value goes up as attacker capability goes up, because it doesn't compete on speed. It removes the race entirely.

The two problems named earlier are the two places to shrink it. The flat network is answered by shrinking each machine's world. The traditional way to do that meant carving the plant into zones - a project that touches everything. What's possible now is finer and far lighter. Picture a switchboard on the plant floor: every device connects to it and to nothing else. When one machine needs to talk to another, the request goes to the switchboard, which checks who is asking and whether an approved reason exists for that conversation - and connects them only if one does. Every device starts with what amounts to a network of its own, able to reach the handful of systems it has an explicit reason to reach and nothing else. All of it happens locally, on the floor - no rewiring, no new addresses, nothing installed on the machines. A foothold - an infected workstation, a compromised vendor laptop - lands in a room of one instead of an open floor.

The one-off connections are answered by the same switchboard, taking calls from outside. The chiller vendor no longer holds a standing line into the plant: they call in, the switchboard verifies who they are, and it connects them to the one system they service - for that session, and nothing else. No direct inbound path to a controller exists at all. This is easier on everyone, not harder. The vendor has nothing to install or maintain; access simply works when they need it. And because every connection now passes through one place, the list nobody was keeping starts keeping itself - every vendor, every link, visible and auditable by the security team. The floor keeps everything it legitimately needs; what changes is what those connections can reach, and who can see them. Neither move requires taking a line down, which is exactly why they work at plant change speed.

This is the thinking behind Zscaler's approach to OT - my colleague Amit Aneja's recent post, Securing the Unsecurable: OT, IoT, and the Factory Floor, walks through what it looks like in practice on the plant network.

None of it fixes a vulnerable controller. The flaw is still there, and patching within the windows the plant can support still matters. What architecture changes is the size of what's left - fewer paths for an exploit to use, fewer places a stolen credential can go, and a record of every connection when something needs investigating.

The hard part of the attack got easy. The hard part of the defense - changing a running plant - did not, and will not. And you cannot decide what the switchboard should allow until you know what talks to what today - so the place to start is knowing what can reach your controllers, and that is a map, not a plant change.  It is the work we do in an OT architecture workshop.