Virginia Tech

Randy Marchany

Software Liability Authority

I was reading a great book by Bruce Schneier called “Click Here to Kill Everybody” a while ago. Its main premise is that as everyday objects and critical systems become increasingly connected to the internet (IoT - Internet of Things), the potential for cyberattacks with real-world, catastrophic consequences grows dramatically. Stronger regulation, clear liability rules, and better engineering practices are necessary to make these technologies safer for society.

OT refers to the hardware and software systems (IoT, SCADA, ICS, etc.) that monitor and control physical processes in the real world. These systems run power generation and distribution, water and wastewater treatment, oil and gas pipelines, chemical manufacturing, railway signaling, hospital equipment, building management, traffic monitoring systems and nuclear facilities as well as other critical sectors.

Standard third-party software liability depends on the harm caused by insecure software being successfully shifted to the user.

OT changes that condition fundamentally. When insecure software controls physical infrastructure, the harm it enables is no longer hard to measure. It is a city without power, a patient who cannot receive surgery, a chemical plant that explodes, or drinking water laced with caustic lye. This is physical harm to people, not just breach notification letters. Physical harm is very difficult to disclaim in an EULA.

Since 2020, researchers have recorded nearly 100 publicly known cyber incidents with direct physical consequences to OT operations.

The reason OT attacks matter so profoundly to the question of software liability is not primarily technical. It is legal and political. Why?

• The 'no physical harm' defense collapses. EULA clauses disclaim liability for 'loss of data' and 'business interruption.' They do not generally disclaim liability for bodily injury, death, or large-scale physical destruction caused by foreseeable product failures.

• The 'user error' reclassification fails. When a generic user follows the vendor's documented procedure for remote access and an attacker exploits a default credential that the vendor chose not to change, the vendor cannot credibly characterize the resulting harm as user error. The user did what the product was designed to let them do.

• The causal chain becomes legally traceable. In a data breach, establishing that a specific vendor's product defect caused a specific plaintiff's specific harm is difficult. In a SCADA attack, the causal chain from unpatched PLC firmware to physical damage is often direct, documented, and incontrovertible.

The policy response to OT attacks is beginning to force software to be treated as a product with attendant safety obligations rather than as a service provided 'as-is' with no warranty.

For example, the EU's Cyber Resilience Act of 2024 is the most significant development in this space. It imposes mandatory cybersecurity requirements on manufacturers of products with digital elements as a condition of market access. Manufacturers must ship products in secure-by-default configurations, maintain vulnerability handling processes, provide security updates throughout the product lifecycle, and cannot disclaim these obligations via EULAs. Penalties reach up to €15 million or 2.5% of global annual turnover.

The regulation treats software security as a product safety issue, not a customer configuration problem. This is the legal foundation that the industry argued for twenty-five years did not exist.

  ​The policy response to operational technology (OT) attacks is beginning to force software to be treated as a product with attendant safety obligations rather than as a service provided ‘as-is’ with no warranty.  

In the United States, the Colonial Pipeline attack triggered the first binding TSA security directives for pipeline operators, ending a decade of voluntary guidelines. The Biden Administration's National Cybersecurity Strategy explicitly called for shifting liability to software vendors. CISA's Secure by Design initiative, while not yet backed by legislation, signals the direction of federal regulatory thinking. The Oldsmar incident directly accelerated EPA and White House action on water sector cybersecurity mandates.

If software vendors are required to stand behind the security of their products as a condition of market access, the implications for the industry's existing business model are profound.

First, 'secure by default' becomes a legal obligation, not a marketing differentiator. A vendor cannot ship a SCADA platform with little or no security practices and then disclaim liability when it is exploited.

Second, the lifecycle support obligation expands dramatically. For example, the CRA requires manufacturers to provide security updates for the expected lifetime of a product. For OT equipment that may be in service for fifteen to thirty years, this fundamentally changes the economics of product development, support, and end-of-life planning. Vendors cannot simply discontinue support and walk away, leaving critical infrastructure running exposed software.

Third, the argument that 'software is speech, not a product' becomes harder to sustain when the software in question directly controls physical actuators, chemical dosing systems, power distribution equipment, and pipeline flow rates. Arguing that software should be exempt from product liability doctrine was always weakest at the OT boundary, where the connection between the software state and physical reality is immediate, direct, and measurable. Courts and regulators are increasingly drawing this line.

The software industry will resist these changes with the same lobbying intensity it deployed to construct the EULA shield in the first place. The industry must now defend the proposition that OT software should carry no warranty of fitness in the aftermath of incidents where that software caused or could have caused physical harm. That is a substantially harder case to make than it was in 1995.