You think you are just working on commission? Legally, you are a manufacturer.

Agencies, system houses, software development firms, platform partners, managed service providers — they all share one self-perception: "We are not building our own product. We work for clients. The responsibility for what goes into production lies with the client."

This view was legally acceptable until recently. It no longer is.

With the Cyber Resilience Act, the new Product Liability Directive, DORA, and NIS2, a new regulatory landscape has emerged that directly captures you as a software developer — regardless of whether the finished product is distributed under your name or under your client's name. The obligations apply to you as developer, as supplier, as ICT third-party service provider.

Four laws, one responsibility #

Product Liability Directive (Directive 2024/2853) #

The new EU Product Liability Directive defines software expressly as a product for the first time (Art. 4 No. 1). Art. 8 expressly classifies as manufacturer anyone who develops or produces a product — not only those who distribute it. This means: if you write code that runs in production at a client's site, you are legally a developer and thus a potentially liable manufacturer. The Directive makes no exception for commissioned development.

Key changes compared to the old Directive of 1985:

Data loss is a new ground for liability (Art. 6(1)(c))
No cap on total liability (Art. 12)
Facilitation of burden of proof in cases of technical complexity in favour of the injured party (Art. 10)
Disclosure obligation for evidence (Art. 9)

Legal consequences of non-compliance: Unlimited damages towards injured parties — including third parties who are not your contractual partners. Liability exclusions in your client contracts do not protect against claims by end users. If your client becomes insolvent or is based outside the EU, injured parties can claim directly against you. Additionally, personal liability of management under general company law where duties of care were grossly violated.

In detail: Product Liability for Companies and The new EU Product Liability.

Cyber Resilience Act (Regulation (EU) 2024/2847) #

The CRA applies to all "products with digital elements" placed on the EU market (Art. 2(1), Art. 3 No. 1). The manufacturer definition under Art. 3 No. 13 also covers those who have a product "developed" and distribute it under their own name. Who the formal "manufacturer" is — you or your client — depends on the specific contractual relationship. The due diligence obligations are in any case passed on to you contractually: Art. 13(5) CRA requires "due diligence" when integrating FOSS components. Your client can only fulfil this duty if you perform it.

From 11 September 2026, reporting obligations for vulnerabilities and security incidents apply (Art. 14 CRA). From 11 December 2027, full application of all provisions.

Legal consequences of non-compliance: Fines of up to EUR 15 million or 2.5% of worldwide annual turnover (Art. 64 CRA). Loss of market access across the entire EU — products that do not meet the CRA may no longer be placed on the market, and already delivered products can be recalled (Art. 52, 53 CRA). Reporting obligations to the competent authority and ENISA for actively exploited vulnerabilities within 24 and 72 hours (Art. 14(1), 14(2) CRA).

In detail: CRA for Companies, What is the Cyber Resilience Act?, CRA — Relevant articles in original wording.

DORA (Regulation (EU) 2022/2554) #

As soon as one of your clients falls under DORA — banks, insurance companies, capital markets, funds, 21 categories in total — you automatically become an ICT third-party service provider within the meaning of Art. 2(1)(u) DORA. This is not a matter of your contract size but of the legal relationship.

What this means:

Your client must include you in an information register of all ICT third-party arrangements (Art. 28(3))
Before and during the contract: due diligence assessment of your security processes (Art. 28(4))
For critical functions: highest quality standards as a contractual obligation (Art. 28(5))
An exit strategy must be in place (Art. 28(8)) — your client must be able to demonstrate how to continue without you
In threat-led penetration tests (TLPT), you may be involved as a third-party service provider (Art. 26)
The supervisory authority may oblige your client to grant access to your processes

Legal consequences of non-compliance: You yourself are not a direct addressee of DORA fines, but your client is liable for up to 1% of their average worldwide daily turnover per day (Art. 50 DORA) — and will seek civil recourse against you if you were the cause. In practice, this means: loss of the entire financial market client segment if you do not meet the DORA requirements. No financial institution may continue to engage you if you fail the due diligence assessment. Additionally, for critical ICT third-party service providers, direct supervision by the European Supervisory Authorities (Art. 31 ff. DORA) with separate fines of up to 1% of worldwide daily turnover of the third-party provider.

In detail: DORA for Companies, What is DORA?, DORA — Relevant articles in original wording.

NIS2 (Directive (EU) 2022/2555) #

NIS2 obliges 18 sectors of critical and important infrastructure to secure their supply chain (Art. 21(2)(d)). This expressly includes the assessment of the security processes and development processes of direct suppliers (Art. 21(3)). As soon as your clients operate in one of these sectors — energy, health, transport, financial services, digital infrastructure, water supply, public administration, automotive, semiconductor manufacturing, and many more — you are a supplier within the meaning of the Directive.

Your clients must demand evidence from you: documented security processes, vulnerability management, secure development, incident response. If you cannot present these, your client is not compliant — and will act accordingly.

