The European Union's newly revised Product Liability Directive, which holds software producers accountable for defects, could have far-reaching effects on U.S. companies that develop for or supply to the EU market software, digital goods, or physical items with integrated software.
"[It] extends the definition of 'product' to digital manufacturing files and software. Also, online platforms can be held liable for a defective product sold on their platform just like any other economic operators if they act like one," the EU Council said. Under the new law, injured parties have a relatively low bar to clear when it comes to burden of proof. Depending on the circumstances, "a court may decide that the claimant is only required to prove the likelihood that the product was defective or that its defectiveness is a likely cause of the damage."
So what does the new law mean for anyone outside of the EU? It could force a fundamental rethink of their software development and testing processes — and accelerate adoption of long-advocated security best practices, experts said. It could also lend momentum to efforts such as the U.S. Cybersecurity and Information Security Agency's Secure by Design initiative and the provisions in the White House's National Cybersecurity Strategy aimed at shifting liability for insecure software products and services.
Saša Zdjelar, chief trust officer at ReversingLabs, called the EU directive a game changer.
"By codifying software as a product under liability laws, the directive acknowledges software as a potential source of harm. This shifts greater responsibility onto software publishers to ensure their products are free from defects that could cause damage."
—Saša Zdjelar
Incidents such as the massive global disruption in July tied to a faulty CrowdStrike update and a stream in recent years of compromises involving trusted software and service providers prompted the new directive. Experts said organizations the EU directive will push organizations to stop simply checking the box for security and actually start doing real security engineering, performing more rigorous security testing, and establishing strong detection and response mechanisms.
Here's what your organization needs to know — and five steps to get ahead of the new directive.
[ Special Report: How to Manage Commercial & Third-Party Software Risk ]
Software liability: A landmine for development organizations
Though the directive introduces no requirements beyond what organizations should already have in place, it assigns no-fault liability on covered entities for damage caused by defects and security vulnerabilities in their software. No-fault, or strict, product liability means a party is held liable for damage or injuries regardless of fault or intent. Under the concept, liability is determined based on the occurrence of damage linked to a product and not on the behavior of the responsible party. The new directive updates the EU's previous civil liability law.
Under the directive, Zdjelar said, software publishers can be held liable for bugs and design flaws that compromise safety, for failure to provide timely updates, or even for making substantial modifications to their products after release. "While free and open-source software (FOSS) developed outside commercial activities is excluded, if FOSS is integrated into commercial products, the organization incorporating it becomes liable for defects," he said. As a result, organizations will need to pay greater attention to the safety and security of open-source and third party components in their software and ensure compliance with licensing requirements, Zdjelar noted.
Significantly the EU directive holds software makers and other covered entities liable for issues tied to any planned obsolescence of a product. And it introduces liability not just for security bugs, but for any software defects that cause material damage, including loss of functionality or business disruption, said Tamir Passi, senior product director at DoControl.
"This creates a whole new level of accountability for the software industry, potentially affecting both [independent software vendors] and their customers."
—Tamir Passi
Jeff Williams, co-founder and CTO at Contrast Security, said that it's important to realize that the new directive offers no safe harbor for organizations that must comply with it.
"The [directive] is very simple, basically saying that software vendors have no fault liability for any security vulnerabilities. The only way out is to prevent vulnerabilities from being exploited and harming users."
—Jeff Williams
Here are five steps to get ahead of the new directive.
1. Implement a secure software development lifecycle
A secure software development process is key to preventing — or at least minimizing — the sort of issues that could trigger legal exposure under the new EU directive. Zdjelar said organizations should make sure the process includes threat modeling for identifying threats during the design phase, industry-standard coding practices, code reviews, and testing using static and dynamic scans. Also crucial are regular penetration testing, security audits, and continuous monitoring for security threats.
2. Develop a plan to detect and mitigate software defects pre- and post-release
Organizations need to go beyond AppSec best practices such as doing static application security testing, dynamic application security testing, and software composition analysis to bolster their capabilities with advanced technologies such as complex binary analysis that can spot and mitigate software defects, tampering and more before and after a software product's release.
Even with advanced new controls, Contrast Security's Williams said, the transformation cannot be just technical.
"Organizations are going to have to find a way to generate a security culture that isn't relegated to a single team in a silo somewhere. Security will have to become an integral part of their software organization."
—Jeff Williams
3. Be diligent about open-source and third-party code
To manage risks associated with third-party components, organizations will need to bolster their vendor assessment practices and include clauses in their contracts that require suppliers to maintain specific security standards and to update them as needed, Zdjelar said. "Agreements with software suppliers [should] include provisions for liability, warranties, and obligations to provide updates," he said.
Practices such as maintaining a software bill of materials (SBOM) for all software components is critical, Zdjelar said.
Williams said the directive mandates that companies are liable for security defects in any of the open-source libraries they use and for malicious code introduced into their software during development.
" That means it's not enough to simply test for known vulnerabilities. Even latent vulnerabilities in all third-party code creates liability."
—Jeff Williams
Because the directive includes passthrough liability for vendors and third-party providers organizations will likely need dramatically increased transparency around security testing, processes, and protection. "While this certainly would include SBOMs, they are just the tip of the iceberg in terms of what organizations need to know about their providers," Williams said.
4. Have a plan for planned obsolescence
The new directive also requires software providers to be clear about the expected lifespan of their products. It holds them liable for damage resulting from their failure to supply needed security updates or upgrades necessary to addressing evolving and new risks during the product lifespan.
Software suppliers need to think about the entire software lifecycle, including how they'll maintain security updates for legacy systems, DoControl's Passi said.
"That means staying current with security best practices and being able to prove they're implementing them. This might mean shorter support lifecycles or more frequent forced upgrades, with clear communication to customers about end-of-life timelines."
—Tamir Passi
The directive obligates covered entities to provide updates and patches, Zdjelar said. So companies need to have clearly defined end-of-life policies and support periods that they need to communicate to users, he noted. "Provide instructions for safe use and the importance of installing updates."
5. Strengthen documentation and evidence preservation
Under the new law, covered entities are required to provide evidence where needed during legal proceedings pertaining to "how a product was produced and how it operates." The goal: To ensure that an entity claiming compensation for damage tied to a software defect has access to information that gives them a clearer understanding of the product.
Software producers will need to fundamentally rethink their testing and documentation protocols, Passi said. "The directive's disclosure requirements mean vendors must maintain detailed records of their development and testing processes while protecting their intellectual property."
Companies will also need to document all their testing and quality assurance processes and also any known limitations of their product, Passi said.
"The challenge will be balancing transparency requirements with the need to protect trade secrets and proprietary information. Testing can no longer be just about functionality — it must also consider potential security implications and document the reasoning behind design decisions."
—Tamir Passi
ReversingLabs' Zdjelar said organizations should also make sure to document their compliance efforts, risk assessments, testing results and update histories. "In case of litigation, having detailed records can help demonstrate due diligence and possibly limit liability," he said.
Going all-in: Strengthen collaboration across your organization
The EU directive presents a legal minefield for U.S. organizations, representing a fundamental shift in software liability that could trigger significant claims against software publishers over defects and security vulnerabilities, DoControl's Passi said.
"This isn't just about preventing security breaches anymore. It's about ensuring software quality and reliability have the same legal standing as physical product safety."
—Tamir Passi
Zdjelar said the directive is a call to action on cross-functional collaboration at organizations. Legal teams, for example, will need to get involved in product development to interpret regulatory obligations. And development teams will need awareness training on the legal implications of product defects and security vulnerabilities, he said.
