CYBERSECURITY'S ORIGINAL SIN (Part 3/4)

When Software Kills - Operational Technology and the End of Outsourced Risk June 2026

4. When Software Kills: Operational Technology and the End of Outsourced Risk

Every argument surveyed so far rests on a single enabling condition: that the harm caused by insecure software can be successfully shifted to the user. Data breaches are expensive and embarrassing, but their victims are diffuse, their damages are monetized at pennies per record, and their consequences fall on consumers and enterprises rather than on vendors. The entire legal and economic architecture of the past twenty-five years was built to exploit this condition.

Operational Technology changes that condition fundamentally. When insecure software controls a water treatment plant, a power grid, a hospital’s life support systems, or an oil pipeline, the harm it enables is no longer a data record on a dark web marketplace. It is a city without power, a patient who cannot receive surgery, a chemical plant that explodes, or drinking water laced with caustic lye. Physical harm is very difficult to disclaim in a EULA.

4.1 IT and OT Are Fundamentally Different Systems

In IT, data is the asset and data is dynamic. IT systems exist to store, retrieve, transmit, and manipulate information. That information moves constantly, flows across networks, gets processed in countless ways, and serves an enormous variety of purposes. Gateways are everywhere by design because information needs to flow freely to be useful. Security in IT is about protecting data confidentiality and integrity across a highly variable, interconnected, and inherently unpredictable environment.

In OT, process is the asset and process is deterministic. OT systems exist to control one physical process and do it reliably, repeatedly, and exactly as designed. Given a certain input, an OT system produces highly predictable outputs within tightly bounded operational tolerances. A water treatment plant’s chemical dosing system does one thing. The deterministic nature of OT is not a limitation. It is the point. The system was engineered to execute one process correctly and safely, typically for 20 to 30 years, with no tolerance for unplanned deviation. Fewer gateways exist because the process does not need information to flow freely. It needs commands to execute reliably and only from authorized sources.

That architectural difference has a legal consequence. The software industry’s standard defense that software behavior varies across deployment configurations and vendors cannot control how customers deploy their products, has genuine force in IT environments. In OT, that defense is substantially weaker, though it does not disappear entirely. Part 4 examines where it survives and where it does not.

4.1a Why OT Systems Were Built This Way

Most legacy OT systems were not designed for hostile network environments because, at the time they were built, hostile network environments were not part of the operational assumption. Industrial control systems from the 1990s and early 2000s were engineered around reliability, determinism, and long service life on isolated networks with trusted operators. Weak authentication, limited logging, and coarse privilege models were often acceptable tradeoffs. The threat environment did not require otherwise, and constrained hardware made stronger security controls difficult without affecting timing or functionality. Judging those decisions without acknowledging the engineering realities of the period would be incomplete.

The certification burden deserves specific attention because it is widely cited and widely misunderstood. Safety-critical OT products certified under IEC 61508 or IEC 62443 face a re-qualification requirement when the product design is modified. Adding authentication mechanisms to a certified product is not a software update. It is a design change that triggers a new certification cycle. Depending on the product category and scope of modification, re-qualification can take 18 to 36 months and cost between $500,000 and several million dollars per product line. For vendors with large portfolios of certified products, retrofitting security into existing architectures is a multi-year, multi-hundred-million-dollar capital commitment. This constraint is real. It also does not apply to new product development, and it does not explain vendors who designed products without certification requirements and still shipped without adequate authentication.

The problem is not that those assumptions once existed. The problem is that the threat environment changed while the architectural assumptions did not. As industrial systems became network-connected, remotely managed, and integrated with enterprise IT environments, the original trust model collapsed. At that point, vendors faced three choices: redesign the architecture for hostile-network environments; constrain deployment explicitly; or continue shipping systems with legacy trust assumptions while shifting responsibility for compensating controls downstream. This series argues that much of the OT industry normalized the third approach: preserving legacy architectures while transferring the burden of risk mitigation to operators, integrators, and asset owners through perimeter security, segmentation, jump hosts, and operational procedures.

A vendor may not be responsible for the physical limitations of hardware designed decades ago. But once the threat environment shifted, vendors remained responsible for how their products evolved and for being transparent about what those products required to operate safely. In many OT environments, perimeter security became a substitute for secure device design rather than a supplement to it. That is the design decision this analysis holds to be defective.

4.2 The Attack Record: SANS Mistakes in the Real World

The history of OT cyberattacks is a compressed, accelerating timeline from theoretical concern to near-catastrophe. Each major incident maps directly to specific SANS Top 10 items that were documented as dangerous in 2001. The pattern is not coincidence. It is the foreseeable result of shipping OT control systems with design defects that the field had already documented.