Legal consequences of non-compliance: For essential entities, fines of up to EUR 10 million or 2% of worldwide annual turnover; for important entities, up to EUR 7 million or 1.4%. The German transposition (NIS2UmsuCG, Section 38) additionally provides for personal liability of your clients' management — who will pass on any responsibility to suppliers that caused security deficiencies. For you as supplier, this means: loss of the client segment of all regulated sectors if you fail the supplier assessment. Additionally, reporting obligations via your clients within 24 hours (early warning) and 72 hours (notification) for significant security incidents (Art. 23 NIS2) — this also applies when the cause lies with you.

In detail: NIS2 for Companies, What is NIS2?, NIS2 — Relevant articles in original wording.

The fundamental misconception: "We are just building on commission" #

Those who develop software for clients often think that responsibility lies entirely with the client. This is wrong for three reasons:

First, the Product Liability Directive makes you directly a developer-manufacturer, regardless of what the contract states. Liability exclusions towards injured parties are not effective — the Directive protects end users and injured third parties, not contractual parties. If your client becomes insolvent or is based outside the EU, injured parties will claim directly against you.

Second, CRA obligations will inevitably be passed on to you contractually. Art. 13(5) CRA obliges manufacturers to exercise "due diligence" when integrating FOSS components. Your client cannot fulfil this duty themselves — they do not know which components you integrated. So they will contractually shift the due diligence to you. The same applies to vulnerability handling (Art. 14 CRA), vulnerability reporting, and SBOM provision.

Third, DORA and NIS2 regulate the supply chain directly. As a developer, you are part of that supply chain. The regulatory burden does not fall away simply because you work "only on commission". On the contrary: the less you communicate, the harsher the due diligence assessment by your clients will be.

What does this mean concretely for you? #

You must establish processes that previously only product companies had:

SBOM maintenance for every project you deliver, including transitive dependencies
Vulnerability management — you must know which vulnerabilities become known in the components you use and be able to respond. Scanners only show registered CVEs — silent fixes remain invisible
Responsible disclosure process — a channel where security researchers can report vulnerabilities (security.txt, documented process)
Documented security strategy — written, verifiable, presentable during client audits and to supervisory authorities
Incident response capacity — in the event of security incidents in your clients' projects, you must be able to respond quickly, including outside business hours
Secure development according to the state of the art (ISO/IEC 27001, ISO/IEC 18974) — as a documented measure, not just an aspiration
Evidence of the suitability of deployed FOSS components — where they come from, how they are maintained, who ensures their security

Most service providers have none of this in documented form. This is not negligent — it is simply the previous industry norm. But the norm has changed.

Beyond obligation: security as a competitive advantage #

Even if you were not directly affected by CRA, DORA, or NIS2 today — and in practice that is rare — it would still be wise to build these processes. The reason is simple: responsibility and professionalism set you apart in the market.

Your clients compare providers. Those who can demonstrate that they know their supply chain, actively fix vulnerabilities, respond to reports, and document every decision appear not just compliant — but mature. In a market where many service providers rely on "we'll manage somehow", that is a tangible differentiator.

Concretely, this means:

Better close rates with demanding clients. Today, procurement departments of large companies and public authorities have a questionnaire on supply chain security on their desks. Those who can answer fully stay in the running. Those who evade are eliminated.
Higher day rates, because you are not perceived as an interchangeable implementation resource but as a partner who shares responsibility for the outcome.
Less friction in the project, because security topics no longer need to be retrofitted in live operations but are part of the process.
Insurance advantages: cyber and liability insurers increasingly assess documented security processes positively in premium calculations. Without such evidence, premiums rise or contracts are refused entirely.
Brand protection: a single publicly known incident can destroy years of sales effort. Being prepared prevents exactly this case — and allows you to demonstrate how you acted in an emergency.
Talent attraction: developers prefer working where clean processes exist. Sloppy practices frustrate your best people first.

The good news: the same processes you need for regulation also make you better in the market. Compliance and quality converge here. What you invest to make your clients compliant, you simultaneously invest in your own profile.

Which category are you? #

The specific requirements differ depending on the nature of your work. Choose your entry point:

Agencies — web, digital, creative, and e-commerce agencies. Websites, mobile apps, campaigns, shops, customer portals.

System houses — IT system houses and traditional integrators. Heterogeneous client landscapes, infrastructure, operations, customising.

Software development — custom software, app development, embedded software. Core software for client business processes.

Platform partners — SAP, Salesforce, Microsoft partners, CMS integrators, e-commerce specialists. Custom extensions on third-party platforms.

MSP and cloud service providers — managed service providers, cloud integrators, DevOps service providers. Operations plus tooling plus custom solutions.

How OTTRIA helps #

OTTRIA is a European service provider that systematically secures the open source supply chain. For software service providers, we take over the processes you need to fulfil your new obligations:

SBOM analysis and maintenance for all projects you deliver
Vulnerability management including silent fix detection
Responsible disclosure channel for your projects
Audit-ready documentation for clients and supervisory authorities
Bug fixing directly in the open source project for FOSS components you use
Steward role for particularly critical components of your clients

You remain the point of contact for your client. OTTRIA works in the background and delivers the evidence you need.

Schedule initial consultation

All OTTRIA services at a glance