On July 30, the FBI warned that attackers had remotely accessed internet-facing Rockwell Automation controllers at US water and wastewater utilities. They changed IP addresses and passwords, and operators lost the ability to see, and sometimes run, connected equipment. Utilities reported loss of pressure and flooding, and CISA described boil water notices and sustained manual operations.
The FBI describes the attackers turning on and setting those passwords themselves, so some controllers had no password protection until an intruder added one. Those devices accepted anyone who reached them, because the people who designed the environments around them assumed nobody outside could.
Welcome to Issue 06 of InfoSec Leadership by InfoSec Relations, featuring Emmanuel Poux, CTO at Junto. He worked 19 years in the defense sector and helped build and migrate an identity stack for the Department of Defense's Mission Partner Environment. Junto did not sponsor this issue.
Let’s get started.
Isolation Is Not an Identity Control
An identity architect and CTO on zero trust for systems that cannot go down.
Listen to the Full InterviewPoux came to identity through the defense sector, where he worked 19 years as an engineer, architect, program lead, and enterprise architect. That last role took him into identity at the edge, in disconnected operations that manage devices and communications with no connection to the internet. "Identity was always the enterprise directory or your Active Directory," he recalls. At the edge, he built siloed identity platforms for environments the enterprise directory never reached.
That background shapes how he reads critical infrastructure today. Plants and utilities run on the same assumption he met at the edge, that a system cut off from the outside world is safe by default.
Plant security still rests on isolation and inherent trust
The first thing Poux notices in an industrial environment is how safe it feels to the people who work there.
"I think what happens is the fact that they're isolated and off the internet gives them a very good sense of security, which does work for the most part," he observes. "It's not going well as of late." Physical access to these sites is hard to get, and operators lean on that difficulty as their main control.
That sense of safety leaves one question open, and Poux raised it early in his own work. "So from my standpoint, it was like, well, how about if one of these operators becomes a bad actor, what happens?" he asks. "And there are no safeguards at this point in the industry for that." He credits the industry with progress, yet he still describes OT as "very much an implicit trust type of environment."
Implicit trust reaches beyond insiders. A shared operator account records that someone acted but not who did, and a standing vendor connection accepts anyone holding its credentials. The July controller intrusions showed the outside version of the same gap, since reaching a device was enough to change it.
So pull the list of shared and generic accounts on your OT network, including the ones vendors and integrators use. Treat each one as a login you cannot attribute, and rank them by what they can reach.
Uptime sets the terms for every identity control
Most identity controls assume a user can wait a few seconds to prove who they are. An operator answering an alarm often cannot, and Poux puts the constraint plainly. "OT environments cannot have disruption," he says. "The reason why they don't allow technology into those spaces is primarily because they can't go down." An IT outage is recoverable in his telling, but water, sewage, and electricity leave no such margin.
Operators resist anything that could lock them out at the wrong moment. "They have to be able to log in successfully and deal with an issue without lots of barriers," he explains. That does not make the current state acceptable either. "It can't stay the way it is now, where you have shared accounts, long-lived credentials, but at the same time, there has to be a transition to go from that full trust model to more of a zero trust model," he adds.
The model Poux describes keeps identity local to the plant. He pictures an ICAM system that runs inside the OT environment, provisions access just in time, and catalogs every human and non-human device. Enterprise identity often depends on an external identity provider with no local fallback, and that design leaves an operator stranded the moment the link drops. "If you have a very strict zero trust model where there's no such thing as a local user account on an application or a device, that becomes problematic," he cautions.
So design the break glass identity before you retire a single shared account. Decide who controls it, how it works when the network is down, and what record each use leaves. Then test it in a drill before an alarm tests it for you.
Segmentation fails without monitoring across the boundary
Separating IT from OT remains the most repeated advice in industrial security, and Poux sees the same flaw behind most of its failures. "The isolation and implicit trust in that isolation is the problem," he argues. The enterprise learned this with DMZs, VPNs, and VLANs, controls that drew a boundary and then trusted everything inside it. "That's all great, but if you're not monitoring what that device is doing, what that user is doing, what that network flow is doing, then you're going to have issues," he notes. "It's the same thing, just in the OT environment it's a lot worse."
Enterprise zero trust replaces the boundary with continuous evaluation of the device, the user, and the network together. OT cannot adopt that model in one step, because every new control first has to prove it will not interrupt production. Poux treats the adoption as a question of pace. "When you introduce these policies like zero trust, it has to be very methodical on how you do that, because you cannot afford downtime," he insists.
So monitor the boundary between IT and OT as closely as you enforce it. Log which devices, users, and flows cross it, and alert on any new one before you tighten the rules.
Identity controls can start at the device
Much industrial equipment runs for decades, lacks authentication support, and outlives its vendor. Poux does not accept that as a reason to leave it alone. "You can start at the device level, which is what a lot of people in the OT space are doing, even some of the larger vendors," he points out.
He reads a recent water treatment intrusion through that lens. In his reading, a modern controller had likely been reachable from the internet for upgrades or monitoring, inside an environment otherwise treated as isolated. "And through that interface, the identity obviously checked out, because somebody had to get into the controller to do the hack," he reasons. In the July intrusions the FBI describes, reaching an internet-facing controller was enough to reconfigure it.
That is why the device comes first in his sequence. "At the very bare minimum, you start with the device, the non-human element, because that's what comprises the OT environment," he says. The first relationship to secure is the one between a device and the controller or human interface it talks to, and he wants it authenticated and monitored. Human access comes next, built outward from there. Distributed control systems, which command PLCs and make decisions across them, get the same treatment, with every control locked down so that nothing acts "without explicit permissions."
So map every path that can reach a controller or HMI, from engineering workstations to remote access gateways and the cellular modems used for field access. Authenticate and monitor each of those paths before you work outward to user access.
Every added control gives operators something else to troubleshoot
The most common mistake Poux sees is treating OT like IT. A critical system needs fewer moving parts, because operators have to find a fault fast when something goes wrong. "Any time you make a system more secure, you introduce entropy," he warns. "Meaning you introduce something that you can't see, potentially, that can come up."
Each security tool built for the enterprise brings its own inputs, outputs, and failure modes. On a plant floor, an operator may have to diagnose every one of them during an incident. Poux extends the concern to modern data centers, which he describes as "little mini cities with their own power, their own water." The outcome he wants to avoid is a control that fails in a way nobody can diagnose, "and then everybody's power is out while you troubleshoot the IT problems."
So for every identity control you plan to add in OT, write down how it fails, who can override it, and how long recovery takes. Pilot it during a maintenance window, and keep the rollback ready before it reaches production.
Coalition identity offers a model for vendor access
Poux's defense work gives him an unusual view of shared access. In the Mission Partner Environment, US commands worked with international partners through a hub and spoke model that granted "just enough permissions to certain pieces of the architecture." The partners trusted each other, and they still limited what they exposed. "The biggest thing is, what are you sharing?" he stresses. "Because it's rarely that you just federate and you have access."
He applies the same structure to critical infrastructure, with vendors in the place of foreign partners. A vendor needs access to certain systems for a defined purpose, and the agreement should name them. Authentication alone does not settle the question. "Just because somebody's authenticated doesn't mean that they should have access to certain things, and they should not be allowed to move laterally," he contends.
The FBI's July warning makes a related point about third parties. It flags that similar network setups provided by third parties may let attackers multiply their successes, so one integrator's remote access design can repeat the same opening across many sites.
So write each vendor's permitted systems into the contract, and enforce that list at the network and identity layers. Block lateral movement from vendor sessions by default, and review any integrator who has built the same remote access setup at several of your sites.
Physical processes still need human eyes
Autonomous systems raise the stakes, because a wrong decision can move an actuator. Poux sees AI in OT today as mostly read-only, based on what he hears from customers. "You probably don't want that, in a sense, without some critical check of a human being," he maintains, describing a sensor alert that a person confirms before anything acts on it.
In his assessment, non-human identities do not crowd OT the way they crowd IT, because sensors, actuators, PLCs, and remote terminal units are "very segmented to a machine." The pressure point is the distributed control system that commands them. "And if it is automated, then you have to have a set of human eyes to make sure that it's correct," he adds.
So keep AI in OT read-only until you have defined, for each automated action, which person approves it and how fast they can respond. Apply explicit permissions to the distributed control system first, since it can act across every controller beneath it.
One working identity is enough to stay inside
An attacker needs only one working identity to enter an industrial network, and Poux expects them to stay once inside. "And once that attacker has that identity, they can stay in there for a long time," he notes. "So the operator may never know." Palo Alto Networks' Unit 42 found that identity weaknesses played a material role in nearly 90% of the more than 750 incidents behind its 2026 Global Incident Response Report.
The statistic matches a lesson Poux learned over his own career. Early on, he and many of his peers trusted firewalls, segmentation, and physical barriers, and they assumed a user on the VPN was the right user. "How do you even know that's the guy on the other side?" he asks now. Multi-factor authentication narrowed the problem without closing it, since an intruder with access to a home, a token, and a password still gets through. "You have to view the network as hostile and trust no one," he concludes.
So treat every session into OT as unverified until device, user, and network context agree. Downgrade access automatically when any of the three changes, rather than trusting a login for the length of a shift.
Inventory comes before every other identity control
Poux's first step for a security leader is the least glamorous one. "You need to do an inventory of all the inputs into your system," he advises. From there, he would retire shared accounts, move to just-in-time provisioning with finite access windows, and catalog device movement closely enough to write policy from it. When something in that policy changes, the policy downgrades access so nobody can move laterally on a stale permission.
Without the inventory, every other control rests on guesswork. "If you don't know what your inputs and outputs are on the platform, on the network, even if it's isolated, then you're blind," he states. Enterprise IT tracks its assets in a configuration management database, and Poux finds no equivalent on the plant floor. "OT environments definitely don't have that," he observes.
None of this means operators should adopt the enterprise playbook wholesale. Poux pushes back on the habit of treating more IT as the fix for OT. "It has to be done very methodically and in a very careful way," he emphasizes.
CISO Action Plan
Isolation has stood in for identity in OT for decades, and attackers now reach the devices it was meant to protect. Here is what to settle now.
- Attribute every shared account. List the shared and generic accounts on your OT network, including vendor and integrator logins, and rank them by what they can reach.
- Build the break glass path first. Define who controls emergency access, how it works offline, and what record each use leaves, then test it in a drill.
- Monitor the IT and OT boundary. Log every device, user, and flow that crosses it, and alert on new ones before you tighten the rules.
- Secure every path into each controller. Authenticate and monitor engineering workstations, remote access gateways, and cellular modems, and take controllers off direct internet exposure as CISA advises.
- Document how each new control fails. Record the failure mode, the override, and the recovery time for every identity control, and pilot it during a maintenance window.
- Write vendor access into the contract. Name the systems each vendor may reach, enforce that list, and block lateral movement from vendor sessions by default.
- Keep AI read-only until approvals exist. Assign a person to approve each automated action, and apply explicit permissions to the distributed control system first.
- Start with an inventory. Catalog every input into your OT environment, devices first, because every other identity control depends on that list.
Thank you for reading InfoSec Leadership.
If you found this analysis useful, please subscribe to the InfoSec Leadership newsletter so you never miss an update.
Lead with clarity, defend with purpose.
Shant Ebenezer Jena
Volunteer Host
This issue draws on InfoSec Relations' interview with Emmanuel Poux, Zero Trust in Critical Infrastructure, with an Identity Architect and CTO, hosted by Shant Ebenezer Jena for InfoSec Leadership.