No EULA clause covers any of these scenarios. The “software is provided as-is” disclaimer is not a legal defense against the deliberate engineering of an explosion at a petrochemical plant or the poisoning of a public water supply. In every case above, the exploited conditions appear on the SANS Top 10 from 2001 - and in several cases, operator configuration failures compounded design defects the vendor had already embedded in the product.

4.3 The Analytical Mistake, and a Better Framework

Most legal and policy analysis of OT cybersecurity has applied an IT security framework to a system that works on different principles. Before explaining why that matters, we need to establish how the OT security field actually models these systems, because the field already had the right model. Lawyers and policy analysts largely ignored it.

4.3.1 Two Different Security Models: What IT Protects vs. What OT Protects

Traditional IT security prioritizes confidentiality, integrity, and availability (CIA) because the protected asset is information. OT security prioritizes control, availability, integrity, and confidentiality (CAIC) because the protected asset is the physical process itself. An unauthorized actor who gains access to a sodium hydroxide dosing system does not have information they should not have. They have the ability to poison a water supply.

4.3.2 Why the Problem Is Access, Not Bugs

The Oldsmar attacker in 2021 did not find a software bug or use a clever exploit. They logged into the SCADA system and used it exactly as designed, changed a process setpoint, the system responded with the new setpoint. The attack worked because the system had no adequate way to stop an unauthorized person from sitting down at the controls. The security failure was not a bug. It was a missing lock on the door.

4.3.3 Three Legal Arguments, and Why One Is Stronger Than the Others

Three legal arguments get OT software vendors to court. Each is correct. They are not equally strong.

ARGUMENT 1: SOFTWARE CAUSED PHYSICAL HARM, SO NORMAL LIABILITY RULES APPLY

Insecure OT software leads to physical harm, so the legal rule that normally bars lawsuits over purely financial software failures does not apply. Vendors can be sued. This argument is correct. But it still treats the software as something that caused harm from a distance, like a defective car part that causes a crash. The software is the villain. The physical harm is the consequence.

ARGUMENT 2: OT SYSTEMS ARE SAFETY SYSTEMS, SO SAFETY LIABILITY RULES APPLY

OT systems should be treated like other safety-critical equipment. A defect in a safety system that causes harm triggers product liability. This is also correct. But it frames the software as analogous to safety equipment still adjacent to the physical system rather than constitutive of it.

The choice of legal theory matters practically. Negligence requires proving the vendor was unreasonably careless, a showing vendors are skilled at defeating by invoking unforeseeable attacks, industry-standard practice, and customer configuration failures. Strict liability sidesteps that contest: the only questions are whether the product was defective and whether the defect caused harm. Vendors helped write the compliance frameworks that define reasonable care; they are on harder ground when carelessness is not the question. Under the control-interface model, a plaintiff would argue that a product shipping without adequate authentication documented as dangerous since 2001 is defective in design, and that a court accepting the causal chain of defective interface, unauthorized access, altered process, cognizable harm, could find both strict liability elements satisfied.

ARGUMENT 3 (THIS SERIES): THE SOFTWARE IS THE PHYSICAL CONTROL MECHANISM, AND THE ACCESS GAP IS THE DEFECT

In OT environments, the software interface constitutes the operational mechanism through which physical control is exercised not adjacent to the physical process but the interface through which the physical act itself is performed. A plaintiff would argue that the vendor designed that interface without adequate restrictions on who could use it; that the access gap is the design defect; and that the causal chain is short: defective interface, unauthorized access, altered process, physical harm.

This series adopts Argument 3. Arguments 1 and 2 leave too many vendor escape routes open. Argument 3 narrows those defenses substantially.

The distinction between IT harm and OT harm is not merely technical. It is legal, psychological, and institutional. Traditional IT failures primarily produce economic and informational harm: stolen records, disrupted business operations, fraud losses, disclosure obligations, reputational damage. Courts have historically treated these injuries differently from physical injury because the harm is diffuse, monetized, and often indirect. OT failures operate under a different reality. IT flaws lose data. OT flaws can lose lives.

That distinction changes how courts evaluate causation, foreseeability, and acceptable design risk. A vulnerable payroll system may expose Social Security numbers; a vulnerable industrial control system may disable a safety interlock at a chemical plant or alter a water treatment process in ways that physically injure human beings. Once software becomes the operational mechanism through which physical harm occurs, the legal analysis begins to resemble traditional product safety doctrine far more than conventional data-breach litigation. Juries intuitively understand poisoned water, disabled braking systems, and compromised medical devices in ways they do not intuitively understand identity federation failures or enterprise segmentation architecture.

