The 'Product Liability' Wave: Why the CRA is closer than you think & how the Product Liability Directive and NIS2 shift the burden of proof.

Table of Contents▾

The era of “Shared Responsibility Model” as we know it for so many years, where software & cloud vendors provided tools and customers carried the security risk, is legally coming to an end in the European Union. With the Cyber Resilience Act (CRA) and the updated Product Liability Directive (PLD), the European Union is shifting the “Cyber Security Debt” back to the manufacturer. If you release software, you are soon legally responsible for the cybersecurity posture of your software. With this short piece I want to highlight the most critical parts of this shift from an IT strategy perspective.

---

The scoping trap#

Classical software or SaaS delivery models relied on: “I provide the platform, tools, and documentation; you configure the security”. Concretely a software of cloud service or platform was offered with basic security controls but the actual process of making it secure was mostly done by configuration and adaptation by the customer. This is changing now, as the “secure by design and by default” state of the software must be included in the scope of the product delivery. Art. 3(1) of the CRA is pretty clear here what kind of products are meant:

‘product with digital elements’ means a software or hardware product and its remote data processing solutions, including software or hardware components being placed on the market separately;

When the CRA is fully implemented in 2027, your product or SaaS (covered by the updated Product Liability Directive) must be secure by design & by default. To give a concrete example: You release an ERP system that has an AI chatbot inside. This AI part must meet for example the OWASP Top 10 points for LLMs (genai.owasp.org) and additional security measures, ensuring prompt injection, model drift and other security weaknesses are out of the box fixed and not possible. To ensure this vendors need to do a conformity assessment beforehand.

---

The 24-Hour Reporting Stress Test (Starting Sept 11, 2026) & Compliance Audit Shifts#

Compliance of IT product will shift from an annual audit to more or less “near-real-time” transparency. Under Art. 14(2)(a) of the CRA manufacturers must submit an early warning of any actively exploited vulnerability within 24h. This has massive implications on incident responses and IT security. If your software contains an exploitable bug you must report this within 24h:

an early warning notification of an actively exploited vulnerability, without undue delay and in any event within 24 hours of the manufacturer becoming aware of it, indicating, where applicable, the Member States on the territory of which the manufacturer is aware that their product with digital elements has been made available;

This requires advanced SIEM tools and 24/7 monitoring. Compared with NIS2 this is a significant change in C-Level accountability for lower-level IT vulnerabilities.

---

Data as “Damage” under the Product Liability Directive (PLD)#

The CRA correlated closely with the updated Product Liability Directive (PLD) which introduces a new concept of damage. Article 6(1)(c) of the PLD for example states:

destruction or corruption of data that are not used for professional purposes.

This is a critical link to the CRA, as data leaks are an inherent security problem. Also Art. 10(2)(b) of the PLD defines that a product that is released is “defective” if it does not fulfill security/safety regulations which more or less directly links to the CRA:

the claimant demonstrates that the product does not comply with mandatory product safety requirements laid down in Union or national law that are intended to protect against the risk of the damage suffered by the injured person; or

This intersection of CRA and PLD should not be underestimated in my opinion. If an IT product/ software component lacks a mandatory security update or violates the “Secure by Default” principle, and a customer loses data as a result, you are strictly liable.

---

Concrete Steps to move forward and prepare#

Well, those changes are a bit down the road, so there is enough time to anticipate, but not endless amounts of time… And NIS2 showed us how fast many organizations react to regulatory changes. So, I advise to start early to be relaxed when time comes (Btw. first registration deadlines are already in fall 2026 just FYI). I would recommend:

• Map out your Digital Product Portfolio: Identify software, components, Add-Ins that you offer on market places, scripts you offer. Article 3(30) demands a recertification for every substantial change. I would question how strict this article is applied but having an overview (inventory) is needed.
• Enforce Secure by Default practices: Delivery teams should shift from “Configuration by the Customer” towards “Hardened-by-Design” approaches. Annex I (2)(b) mandates this change “be made available on the market with a secure by default configuration (…)”
• Inventory Supply Chain: You are legally responsible for third-party components you integrate (yes, all those libraries that you import in your code as well). This requires a so called “Software Bill of Materials”.
• Operationalize Art. 14: Build a working “Vulnerability Response” bridge between your Support, Legal, and DevOps teams to meet the 24-hour reporting window. I know this is super hard, but there is still time left. Create a slack channel, a joint task force or whatever fits your organization best. If you are NIS2 affected you most likely have to do this anyways.

Conclusion: In 2026, cybersecurity is no longer a “feature” or a documented process by a software vendor, It is Market Access. Sounds brutal, but this is the reality. Companies that treat the CRA as “more paperwork” will find themselves uninsurable and legally exposed. As always, one word of caution. While regulators may show some mercy for good-faith efforts, the strict liability of the PLD means that in civil law-suits, ‘fair effort’ is not a defense against a non-compliant product. A good and fair effort however will bring you a long way.

---

Disclaimer#

This post is for informational purposes only & only constitutes the opinion of the author - not the companies the author might be employed and/or connected with in any manner! Also this does not constitute legal advice. For specific guidance related to the topics discussed or other legal matters, please consult a qualified professional / lawyer and/or audit firms tech consultancy advisory for qualified and legally binding answers.