I just finished reading a report about the attacks against water utilities in Minnesota, and one detail stopped me cold. In at least one of the affected utilities, the attackers reportedly modified the ladder logic inside the PLC project file. That detail matters far more than simply saying an attacker gained access to a controller. They didn’t just steal a password, change an IP address, or lock an operator out of a system. They changed the logic controlling the physical process.

Think about what that means from a recovery perspective. You can reset the password, restore the IP address, regain communications with the controller, and see perfectly normal-looking values on an operator’s screen. Everyone can breathe a sigh of relief because the system appears to be back online. But if nobody verifies the PLC logic against a known-good baseline, how do you know you’re actually back in control? A controller can be online, authenticate properly, communicate with the HMI, and report completely reasonable values while still executing logic written or modified by an attacker.

Credential recovery is not process recovery.

What amazes me even more about this incident is that we demonstrated this type of attack in 2003. Twenty-three years ago, as part of a government attack team, we demonstrated what could happen when an attacker gained access to industrial control environments. We showed that cyberattacks weren’t limited to stealing information, defacing websites, or crashing computers. An attacker could manipulate the systems controlling the physical world.

That was 2003. So please don’t tell me this is some new or unexpected threat. Don’t tell me that, in 2026, owners and operators of critical infrastructure haven’t heard about cybersecurity. They have. Don’t tell me the engineers, operators, integrators, IT departments, vendors, and security teams responsible for these environments have never heard warnings about connecting industrial controllers to networks. They have. We’ve been talking about these risks for decades.

Yet here we are, talking about Internet-facing industrial controllers, compromised credentials, remote access, operators being locked out of their own equipment, and attackers modifying controller logic. At some point, we have to stop pretending the problem is a lack of awareness.

Part of the problem is something I’ve watched throughout my career: organizations continue treating operational technology like another IT network. It isn’t. IT and OT share many cybersecurity principles, but their priorities, architectures, consequences, and operational realities can be dramatically different.

An IT security professional responding to an incident might reset credentials, patch vulnerable systems, scan endpoints, restore from backup, block malicious IP addresses, and increase monitoring. Those actions may all be appropriate, but in an OT environment they aren’t necessarily enough. Someone also needs to ask whether the controller logic changed. Did the firmware change? Were configuration files modified? Were safety parameters altered? Did someone change timer values, set points, interlocks, or operating sequences? Is the PLC executing exactly the logic we expect it to execute?

Those aren’t theoretical cybersecurity questions. When cyber systems control pumps, valves, motors, chemical dosing, pressure, temperature, electricity, manufacturing processes, or safety equipment, compromised software can become a physical consequence. That is why OT cybersecurity requires people who understand cybersecurity and the physical processes being protected.

Unfortunately, we continue seeing the same combination of failures. IT personnel don’t always understand OT networks. Cybersecurity professionals are often trained almost exclusively in enterprise IT security. OT personnel sometimes implement remote connectivity because it makes maintenance easier. Organizations assume they’re protected because someone says, “We’re on a closed network.” Then there’s the statement I’ve heard far too many times: “Why would anyone want to attack us?”

Apparently, after all these years, we still haven’t learned the answer. Because they can. Because disrupting critical infrastructure creates consequences far beyond a compromised computer. Because water, electricity, manufacturing, transportation, communications, and other critical systems affect entire communities. And because attackers don’t necessarily need a brilliant, never-before-seen zero-day exploit when we continue giving them easier ways in.

I’ve said this before, and I’ll continue saying it: cybersecurity for IT and OT isn’t impossible. But it has to be done correctly. That means understanding the environment you’re protecting rather than buying a product, installing an appliance, checking a compliance box, and declaring the organization secure. It also means having the right people doing the right job.

I’ve used this analogy before. If you needed spine surgery, would you go to a general practitioner or a spine surgeon? Both are doctors. Both went to medical school. Both understand medicine. But I know which one I want operating on my spine.

Cybersecurity is no different. Being an excellent enterprise cybersecurity professional doesn’t automatically make someone an OT cybersecurity expert. Knowing Windows security doesn’t mean you understand PLCs. Knowing Active Directory doesn’t mean you understand ladder logic. Knowing how to deploy an EDR platform doesn’t mean you understand the operational consequences of interrupting communications between a controller and the physical process it manages.

Specialization matters. Experience matters. Understanding the mission matters. Organizations need to get the right people to do the right job and spend their security budgets on the right solutions, not automatically on the biggest name in cybersecurity because everyone recognizes the logo. The most expensive security tool in the world is worthless if it doesn’t understand or adequately protect what you’re actually trying to secure.

This is where I find myself asking an uncomfortable question: Are we actually getting dumber as a society? I don’t mean because we lack intelligence. I mean because we repeatedly choose convenience and cost savings over lessons we’ve already learned.

Imagine watching someone stick their finger into an electrical socket. They get shocked. Then the next person walks over, sticks their finger into the same socket, gets shocked, and looks surprised. Then another person does it. Then another. Twenty-three years later, we’re still standing around the electrical socket asking, “How could this have happened?”

At what point do we stop blaming the socket?

We know what can happen when industrial controllers are exposed to the Internet. We know what can happen when remote access isn’t properly secured. We know what happens when credentials are poorly managed and networks aren’t properly segmented. We know the danger of assuming an OT environment is isolated without actually verifying it. We also know what can happen when incident response teams treat an OT compromise exactly like a traditional IT incident.

The PLC ladder-logic modification reported in this incident should reinforce another important lesson: recovery in an OT environment has to extend all the way to the physical process. If an attacker modified PLC logic, resetting credentials isn’t enough. Blocking an attacker’s IP address isn’t enough. Replacing a firewall isn’t enough. Even reimaging an engineering workstation may not be enough.

Recovery means establishing a known-good state across the environment. That includes validating controller programs and configurations against trusted baselines, examining engineering workstations, verifying firmware where appropriate, reviewing network architecture and remote-access paths, investigating how the attacker gained access, and confirming that the physical process behaves exactly as intended. Most importantly, it means understanding that “the system is communicating again” and “the system is secure again” are two completely different statements.

Attacks against IT, OT, IoT, and IIoT environments aren’t going away. They’re going to increase. Our homes, factories, utilities, transportation systems, and cities are becoming more connected every year. That connectivity creates tremendous capabilities, efficiencies, and opportunities, but every connection also creates potential attack surface. We cannot keep adding connectivity while treating cybersecurity as something we’ll bolt on afterward when the budget becomes available.

We’ve had decades of warnings. We’ve had demonstrations. We’ve had government advisories. We’ve had compromises. We’ve watched ransomware shut down operations. We’ve watched nation-state actors target critical infrastructure. We’ve watched researchers demonstrate attacks against industrial equipment over and over again. At some point, the excuse that “we didn’t know” stops being believable.

So maybe the real question isn’t whether attackers will continue targeting these systems. They will. The question is whether we’re finally going to learn. Will we invest in the right expertise and design security around the systems and processes we’re actually protecting? Will we stop confusing convenience with good architecture? Will we stop believing that buying the biggest cybersecurity brand automatically makes us secure? Will we verify that supposedly isolated networks are actually isolated? Will we build incident response plans that understand the difference between resetting a password and validating PLC logic?

Or will we keep sticking our finger into the same electrical socket and acting surprised every time we get shocked?

Twenty-three years is more than enough time to learn the lesson. The threat isn’t new. The technology isn’t unknowable. The consequences aren’t hypothetical.

Maybe it’s time we stop acting surprised and start acting like we’ve actually been paying attention.