OT systems are constrained by physical law in ways enterprise IT systems are not. Industrial control systems exist to manage deterministic physical processes operating within tightly bounded timing and safety tolerances. A turbine governor, PLC safety controller, railway signaling system, or chemical dosing process cannot tolerate arbitrary latency, unpredictable behavior, or uncontrolled command authority without creating operational danger. Those physical constraints weaken one of the software industry’s most durable defenses: that deployment variability makes secure design obligations inherently indeterminate. In many OT environments, the operational function, timing requirements, and authorized control boundaries are known in advance with far greater precision than in enterprise IT environments. That predictability strengthens the argument that inadequate authentication, unsafe privilege architecture, or absent audit controls are foreseeable design defects rather than unavoidable operational artifacts.

This distinction also helps explain why OT litigation creates unusually high precedent risk for vendors. A confidential settlement after a breach is financially manageable; an adverse judicial opinion establishing that insecure OT control interfaces constitute defective safety-critical design is not. Once a court formally accepts the causal chain of defective control interface, unauthorized operational access, altered physical process, foreseeable physical harm, the legal distance between insecure software and traditional product liability narrows substantially. Defendants therefore have strong incentives to avoid litigated precedent in OT physical-harm cases, particularly where the underlying defect class was documented for decades before the incident occurred.

The foreseeability of this harm is no longer theoretical. In January 2026, Dragos, the world's leading OT cybersecurity firm, investigated and documented the first confirmed AI-assisted attempt to breach industrial control systems at a water utility (Jay Deen, "AI in the Breach: How an Adversary Leveraged AI to Target a Water Utility's OT," Dragos, May 6, 2026, https://www.dragos.com/blog/ai-assisted-ics-attack-water-utility; full technical report: Dragos, "AI-Assisted Compromise of Mexican Water Utility with OT Implications," hub.dragos.com/ai-assisted-compromise-of-mexican-water-utility-with-ot-implications-dragos, registration required). An unidentified threat actor, with no prior OT or ICS knowledge, used commercially available AI models to attack Servicios de Agua y Drenaje de Monterrey (SADM), the municipal water and drainage utility serving Mexico's third-largest metropolitan area. The attacker's initial objective was stealing government records and not targeting OT at all. The AI independently identified a SCADA interface as a strategically significant target, assessed the IT-to-OT pathway, studied vendor documentation, generated credential lists, and executed an automated password-spraying attack against the control interface without OT-specific direction from the attacker. Dragos analyzed over 350 recovered artifacts, predominantly AI-generated malicious scripts. The OT breach ultimately failed. The design conditions that enabled the targeting e.g., weak single-password authentication on the control interface, IT-OT boundary permeability, inadequate network segmentation, are Mistakes 1, 2, and 4 on the 2001 SANS list. The Dragos report explicitly concludes that this attack reinforces the need for security aligned with the SANS Five Critical Controls for ICS Cybersecurity (Robert M. Lee and Tim Conway, SANS Institute, November 2022, https://www.sans.org/white-papers/five-ics-cybersecurity-critical-controls). The SANS institution documented the foundational failure classes in 2001, published the OT-specific control framework in 2022, and the world's leading OT security firm cited both when documenting the first AI-assisted OT attack in 2026. Dragos states directly: 'current AI models do not provide novel ICS or OT-specific capabilities, yet can make OT more visible to adversaries already operating inside IT environments.' The threat is not AI going rogue. It is offensive capability moving faster than the insecure design decisions this series has documented are being remediated.

4.3.4 Three Legal Consequences

No U.S. court has yet ruled that insecure OT software design constitutes a defective product under strict liability doctrine. The three doctrinal consequences that follow explain why the logic of the control-interface argument compels that development, and why defendants will have strong incentives to prevent it from reaching adjudication.

Defendants in OT liability cases attack the causal chain in three predictable ways: the attacker was the real proximate cause; the specific attack was unforeseeable; the customer’s configuration decisions broke the chain. Each faces a shorter causal distance in OT than defendants are used to, for the engineering and historical reasons surveyed above.

The feasibility argument vendors will raise that stronger authentication on legacy OT hardware was not straightforwardly feasible, is real and time-indexed. It carries genuine weight for systems designed and sold in the 1980s and 1990s, before the SANS documentation and before network connectivity became standard. It weakens materially for systems sold after 2001, when the field had documented the specific risks. It weakens further for vendors who added remote access capability to legacy air-gapped architectures without simultaneously redesigning the authentication model. Adding connectivity without adding security is not a hardware constraint. It is a design decision. By 2005, authentication mechanisms capable of running on OT-grade hardware without disrupting deterministic timing were available in comparable safety-critical contexts, including medical devices and aviation systems. The accountability analysis is therefore time-indexed to what was feasible when the specific product version was designed and sold.

