Who’s Afraid of Products Liability? Cybersecurity and the Defect Model

Despite year-after-year increases in cyberattacks, ominous projections that cyber ransom will rack up a bill of over $265 billion in the coming years, and catastrophic events such as the revelation of Log4Shell vulnerability, the software supply chain remains insecure as ever. The public expects software manufacturers to be answerable for the enormous harm that ensues, at least when identifiable problems in their software lead to these disasters. However, because the American legal system has lagged decades behind the world of cyberspace, that is almost never what happens. Software manufacturers most often face little to no accountability under the law.

This year, Washington began to address these problems. In March, the White House announced a National Cybersecurity Strategy, declaring that “the Administration will work with Congress and the private sector to develop legislation establishing liability for software products and services,” specifically endeavoring to “realign incentives” and “shift the burden” of improved cybersecurity away from end users and onto the entities “most capable and best-positioned” to guard American digital infrastructure. According to the Biden administration, the strategy seeks to hold the stewards of American data “accountable” for their bad practices in part by subjecting them to legal liability. To assuage corporate concerns, the strategy features phrases such as “safe harbors,” “best practices,” and “reasonable precautions” while promising to “minimize the cost and burden of compliance.” In other words, a key part of the Biden administration’s plan to take cybersecurity seriously is a federal scheme of tort liability for software manufacturers that balances these oftentimes conflicting interests.

There is a central question in formulating such policy that must be addressed: What form of tort liability should federal legislation enact for software?

Generally speaking, there are three forms of liability that seek to address socially harmful conduct: criminal, regulatory, and tort. Crimes—such as car theft—may be enforced by government prosecutors and punished—typically by imprisonment or fines. Regulatory infractions—such as driving a car with an expired inspection—are also enforced by government actors, by fines or other practical consequences (for example, the impounding of a vehicle). Our proposal, like the White House call to action, focuses on the third category: tort liability. The commission of a tort—such as negligently crashing a car through a private property owner’s fence and destroying their shrubs—does not put the government into action but instead provides victims with a right to sue injurers and obtain compensation for the harm inflicted (here, the cost of repairing the fence and replacing the shrubs). The victims win only if they can show that the harm was inflicted by conduct that violated one of the rules of tort law. The term “torts” denotes the various legal norms that could ground such a lawsuit such as battery, negligence, fraud, trespass-to-land, and products liability, among others. 

By putting tort liability on the table as part of a cybersecurity plan, the Biden administration has indicated that it wants industry, policy wonks, and legal scholars to tell them what such a framework should look like. Two frontrunners in the debate are “negligence” and “products liability.” Negligence imposes liability on a person or company whose careless conduct caused an injury, while products liability imposes liability on a person or company that sold a defective product that injured someone. Overwhelmingly, the tort of negligence has dominated policy discourse and scholarship alike. As discussed further below, the focus on negligence over products liability is unfounded and unwise; to the contrary, products liability is far more promising.

The Affirmative Case for Products Liability

Products liability law offers three key advantages over negligence:

• It is better able to realign incentives; by focusing on products over practices, products liability forces companies to invest in new methods of developing safer software rather than allowing them to rest on compliance with existing (widely considered inadequate) standards.
• It avoids reinventing the wheel: Products liability has already developed (in other contexts) a menu of doctrinal options to solve vexing problems that will arise (in part because of the complexity of the market) in litigation over insecure software.
• It can help to bridge the knowledge gap between industry and the court: Products liability equips judges and jurors, who are faced with complicated questions of evidence and causation but lack cybersecurity expertise, with procedural safeguards that would help to avoid misapplication of the law.

First, products liability typically forces the manufacturer to focus on whether the product’s design is safe, not on what steps the manufacturer has or has not taken. This makes products liability future oriented and requires companies to invest in better practices to address security risks, including risks that are unknown but reasonably discoverable. Where negligence might forgive otherwise preventable harm because a manufacturer technically crossed the t’s and dotted the i’s on existing cybersecurity frameworks, products liability would demand more. Could manufacturers have built a more secure product, whether those practices are enshrined in frameworks or not? By focusing on the fault in the product—the potential defect—rather than the faultiness of the defendant’s practices, products liability chooses forward-looking proactivity rather than backward-looking conventionalism.

When a lawsuit focuses on a product’s design, a company cannot hide behind how hard it tried to produce safe and secure code; the question becomes whether—in light of knowable risks and feasible alternatives—a different design could have and should have been selected. Compliance with conventionally accepted standards or a record of what appear to be diligent efforts will not necessarily immunize defendants from liability. Putting pressure on defect over conduct can incentivize ongoing research into improved security features. And, as the cyber threat landscape worsens, shouldn’t security research keep pace with the increased number and sophistication of attacks?

