Strong on Controls, Light on Decisions: What We Heard at the 2026 ICS Cybersecurity Conference

The talk that stayed with us from this month's ICS Cybersecurity Conference in Nashville was Kyle Miller's on testing frontier AI models in OT environments. Booz Allen ran AI models against an isolated testbed built to stand in for a manufacturing plant. In one run, a model went from a compromised perimeter to acting inside the control network in just over 16 minutes. In another, a model found a robotic arm, mapped its motion limits, and moved it, after pausing for the human sign-off the test rules required before any physical action. The models mostly used the devices' own protocols and default passwords - the same openings defenders have been told to close for years.

We also had sessions on the agenda - Umang Barman with "Faster Than You Can Watch: Why Agentic AI Breaks the OT Visibility Model" and Hitesh Chhabra with "The Zero Trust Factory: Your Blueprint for Securing OT without Production Downtime" - and spent the rest of the four days in sessions and hallway conversations. In the architecture talks, one follow-up question kept coming back: does this boundary actually make a decision, or does it just forward a packet? That question sums up what we saw. OT security is strong on controls and light on decisions, and AI is shrinking the time defenders have to close that gap.

Is AI shortening the path from IT to OT?

The problem we heard most, in different vocabularies, was the path from IT into OT. Once an attacker has a foothold on the IT side, how quickly can they reach something that matters on the plant floor? The Booz Allen run shows how short that path can get.

Sessions drawing on real-world campaigns pointed the same way. A threat-intelligence talk on AI-augmented ICS attacks found that the techniques involved were already public; what changed was the speed and autonomy with which AI put them to work. A review of 23 OT attacks found that fewer than two involved a genuine zero-day against a core OT system. George Urling of the West Virginia Fusion Center added that low-skill groups, hacktivists included, now pose a real threat to OT, and many publish their targets and methods in the open.

The talks that moved the room treated AI as an accelerant for known attacks that have known defenses. The ones that leaned on fear lost people quickly. Umang's session made the case that faster detection alone is a race defenders will keep losing at machine speed, so containment has to hold even when nobody catches the attacker in time.

Booz Allen's own results point to a layered answer. Firewalls, segmentation, and endpoint tools slowed the models or flagged their activity, but no single safeguard consistently stopped them. Its recommendations: make environments harder to traverse, remove implicit trust, detect consequential changes quickly, and limit what an attacker can affect. Most attendees we spoke with still see the longer-term impact of AI in attackers' hands as an open question. Two of those near-term recommendations, removing implicit trust and limiting what an attacker can affect, come down to decisions made at boundaries.

Does your boundary make a decision, or just forward a packet?

The firewall-refresh story was everywhere: IEC 62443 zones and conduits, enforcement at each Purdue level, broader industrial protocol coverage. It lands well with engineering buyers who want a clean diagram, and modern zone firewalls can enforce identity- and protocol-aware policy. The follow-up questions were about whether they do. In the OT environments we assess, zone rules are often written broadly and protect conduits nobody can fully explain.

Eric Devoy, OT Security Architect at Grainger, argued that neither the traditional Purdue model nor zero trust alone is sufficient for OT today. Purdue zones provide the structure, and zero trust governs what is allowed to cross between them. The clearest version of that idea we heard in the room reduced it to five questions every conduit across a zone boundary should be able to answer:

• Path: what route does this connection take?
• Identity: who or what is on each end?
• Scope: what exactly can it reach?
• Evidence: how would you prove a session was legitimate?
• Consequence: what happens to the process if it is abused?

A blank answer is a decision nobody has made. As one speaker put it, a boundary that doesn't make a decision is just another hole in the wall. The questions also assume you know what is crossing and what sits behind it, which makes asset visibility the starting point.

Few sessions framed OT security this way, and the room was split: some attendees nodded along, and plenty were openly skeptical. A boundary decision only protects the plant if people use the path it governs. Remote access is where that breaks down.

Why do operators keep routing around secure remote access?

Remote access had a whole cluster of sessions, covering ghost sessions, shared credentials, audit gaps, and privileged access at the IT/OT boundary from inside a large utility. The message that landed hardest with the operations people we spoke to came from the remote access vendors themselves: secure access usually exists, but it is slower than the workaround, so people go around it. Picture a vendor technician on a deadline. If the approved path takes three approvals and a VPN client, the remote desktop tool already installed on the jump host wins.

If the secure path isn't the fastest path, you don't have a secure path. You have a policy document. We see the same pattern in our own OT workshops, and it was useful to hear it confirmed across the industry.

Can virtual patching keep up with AI-found vulnerabilities?

Virtual patching got real airtime, including live demos and a case for protecting devices before a vulnerability is even disclosed. It earns its place. OT patch cycles are slow for good reasons, and plants already struggle to apply the fixes that exist today.

The open question is volume. Several sessions argued that AI will sharply increase the rate at which vulnerabilities are found in controller firmware and embedded software. Every protection that sits inline on control traffic has to be validated before it goes live, because a false positive on that traffic can stop production. As the CVE count climbs, so does the validation load.

Limiting reachability changes that math without replacing virtual patching. Segmentation changes need validation too, but once per path rather than once per CVE, and every path removed is one less conversation that needs inline protection at all.

How should plants think about AI agents?

AI agents for operations and security teams were among the most-watched topics, and the credible talks were restrained. They bounded autonomy explicitly and placed agents at specific Purdue levels instead of implying autonomous plant control. One session framed AI as a potential embedded insider and called for bounded autonomy and least privilege.

When attendees followed up, they asked about identity and audit rather than capability. Every AI assistant that touches the plant, whether a copilot, a SOC agent, or an engineering helper, is a new identity. It needs the same scope, approvals, logging, and revocation you would require of a human contractor.

What should you do differently on Monday?

The people in those rooms understand the risks. Umang's read was that what they lack is budget and time. So here is where we would start, merging both of our lists:

1. List the conduits that cross your IT/OT boundary and the assets behind them, then run the five questions against each one.
2. Fix your three to five highest-risk remote access paths. Start by listing the vendor and contractor endpoints connecting today that nobody has profiled, then make the approved path for the riskiest ones easier to use than the workaround. 
3. Shrink what is exposed. Remove external exposure of OT assets, and turn off unused protocols and services at Levels 2 and 3.
4. Treat AI agents as identities, with scoped access, approvals, logging, and revocation.
5. Deploy decoys as tripwires, backed by segmentation that limits what an attacker can reach even if nobody catches them in time.

None of this requires buying an AI product, and none of it asks a plant to trade away safety or uptime, which still come first.

At Zscaler, this is the model we build OT security around. Zero Trust Branch enforces policy at the IT/OT boundary, so each crossing is decided by identity and scope rather than network location. Segmentation inside the plant limits what any single device or session can reach. Privileged Remote Access gives vendors and contractors a brokered, recorded path designed to be simpler to use than the workaround. And Deception places decoys where legitimate users have no reason to go, so any interaction is a signal worth acting on.

Want to work through your own IT/OT conduits with us? Request an OT architecture workshop.

Want to hear real world customer examples working with us? Here from them directly.