Three doctrinal points follow directly from the control-interface argument and govern the legal analysis in Part 4. First, the deployment-variability defense is substantially weaker in OT contexts where the system's operational function is fixed and deterministic. Second, the software-as-product question cuts differently for OT: what matters is what the software does not what it is made. Third, strict liability fits OT control-system failures better than negligence because it removes the foreseeability problem: the plaintiff need not prove the vendor anticipated the specific intrusion method, only that the product was defective and the defect caused harm. Part 4 works through the specific case law, evidentiary requirements, and regulatory frameworks that determine how each of these points gets resolved.

4.3.5 Whittaker’s Framework, Applied to OT

Whittaker and Thompson’s 2004 vulnerability taxonomy sorts software defects by root cause. Class 3 is vulnerable design i.e., bad design habits that bite. In OT, Class 3 defects are not configuration gaps operators find at installation. They are architectural decisions made before the product ships shaped by real engineering constraints, but decisions nonetheless. The OT supply chain complicates accountability. Integrators configure systems during deployment, asset owners set requirements at procurement, and operational engineers make access decisions over the system’s life. The table below focuses on what the vendor controls before the product leaves the factory.

Each row below maps a common OT attack vector to the SANS item it exploited, documents it as Whittaker Class 3 vulnerable design, and identifies what the vendor controlled at design time.

A note on Oldsmar: this series uses the incident as an illustration of the design-defect argument, not as a settled factual record. The public account rests primarily on contemporaneous law enforcement statements and press reporting. The full technical details have not been established through forensic proceedings, and a subsequent investigation raised questions about the initial characterization. The design-defect argument does not depend on Oldsmar specifically; every incident in the attack record table supports the same framework. Litigation based on this argument should be built on incidents with more complete evidentiary records.

4.3.6 Shared Responsibility: What Vendors Owe and What Operators Owe

The liability argument in this series is not a claim that vendors are solely responsible for OT security failures, or that operators bear no accountability for how they configure, maintain, and operate the systems they purchase. The attack record shows that both vendor design decisions and operator practice contributed to every major incident surveyed above.

Vendors are responsible for the foundational security architecture of the control system, authentication design, privilege model, default configuration, audit capability, and fail-safe behavior. These are decisions made before the product ships and cannot be meaningfully corrected by the operator after the fact. An operator cannot add role-based authentication to a system that was not designed to support it. They can add a firewall in front of it. That is a compensating control, not a correction. The vendor’s design decision stands.

Operators are responsible for configuration hygiene within the system the vendor shipped: credential management, network segmentation, decommissioning of unused remote access tools, patch application where available, and incident response readiness. These are decisions the operator makes and controls throughout the system’s operational life. When operators leave default credentials unchanged, keep TeamViewer installed after decommissioning, or run end-of-life operating systems on network-connected workstations, they have made security decisions of their own and those decisions contributed materially to the incidents in the attack record.

Foundational control-security architecture is not delegable. A vendor can specify how an operator should configure the system. A vendor cannot specify that the operator is responsible for whether the system has adequate authentication at all. That decision was made at design time. If it was made poorly, the operator’s subsequent configuration choices may reduce the exposure but do not transfer the underlying accountability.

4.3.7 Where the Legal Theory Stands: An Honest Summary

The control-interface argument is coherent. It is not settled law. Strict liability for software defects has not been accepted by most US courts. The causal chain through an intervening criminal act faces doctrinal obstacles. No US court has applied strict product liability to an OT control-system failure of the kind described in this series. The logic, the analogies, and the regulatory direction including the EU Cyber Resilience Act’s treatment of OT control software as a product with mandatory safety obligations. All points toward it. The doctrine is not there yet.

The regulatory picture is clearer than the judicial one. The EU CRA, effective 2027, creates a compliance framework that will generate documentary evidence directly relevant to product liability claims. TSA’s pipeline security directives, issued after Colonial Pipeline, are the closest current example of binding OT security requirements in the US. CISA’s secure-by-design guidance and the National Cybersecurity Strategy’s call for shifting liability to software vendors signal the direction of regulatory movement without yet creating enforceable obligations.

Part 4 works through the specific legal doctrines, evidentiary requirements, and regulatory frameworks that will determine whether the three key questions of product status, defect characterization, and proximate causation through an intervening criminal act, get answered in the affirmative. The principal objections to vendor liability in OT environments, including innovation-chilling effects, operational patching constraints, open-source dependency gaps, and insurance market readiness, are addressed in full in Part 4, Section 5.9.

This article was written with AI assistance (Claude Sonnet 4.6, Anthropic). The structural analysis, historical judgements, and policy positions are the author’s own. Section-level AI assistance disclosure is provided in the Technical Addendum and Foreword.

Next: Part 4/4 -