Second—and potentially mitigating some of the concerns raised in the prior paragraph—products liability law is better prepared for the range of doctrinal challenges software security lawsuits will present: When should suppliers or component part manufacturers be liable? What responsibilities exist for recalling products after the manufacturer learns of a defect? How does or should a claim of design defect relate to a claim that the defendant should be held liable because it did not warn of risks in the product or instruct users how to mitigate risk? Should software suppliers providing pieces of code to a highly sophisticated user be treated differently than those providing the same pieces of code to unsophisticated users? Should innocent distributors or retailers of defective software created by another company face liability, and, if so, can they be indemnified? The list goes on and on. Sixty years of litigation in complex commercial interactions in pharmaceutical, automotive, food, and chemical domains (among others) has generated a variety of doctrines—common law, statutory, and regulatory—that could provide guidance to legislative drafters for the range of issues likely to arise.

Neither judges nor juries are cybersecurity experts, which points to a third and related set of advantages. Issues of evidence, causation, and defectiveness endemic to products liability law have forced judges and lawyers to construct frameworks for evaluating evidence and experts that are fit to go before juries and to play a role in the adversarial system. Courts rarely know what to do with expert testimony and forensic evidence in software security breach cases. Over the past few decades, products liability law has spawned the most elaborate and sophisticated set of rules and principles for dealing with expert testimony. Plainly, any plan to implement a tort liability regime for code and cybersecurity will face a massive challenge of translating the technical world to the mindset of lay jurors. Products liability is the best prepared to do so.

Correcting Misleading Narratives

Despite the myriad advantages of products liability over negligence, the discourse today still seems to favor negligence. The culprit is likely outdated thinking mired by misconceptions—tainting the discussion and distracting from a promising solution. Let us correct the record.

Perhaps the most common misconception (even among lawyers) is that products liability is harsh and synonymous with strict liability, while negligence law utilizes notions of reasonableness and thus achieves moderation alien to products liability. This view is distorted from top to bottom.

Like negligence law, products liability law utilizes the notion of “reasonableness” and virtually never imposes fully strict liability. American courts do not generally permit plaintiffs to recover for a defectively designed product unless the trial shows that there is a “reasonable” alternative design that the manufacturer could have used and did not. Commonly, a jury will be required to find that the actual design used was “unreasonably dangerous.” Even plaintiff-friendly standards today still require jurors to find that the product’s design defied consumers’ “reasonable” expectations. What’s more, the most pervasive analytical framework in products liability requires a plaintiff to use a cost-benefit method that, in practice, echoes the economic paradigm of reasonableness: If the plaintiff cannot show that the risks of a product’s design outweighed its benefits, they simply lose.

“Surely there must be some aspects of products liability law that are strict,” readers might say, “otherwise it would not have been called strict products liability law.”

Yes and no.

On the yes side, the most prominent early cases involved manufacturing defects, in which sellers are held strictly liable (regardless of manufacturer diligence) for the harm caused. The predicate of liability in these cases is a soda bottle or brake pad that came off the assembly line with a flaw that was not in the original design but ultimately caused an accident. In those cases, companies are held accountable even when due care may not have revealed or prevented the defect.

By contrast, the software liability law contemplated would focus on design defect, which is a whole different domain of defect-based accountability—one that lacks this sort of strictness. Absent the introduction of a bug during the copying of code, akin to a defect introduced on the assembly line, the predominant question will likely be whether there was actually a defect in the design of the software, not whether some glitch in the production process created a “lemon.” Simply put, products liability law need not be strict. No defect, no claim. And design defect is fundamentally a fault-like idea.

Those concerned with the “strictness” of products liability law may point to a period during the 1960s and early 1970s in which a few courts accepted the plaintiff’s idea that the defectiveness of a product could be evaluated in hindsight, and need not concern itself with whether the risks in question were foreseeable. That position has essentially vanished today. The blackletter law of design defect today demands the jury consider only foreseeable risks. For those still anxious about hindsight review, a federal statute can be written to override that concern and entrench what has long been the conventional wisdom of products liability: The defendant is not liable for risks that were unforeseeable. States are already passing laws to remedy similar concerns with common law products liability doctrine in other contexts. For example, dozens of states have passed laws that shield non-manufacturing sellers of products from liability where they sold a defective product but had no reason to believe it was defective.

We are not saying that the common law of products liability is an easy fit; nothing is an easy fit. The text-like qualities of software and its intangible nature have led some courts to shy away from the application of products liability. Additionally, Uniform Commercial Code cases have enforced liability waivers in software contracts. The short answer to these concerns is simply to acknowledge that successful legislation will stipulate that software is to be treated as a product and liability waivers are unenforceable. At a minimum, federal legislation will already need to relax the economic loss rule, a large obstacle to a successful liability regime under negligence or products liability, which prohibits recovery for purely economic harms.

Looking Ahead 

We are far from Panglossian about a products liability framework. As addressed above, the fact that insecure software is informational, distributed with robust warranty disclaimers, and often tied to nonphysical harms, presents challenges to a products liability regime. The same problems beset negligence law, however, so none of these considerations should—on their own or together—disqualify products liability as a framework. Instead, they reveal that the common law as it has developed will not be adequate; legislation is needed. But producing legislation is exactly what the Biden administration has encouraged. On the question of which body of law should serve as the foundation of our new regime, the answer is products liability.