Cybersecurity policy has so far mainly tackled the symptoms

The market for commercial software pro­ducts differs from other markets in one key respect: Software vendors generally do not face significant consequences if their pro­ducts cause harm. Instead, the majority of regulations introduced to date place respon­sibilities on operators, such as those of cri­tical infrastructure, and other key entities. Similarly, many common cybersecurity measures target users, for example in the form of warnings, awareness campaigns, or training.

Indeed, users and operators can ensure that their software is up to date and secure­ly configured; they can also set up their IT systems in ways that limit risk. But such measures can do little to tackle the problem of insecure software. Therefore, German and European cybersecurity policy should focus on compelling commercial software vendors to develop secure products.

Vendors lack incentives to develop secure software

For years, the majority of discovered soft­ware vulnerabilities go back to vendors making the same long-known and often easily avoidable errors. At the same time, software developers know how to design secure development processes and products, given the wealth of practical guidance avail­able on the subject. For example, vendors should monitor vulnerabilities in open-source components that they integrate into their products and patch them as needed. They can even use AI applications to simpli­fy this process. Furthermore, they should integrate only actively maintained open-source components. Likewise, they should use memory-safe programming languages to avoid a common type of vulnerability.

Why do commercial software vendors not simply implement these best practices? There are four interrelated reasons. First, software vendors often want to bring their products to market as quickly as possible. After all, they can always patch vulnera­bilities later via a security update. Second, users find it difficult to assess the security of software products, as there is no widely recognised IT security label for software. Furthermore, when users – including corporate customers – make buying deci­sions, they usually focus on functionality and price while disregarding security. Third, cybersecurity incidents have little long-term impact on a company’s reputation or share price. And fourth, vendors face no legal or financial consequences for making insecure products. Policymakers should address this last point.

How policymakers can create the right incentives

Currently, users generally bear the costs when insecure software causes cyber­security incidents. But policymakers have different regulatory options at their disposal to ensure that vendors are held accountable instead, as demonstrated by the incorporation of the polluter pays principle into environmental law. Users may also bear some responsibility for cybersecurity in­cidents – for instance, if they fail to install security updates – and regulatory frame­works should reflect this. Even so, there are several regulatory points of leverage.

To date, injured parties of faulty software can generally bring claims against vendors under warranty law – but only if they have a contract with them. As a result, the vendor may have to refund the purchase price, but this offers at best limited con­solation if the cybersecurity incident in question caused significant harm. To pursue further claims, users usually need to prove that the software did not meet the neces­sary security requirements and that this specific deficiency caused the damage. In practice, this proof is often difficult to pro­vide, as security incidents are frequently attributable to multiple factors. In sum, without further regulation, there are signif­icant hurdles to holding vendors account­able for insecure software.

However, policymakers have three regulatory options at their disposal. First, the legislature can formulate product safety law requirements that vendors must meet in order to be permitted to place their pro­ducts on the market. Market surveillance authorities monitor compliance and impose fines for violations. Such regulation is in­tended to prevent vendors from offering unsafe products in the first place.

The second instrument is product liability law. If a party suffers harm from a defective product, such regulation allows them to bring claims against the vendor of the product. Product liability provisions can therefore not only provide the legal basis for compensating individual damages, but also – given that vendors face significant financial losses – create incentives for vendors to invest more in the security of their products. Experience from the auto­motive and pharmaceutical sectors shows that the introduction of product liability regulation tends to correlate with safer products. Product liability law does not require a contractual relationship between the vendor and the injured party, and it also allows injured parties to claim con­sequential damages.

Software vulnerabilities can be exploited not only when the software is purchased and installed on users’ own systems (“on premises”). The same applies when it is procured as a service, usually as a cloud solution (“Software-as-a-Service”, or SaaS). Product liability and product safety law often does not apply to such usage models. In addition, legislators can therefore establish cybersecurity requirements for these providers.

