Liability Regime for Insecure Software: How to Get There

Liability for software insecurity requires a blended scheme that balances the threat of liability with incentives for improving security.

Liability Regime for Insecure Software: How to Get There

The case for imposing legal liability on providers of insecure software is in the making for decades by scholars and researchers. It is recently put back in the spotlight as one of the strategic objectives outlined in President Biden’s 2023 National Cybersecurity Strategy (“Strategy”). It has been called “revolutionary”, and a “landmark moment for the industry”, but at the same time “risky” and possibly “the most controversial aspect” of the Strategy.

This issue invites strong objections from manufacturers, and divides experts in legal and security communities. Not all insecure software is created equal, and the key is to strike the right balance. How we get there is the focus of this article.

Why Liability, Why Now

Data Breach Risk for Consumers

As cyber incidents continue to rise, the Strategy urges more mandates on technology companies to implement minimum cybersecurity measures to protect their software from vulnerabilities and consumers from risk of data breaches. When these companies ship products with insecure default configurations or known vulnerabilities, or integrate third-party software with unvetted or unknown features, end users are left holding the bag, and the entire ecosystem suffers.

Market Forces Are Not Enough

The Strategy points out that the market forces alone have not been enough to drive broad adoption of best practices in cybersecurity and resilience. That is leading to a race to the bottom as software vendors use contract law to shield themselves from liability. Critics of the Strategy dismiss the idea of imposing liability as an interference by the government in the software providers’ ability to make their own technical decisions. Ultimately, the Strategy reflects the Biden administration’s belief that the cascading, harmful effects of insecure software may not be adequately abated without the ability to impose legal consequences for failing to implement reasonable security.

Incentivizing Reasonable Security

The Strategy echoes the Cybersecurity and Infrastructure Security Agency (CISA) Director’s proposal that Congress should advance legislation to shift liability onto the providers who should be taking reasonable precautions to secure their software. It envisions doing so by preventing them from disclaiming liability by contract, establishing a standard of care, and providing a safe harbor to shield from liability those providers that do take reasonable measurable measures to secure their software.

Absolute Liability for Defective Software

While the idea of imposing liability may appear revolutionary in the context of software products, the theory of holding manufacturers of a product liable for defects is over a 100 years old. Automobile makers in the early 20th century also used to disclaim liability for any flaws in their products. This practice continued until the landmark decision in the case of Buick Motor Company in 1916 established the product liability theory. Under this theory, the absolute liability for any product defects lies with the manufacturer based on the principle that it is “in the best position to know details regarding assembled sub-systems and to control the processes that would address risk factors.” The same principle can be applied to those in the software supply chain who are best positioned to know and address the risks in their software.

Liability For Breaching Standard of Care

While product liability is absolute, it may only apply when insecure software is viewed as a defective product. An alternate theory of liability that exists is based on a negligence claim. However, it is difficult to enforce in practice, as it requires a consumer to prove that the manufacturer owed them a duty of reasonable care, the duty was breached, and the breach caused them actual harm (aka “causation”). The exact standard of reasonable care would be determined on “case-by-case basis,” but would generally depend on industry-wide best practices such as reasonable security standards. Even if breach is established, causation and actual damages become increasingly difficult to prove as software becomes more complex. And last but not least, liability for negligence may be precluded under the contract.

Another potential theory of liability can be based on professional malpractice, where the standard of reasonable care might be replaced by customary care. This could allow software experts to define a range of acceptable practices, as well as a minimum floor of competence, and might improve software quality by offering more sensible legal oversight.

Liability for Technology Is Complex

Liability Scheme Should Calibrate Risks

Software security is inherently challenging to measure and regulate. The challenge lies in designing a liability regime that incentivizes software providers to improve the security of their products without crippling the software industry or unacceptably burdening economic development and technological innovation.

Liability schemes can be designed in a manner far more nuanced than its critics suggest. Holding software providers accountable for their code need not entail exposing them to lawsuits for any and all vulnerabilities found in their products. Experts at the Department of Homeland Security have opined that it’s not possible to eliminate all defects, but also that right now there is little incentive to invest in a dramatic reduction of cyber vulnerabilities.

It would make sense to not hold all software providers to the same standard of liability, whether it's absolute or based on negligence. Rather, it should take into account the software’s intended use and associated harms. It should not be the number or types of vulnerability that proves a software unreasonably defective or insecure- but rather deviation from reasonable security safeguards, such as those prescribed by industry standards or required under existing regulations. In fact, adopting such safeguards or standards could in turn constitute the basis for safe harbor to shield the provider from liability.

Shared Responsibility Can Evolve Into Liability

