Control system security has gone from a conference topic to a daily operating constraint, and it is about to get harder. When I started working with control systems, Stuxnet was the story everyone in the field was talking about. More than a decade later I have watched the lockdowns that followed, sat on the council that argued over them, and now see a new wave coming where AI agents can find and exploit flaws faster than most sites can patch.
This is what I have seen change, and what I think it means for anyone responsible for a lab or pilot reactor system.
The lesson of Stuxnet
Stuxnet, discovered in 2010, was unlike anything the control systems world had seen. It targeted a specific Siemens PLC family running a specific configuration, changed centrifuge speeds while feeding normal readings back to the operators, and did all of this inside a facility with no connection to the internet. It could cross isolated networks on removable media.
What it proved was simple and uncomfortable: an air gap is a strong control, not a complete one. The people, the maintenance laptops, the thumb drives, and the vendor service visits that every plant depends on can still provide a way in.
The attacker in that case was a nation state with enormous resources, and most of us will never be that kind of target. But the industry took the broader point, and the next decade of IT policy at industrial sites followed from it.
A seat on the IT council
At the R&D center where I worked, I represented the operations side on the site’s Technology and Innovation / IT council. My job was to keep IT changes from disrupting the units, and to carry the problems those changes created back to the people who could fix them.
It was a useful seat because you hear both sides. Researchers saw a stream of updates, lockouts, and new restrictions arriving with no explanation. IT saw a growing list of threats and a group of users who kept finding ways around the controls. Both were right about what they were seeing.
Updates, firmware, and license keys
The biggest change was that control and data systems that had been able to reach the internet were cut off. On its own that is the right decision. In practice it broke a whole category of routine work: license activation, software updates, and controller firmware updates.
Much of the software that runs a reactor system is licensed, from PLC programming environments to historians and analytical instrument software, and both activation and updates assume the machine can phone home. IT had also locked down USB ports and optical drives, which removed the obvious offline workaround. So we had machines that could not reach the vendor, could not read a thumb drive, and could not run without a key or stay current without an update.
What we worked out with IT was a staged process. IT personnel would take the update or the offline activation file, scan it for vulnerabilities, and push it to the machine. On our side, we would open a ticket, wait for it to be approved, receive temporary administrative rights on that computer, and do the install ourselves.
It worked. But an activation we used to do the same day could now take up to a week, most of it waiting on the ticket. That is the hidden cost of a security decision: the policy takes an afternoon to write and months to make livable.
Why IT kept making life harder
From the lab bench, it looked like IT was making the computers worse on purpose. Updates pushed in the middle of an experiment, applications that stopped working, shared folders that disappeared behind new permissions. That frustration was real, and I shared some of it.
What most people in R&D never saw was the trend line behind the policies. The number of attacks against the company had been growing substantially year over year, long before anyone was talking about AI agents. Phishing, credential theft, scans against anything with a public address. IT was no longer responding to Stuxnet. They were responding to a steady, rising volume of ordinary attacks, and the restrictions that annoyed us were their answer to that chart, not to a theory.
A friend of mine watched that chart land on his company. They had gone to the trouble of configuring a VLAN. Then an employee ran an infected file by accident, and ransomware locked them out of everything. The demand they received: pay, or the company’s files go up on the internet, and after that the servers get wiped. The first move was a person opening a file, not an exploit against the network.
What agentic AI changes
The constraint that quietly protected most sites was that finding an exploitable flaw took skilled people and a lot of time. That constraint is eroding fast. In April 2026 Anthropic reported that a model it chose not to release publicly had found thousands of high- and critical-severity vulnerabilities on its own, some in code decades old (CERT-EU’s summary is a good overview). Google’s M-Trends 2026 estimates the mean time from a vulnerability’s disclosure to its exploitation at negative seven days. That is a mean pulled down by zero-days, not a typical window, but the same series measured 63 days in 2018.
AI adds two capabilities to that existing problem. Large language models now write working exploit code and tooling that a few years ago only a small number of specialists could produce. And they can run as agents: coordinated groups that scan, find, validate, and chain flaws together with no person in the loop, at a tempo no patching cycle was designed for.
This does not mean everything is suddenly broken. The same tools find flaws for defenders, and the large vendors are running them against their own code. The exposure is in the long tail: software nobody is auditing, and hardware that cannot be patched at all.
Where reactor and pilot plant systems are exposed
A lab or pilot reactor system runs on hardware that outlives the software support behind it. PLCs, HMIs, managed switches, serial-to-ethernet converters, mass flow controller hubs, and analytical software on a Windows PC that cannot be updated because the vendor validated it on one version. The equipment lasts ten to twenty years and stays in service long after its operating system, engineering software, or firmware loses support, and none of it was built for a world where discovery is cheap.
For most sites the realistic threat is not a targeted attack on the reactor. It is a router on the lab network with four-year-old firmware being the easiest door in the building, or the lab taking collateral damage when the business side is hit. Stuxnet showed that an isolated control system could be the target. The lab can just as easily be the way in, or the thing that gets caught when something else is.
That changes who owns the problem. It is no longer enough for IT to protect the business network while the lab manages its own equipment. Every device with an IP address is part of the same attack surface.
When the control PC goes dark, or starts lying
There are two cases, and they are not the same. In the first, the PC is dead or locked. The PLC or DCS is a computer in its own right, so any control logic that lives in the controller keeps running whether or not anyone can see it. What stops is everything that lives on the PC: alarm annunciation, data logging, and any sequence or interlock that was built in the HMI software rather than the controller. A dead HMI is not a dead unit. It is a unit you cannot see or adjust, and you need to know ahead of time which functions went with it.
In the second case the PC is still running, and it belongs to the attacker. Treat a compromised HMI as an operator with full screen access and bad intentions. Anything the operator can do from the screen, the attacker can do: change a setpoint, raise an alarm limit, force an output, or show normal values while doing it, which is what Stuxnet did to the centrifuge operators.
That sets the questions to answer before anything happens. Can the operator still read pressure and temperature from local gauges and panel displays? Is there a manual shutdown path that does not run through the HMI? And the one that matters most: what cannot be done from the screen? A trip that lives in the controller is not independent if the HMI can write to its setpoint or its bypass bit. Hardwired trips, mechanical relief, and a physical emergency stop are independent because the PC has no write path to them. That list is your real protection when the screen cannot be trusted.
One more physical barrier: keep the controller’s mode switch in RUN rather than a program-enabled position, and remove the key where there is one. On most PLCs that blocks program downloads and online edits, so a modified or corrupted strategy file cannot be pushed from a compromised PC to the controller. It does not stop writes through the existing strategy, and the exact behavior depends on the controller, so check what yours does in each position.
What to do now
Several of the most useful first steps start with coordination and an accurate inventory, not a purchase order. All of them require the people who run the equipment and the people who run the network to treat it as one system.
- Inventory everything with an IP address on the control and lab networks, including what vendors installed and what a researcher plugged in two years ago. You cannot protect what is not on the list.
- Segment the control network from the business network and from the internet. The control zone initiates every connection, nothing outside it can connect in, and outbound traffic is limited to named destinations and ports. Where a flow has to be truly one-way, use a unidirectional gateway, which is its own article. Anything that cannot be patched gets its own zone and only the connections it actually needs.
- Keep the controller’s mode switch in RUN and the key out. That blocks program changes from a compromised PC. It does not block writes through the existing program, so know which protective functions have no write path from the HMI at all.
- Decide how license activation, software and firmware updates, and vendor remote support will work on an isolated machine before you buy the software, not after. This is the lesson I paid for.
- Agree on maintenance windows with IT so updates never land during a run, test each update on a spare or offline machine first, and write down how the unit comes back if the update breaks it.
- Keep offline copies of PLC programs, HMI projects, and instrument configurations, along with the installation media, the exact software versions and drivers they run on, and the license files. Then test a restore. Having the program is not the same as being able to load it; the activation story above is what that gap looks like.
- Put an operations person in the room when IT policy is written, and have IT show the attack trend to operations. People accept constraints when they can see the chart.
- If your group writes its own software, use the same AI tools attackers use to find flaws in it first. The OpenSSF guide to finding and fixing vulnerabilities with AI is a good starting point.
This will be a hard few years for IT teams and for the people responsible for control systems. The two groups will do better if they stop treating each other as the problem.