The Federal Government should not pursue these three regulatory avenues on its own. Rather, it should focus its efforts primarily at the EU level to drive forward European regulations. Once European legislation is enacted, responsibility returns to the Federal Government: EU directives must then be transposed into national law, and EU regulations often need to be accom­panied by implementing legislation.

The special role of open‑source software

Open-source software (OSS) forms the back­bone of virtually all software products. AI applications such as the large language model Mythos Preview have successfully identified vulnerabilities in numerous OSS components. Although this analysis focuses on commercial software vendors, OSS should be taken into account as well.

Regulating non-commercial OSS developers could have unintended consequences. For instance, hobbyist developers might cease their activities for fear of liability or increased security-related burdens. One possible solution would make commercial software vendors that use OSS components responsible for fixing vulnerabilities in them. Similarly, governments could com­pile an inventory of critical OSS components and then (have a third party) secure them.

Trade-offs in placing obligations on vendors

Regulating software vendors has both ad­vantages and disadvantages. First, the dynamic and relatively low-cost software sector has become the foundation of modern digitalised societies and economies. Not all, but some, of the measures that help ven­dors make their software products more secure require time and resources, and sanctions or liability risks can create ad­ditional costs. Vendors would likely pass on these increased costs to their customers, leading to rising software prices. Ultimately, this would mean that a software pro­duct’s price would start to reflect its secu­rity: The less secure the software, the more a vendor would have to spend to secure it or reserve for liability risks, and the more expensive the product would become. On the one hand, rising software prices could trigger domino effects such as inflation. On the other hand, if the prices of software products reflect their security, this would make more secure products more competitive. As a result, buyers would select pro­ducts also based on security, which should raise the level of cybersecurity in the long term.

Second, additional obligations for commercial software vendors could also have unintended consequences. A key factor here is that the market for software pro­ducts is heavily dominated by US companies – particularly in operating systems, office applications, cybersecurity products, and AI applications. Accordingly, US ven­dors have a decisive influence on the level of cybersecurity in Germany. If Germany or the EU passed strong regulation in this field, international companies might decide to leave the market. As a result, these (pre­sumably less secure) products would no longer be available on the German or Euro­pean market. This could, on the one hand, have the positive side effect of improving the market position of those vendors that prioritise cybersecurity. On the other hand, Europe is heavily dependent on US compa­nies in the technology sector as a whole, and specifically in the field of cybersecurity, while for some products there are no Euro­pean alternatives. Despite all efforts to reduce these dependencies, a withdrawal of major US software vendors from the EU market could lead to operational disruptions. Furthermore, stricter European rules for US companies would likely strain trans­atlantic relations.

Third, additional regulation would run counter to the current mood in Brussels, which favours reducing and streamlining existing market interventions, particularly in the digital sector.

Fourth, cybersecurity requirements place a disproportionately heavy burden on small and medium-sized software vendors – which play a particularly important role in Europe – because they have fewer re­sources available for implementation than large technology companies. Relief measures for SMEs can mitigate this effect.

Overall, policymakers considering obligations for software vendors need to balance cybersecurity against efficiency and in­nova­tion. The question is whether the costs of cybersecurity incidents justify such mea­sures. Given the current threat landscape, the answer is likely yes.

Existing product safety regulation for software

In recent years, the EU has adopted legis­lation for each of the regulatory options mentioned above – product liability, pro­duct safety law, and cybersecurity requirements for service providers. However, these regulations contain some gaps, and there are indications that the German government does not plan to enforce them strictly.

In Europe, there is currently no comprehensive product safety regulation in force for software. However, there are sector-specific requirements for medical devices, in vitro diagnostic medical devices, radio equipment, motor vehicles, and high-risk AI systems. In December 2027, the main provisions of the new EU Cyber Resilience Act (CRA) will come into force. This legis­lation sets out obligations for vendors of “products with digital elements”, that is, software and products with embedded software such as Internet of Things (IoT) devices. The German government has al­ready initiated the corresponding implementing legislation.