There is precedent in other areas going through a similar process, which starts with a self-regulatory model and then evolves into regulation. Most notable and relatable example is in data privacy, where regulations such as the GDPR and the CCPA have established an expectation of reasonable care for protecting data, accountability for those who fail to comply, while allowing safe harbor mechanisms for reducing friction in trans-atlantic data transfers. Establishing the concept of safe harbors allows the industry to mature incrementally, leveling up security best practices in order to retain a liability shield, versus calling for sweeping reform and unrealistic outcomes.

An example of self-regulatory approach in cybersecurity is the shared responsibility model adopted by cloud providers like Amazon Web Services (AWS). Though that is encouraging, cloud and software providers should take more of the responsibility to avoid errors or misconfigurations, according to Jason Chan, the former Vice President for Security at Netflix. “Rather than expecting the end user (who is often not sophisticated in security practices) to do what it takes to use software securely, the providers should do it for them by implementing secure defaults,” urges Chan, who is credited for implementing the secure-by-design philosophy at Netflix. That would be better than taking action after-the-fact, he says. For example, Peloton added a pin code to let users control who can use the product after multiple reports of accidental unsafe use. Similarly, AWS tightened the default permissions for its user accounts after reports of numerous breaches caused by insecure configurations.

Requiring that the software should be designed to make the default state as the secure state can be the evolution of the shared responsibility model into a liability-based scheme. “We will no doubt become more regulated over time, but it will also become easier for us to be compliant due to innovations in technology,” says Chan. He opines that rather than fighting regulation, providers should “become more flexible” to adapt to evolving compliance requirements.

Liability Risk May Impact Functionality

As a side-effect of potential liability for insecurity, some providers may scale back the functionality their software provides. In other words, they may want to avoid their risk exposure by focusing on building fewer features with more scrutiny for security defects.

It's also worth exploring how potential liability for insecure software may conflict with liability protections for platform providers for third party content under Section 230. It protects platforms from liability resulting from taking or not taking any action to remove third party content. In situations when malicious content uploaded by the user affects the interactions of other users with the software (for e.g. infects them with malware), a question might arise as to whether the presence of malware in the software could be viewed as a defect and subject to absolute liability, or inaction by the provider to remove the malware be subject to liability under negligence.

“There are many open questions about how liability would work and be limited, including what “reasonable precautions” and standards of care would look like, how small and medium-sized businesses would be accommodated, and how safe harbor compliance would be evaluated,” says Brandon Pugh, Policy Director of Cybersecurity at RStreet. "Holding a manufacturer accountable for willfully failing to act on security is different from holding a manufacturer that tried yet failed to prevent every vulnerability,” he adds.

Insurance Can Play A Role

Covering Risk of Liability

If software providers are prevented from disclaiming liability for insecurity by contract as envisioned in the Strategy, it may be natural for them to rely on insurance to reduce their financial exposure. This is not unlike the role cyber insurance plays today in mitigating the risk of exposure to data breach liability that is often not allowed to be disclaimed by contract. More specifically, a professional liability insurance- also called errors & omissions (“E&O”) coverage- already protects from claims of negligence or professional malpractice for breaching a standard of care (if it can be proved and recovery is available), while a product liability insurance may cover claims based on absolute liability (should the latter extend to software).

Coverage May Also Bring Immunity

In the wake of rising costs of data breaches, underwriters are now taking a fine-toothed comb to commercial cybersecurity practices. The insurers are focused on maintaining a healthy cyber risk portfolio, and raising the bar for coverage based on cybersecurity maturity of the insured. On the one hand, this creates incentives for software providers to adopt good cybersecurity hygiene, and on the other it may also make them eligible for safe harbor protection under the Strategy.

This is a net positive outcome, because the providers are now incentivized to invest in a mature cybersecurity program to reduce their risk of exposure to liability, and may potentially shield themselves fully from the liability while doing so.

Risk Exposure Will Vary

It should be recognized that some providers may not be able to maintain the required level of cybersecurity maturity to protect themselves from liability exposure, or some may simply be overwhelmed by cyberattacks that are “uninsurable,” and the risk may be passed to others in the ecosystem.

One scenario is the creation of a federal cyber insurance backstop to stabilize the markets against catastrophic risk as anticipated in the Strategy, effectively spreading the loss to the taxpayers. Another is the creation of clever financial instruments, such as catastrophe bonds, to pass the risk to those who invest in them.


In conclusion, the ability to impose legal consequences for software insecurity seems necessary because market forces so far have not resulted in adoption of adequate security practices to abate its harmful effects on consumers. There exists regulatory precedence and legal framework for it, but the challenge lies in designing a liability regime that calibrates the risks carefully without crippling the software industry. A well-designed scheme will be a blended carrot-and-stick approach that balances the threat of liability with incentives for improving security.

This is an expanded version of the article originally published in the IAPP Privacy Advisor.

Connect with us

If you would like to reach out for guidance or provide other input, please do not hesitate to contact us.