Once the CRA comes into force, all ven­dors wishing to offer their products on the European market will have to comply with the cybersecurity obligations set out there­in. For example, during a product’s life­cycle, vendors will have to remedy vulnera­bilities that are being actively exploited. For many products, vendors themselves can attest to their compliance with the rules. For particularly “important” and “critical” products, such as firewalls, independent bodies must verify compliance before the product can be placed on the market. If companies violate the rules, they must pay fines and rectify the defects or withdraw their product from the market. Furthermore, customers can bring claims against vendors who violate the CRA rules.

However, the regulation does not apply to products “developed or modified exclu­sively for national security or defence pur­poses or to products specifically designed to process classified information”, as the EU has no competence in this area (dual-use products, however, remain within the scope of the regulation). In this field, member states can either conduct initiatives under the Common Security and Defence Policy or put forward national measures. The CRA calls on EU member states to ensure, for defence and security products, a level of protection that reaches or surpasses the CRA requirements. Indeed, products in this sector are often already subject to stringent security requirements, for example through procurement directives or mandatory certi­fications. Some of these requirements are classified and therefore cannot be assessed here; however, authorities can often deviate from them in justified cases. It is thus ques­tionable whether these instruments are suitable for raising the security of these products overall.

Existing product liability regulation for software

Even if the CRA were to be rigorously enforced following its entry into force at the end of 2027, insecure software products will likely continue to cause harm. This is where product liability law may come into play. When considering such regulation, policymakers must carefully balance differ­ent interests: Liability regulation protects consumers, but it also restricts entrepreneurial freedoms, as it may influence liability costs, insurability, and recall and litigation risks.

The current German Act on Liability for Defective Products does not apply to soft­ware. However, a new version of the EU Product Liability Directive, on which the German law is based, was passed in 2024. Members of the Bundestag’s Committee on Legal Affairs and Consumer Protection are currently deliberating a draft law that trans­poses the Directive into national law.

The previous 1985 Directive did not apply to software due to its intangibility, but the recast applies. As the Directive forms part of consumer protection law, it imposes three significant restrictions: Only natural persons may bring claims, only software used exclusively for private pur­poses qualifies, and claims arise only in cases of personal injury, property damage, or data damage. Conversely, this means that neither companies nor public author­ities (such as municipalities) nor natural persons using software for professional purposes can bring claims. Purely financial losses also fall outside the scope of the Directive.

These restrictions apply because the directive governs strict liability: Vendors can be held liable without claimants having to prove intent or negligence on their part. The limitations are meant to ensure that the law does not give rise to uninsurable liability risks that could threaten software vendors’ business models. Compared with natural persons, companies and public authorities are deemed to be less in need of protection because they can usually safe­guard their interests by formulating their contracts accordingly.

However, these restrictions make little sense for the software market. Many pro­ducts are used by private and professional users alike. Major software vendors often have such tremendous market power that they can dictate the terms of the contract (and, for example, exclude liability). This is particularly true when SMEs purchase pro­ducts from large US vendors. Furthermore, cybersecurity incidents primarily cause financial damage. For instance, when cyber­criminals encrypt company data and de­mand a ransom, they often disrupt opera­tions and cause firms to miss out on profits. Against this backdrop, the limitations of EU product liability law are problematic.

Apart from the EU, no country has adopted product liability regulations that entitle users of software products to bring claims. In the United States, there had been discussions under the Biden administration about introducing product liability for soft­ware, but the Trump administration is seek­ing deregulation in the digital sector. In 2022, the European Commission had pre­sented a proposal for its own product liabil­ity directive for AI applications. How­ever, the Commission withdrew this proposal in October 2025 for various reasons.

Existing requirements for SaaS providers

Product liability law generally applies only to on-premises software solutions, not to Software-as-a-Service (SaaS), as the latter is not a product. The CRA applies to SaaS if the service forms part of the product as a “remote data processing solution”. In ad­dition, SaaS providers must comply with the requirements of the Directive on measures for a high common level of cybersecurity across the Union (NIS 2 Directive). Germany implemented the NIS 2 Directive late, in December 2025. The law stipulates that providers must offer secure services, includ­ing the management of software vulnera­bilities.

The problem with NIS 2 is not so much that it contains regulatory gaps – it has a broad scope and applies to all providers offering services on the European market. The exemption for small businesses is hard­ly relevant in the SaaS sector. The problem is that there are doubts about its enforcement in Germany. The Federal Office for Information Security (BSI) is responsible for imposing fines in cases of non-compliance. However, the President of the organisation stated that her agency would generally not impose fines on companies that violate these requirements. But will companies adapt their cybersecurity practices if they have no sanctions to fear? If German authorities do not strictly enforce the rules even against German or European companies, how likely are they to ensure that US SaaS providers make their cloud solutions more secure? And what questions does this reluctance to enforce NIS 2 raise regarding the imposition of fines or product recalls for breaches of the CRA, for which the BSI will also be the enforcing agency?

Four tasks for German policymakers

If policymakers want to improve the dire cybersecurity situation, they must ensure that software becomes more secure. To create the right incentives for software vendors, policymakers should do four things.

First, at the national level, the competent authorities should strictly enforce the exist­ing rules. Both the NIS 2 Directive, which is already in force, and the CRA, which will enter into force in late 2027, can only be effective if vendors know that they face sanctions if they violate the rules. As a first step, the BSI should require all companies covered by NIS 2 to register in the relevant portal – so far, only around half have done so. The BSI should then impose fines for violations, including for US firms. This could encourage companies to prioritise compliance with the regulation. The US administration has recently shown greater openness to regulation aimed at limiting the cybersecurity risks of AI applications. Before taking action against US firms, Euro­pean policymakers should lay the political groundwork through a dialogue on AI and software security risk. At the same time, European governments should prepare for defensive or retaliatory measures from Washington.

Second, European governments should comply with the CRA’s call to develop strict cybersecurity requirements for vendors of software products in the security and defence sectors, and enforce these without exception. In the defence sector, governments can do this in various ways: The Ministry of Defence and the Bundeswehr could provide model contract language to the many Bundeswehr units responsible for procuring and operating software. In ad­dition, policymakers could formulate cor­responding horizontal minimum requirements for procurement and ideally apply them equally to the Bundeswehr and critical civilian sectors.

Third, on the EU level, the German government should advocate for a product liability law specifically for software. In theory, the Bundestag could also close the gaps described above in the draft bill for the national implementation of the EU Product Liability Directive. However, the European Court of Justice has set strict limits on member states’ ability to engage in so-called gold-plating, that is, introducing national regulations that go beyond EU legislation. Furthermore, unilateral national initiatives to regulate the globalised software market are not particularly effective. A European law is therefore the better option. This law should allow companies, public authorities, and individuals who use software in a pro­fessional capacity to bring claims against vendors. Purely financial harms should also give rise to claims. It could also cover the security and defence sectors.

There is precedent for product liability laws for specific product groups. To justify the need for a liability law specifically for software, policymakers should refer to the particular characteristics of the software market. Given the serious cybersecurity threat landscape, support for such a pro­posal in Brussels is likely. Such a law could cap liability amounts to avoid creating un­insurable claims. To protect SMEs, these caps should be tiered according to company size. Such a proposal should account for its implications for transatlantic relations.

And fourth, European policymakers should first pass a comprehensive product liability law for software before considering a regime specifically for AI applications. Even though the latter pose particular chal­lenges, they are, first and foremost, soft­ware. Presumably, comprehensive product liability law for software would also cover many conceivable cases of damage caused by AI applications. It there­fore makes sense to establish comprehensive product liability for software first and then proceed to ex­amine whether AI systems need further regulation. Such a legal framework would also be in line with the European Commission’s recent efforts to streamline EU digital regulation.