Software Development Houses

You develop custom software, mobile and desktop applications, backend systems, APIs, embedded software, and often critical core applications for your clients. Your work is rarely visible from the outside, but from a regulatory perspective you are at the centre: you produce code that carries business processes.

No other group is so clearly captured by the new regulation. The Product Liability Directive expressly names developers as manufacturers (Art. 8), the CRA treats every developed software as a product with digital elements (Art. 3 No. 1), and as a supplier of critical business functions, you are directly embedded in DORA and NIS2 supply chains.

Typical projects and their regulatory classification #

Custom software for business processes #

Whether you develop an inventory management system, a production control system, an accounting module, or an industry solution — this software is a product with digital elements under the CRA. Your clients operate it as a core component of their business. If it fails or contains vulnerabilities, product liability applies directly.

For DORA clients, such software is often classified as a "critical function" (Art. 28(5) DORA) — with correspondingly heightened requirements for quality, documentation, and exit capability.

Mobile apps for end customers and employees #

Apps are clear CRA products. When built for regulated clients — banking apps, insurance apps, health apps — DORA or NIS2 apply additionally. Apps that process payments, authentication, or health data also fall into the "critical" CRA category under Annexes III and IV of the Regulation.

Backends, APIs, and microservices #

Backend development is often invisible but regulatorily the most problematic: backends process the most sensitive data and carry the central business processes. A faulty backend can shut down an entire operation or compromise data at scale — Art. 6(1)(c) of the Product Liability Directive (data loss as ground for liability) addresses exactly these cases.

Embedded software #

Embedded development for industry, medical devices, automotive, or energy falls under the new laws in multiple dimensions: CRA as software in products, product liability as part of a safety-relevant product, NIS2 as supply to critical sectors. Typically, sector-specific requirements apply additionally — such as the Machinery Regulation, IEC 62443, MDR, or UN-R 155.

Core banking, insurance core, health systems #

When you develop core systems for financial institutions, insurance companies, or hospitals, you work at the most stringently regulated end of the spectrum. DORA treats such systems as "critical ICT services" (Art. 28(5)), supplier management is maximal. You will be prominently listed in your client's DORA information register.

Which laws apply for which clients #

Two laws always apply, regardless of who you develop for:

Product Liability Directive (Directive 2024/2853) makes you as developer a manufacturer (Art. 8). Data loss is an independent ground for liability (Art. 6(1)(c)), liability is uncapped (Art. 12), and the burden of proof is facilitated in favour of injured parties (Art. 10). No contract with the client protects you from direct claims by third parties.
Cyber Resilience Act (Regulation (EU) 2024/2847) covers every software you develop as a "product with digital elements" (Art. 3 No. 1). You are subject to due diligence obligations for FOSS integration (Art. 13(5)), vulnerability handling (Art. 14), and at least five years of support.

Because software development houses often deliver central core applications, DORA and NIS2 additionally come into play via the client side:

Financial sector (banks, insurance companies, funds, payment service providers, crypto-asset service providers) brings DORA in full force. Art. 28 DORA with information register, due diligence, exit strategy, TLPT involvement.
Healthcare (hospitals, laboratories, medical device manufacturers, digital health applications) brings NIS2 plus MDR burden plus particularly high data protection requirements.
Energy and utilities (municipal utilities, transmission system operators, gas suppliers) bring NIS2 as essential entities.
Industry (automotive, mechanical engineering, semiconductors, chemicals) brings NIS2 as important entities, often combined with product safety requirements under the Machinery Regulation.
Public administration and federal authorities bring NIS2 and often additional BSI-specific requirements (ITSiG, BSI-KritisV).
Telecommunications and digital infrastructure are NIS2 sectors.

Even without regulated end clients, the Product Liability Directive applies to all your commissioned development. The notion that "that's the client's concern" does not hold legally.

Concrete consequences #

Legally at stake:

Unlimited liability under the Product Liability Directive — for software houses regularly the most economically dangerous point, because your software often carries core processes and errors can have catastrophic consequences
Fines of up to EUR 15 million or 2.5% of annual turnover under CRA (Art. 64)
Loss of EU market access: software that does not meet the CRA may no longer be placed on the market, existing deliveries can be recalled (Art. 52, 53 CRA)
24/72-hour reporting obligations for actively exploited vulnerabilities and security incidents (Art. 14 CRA, Art. 23 NIS2, Art. 19 DORA)
Facilitation of burden of proof under Art. 10 Product Liability Directive when due diligence documentation is missing — in doubtful cases, against you
Loss of regulated client segments such as financial service providers, healthcare providers, or critical infrastructure operators
Direct DORA supervision of up to 1% of worldwide daily turnover for critical ICT third-party service providers (Art. 50 DORA)

Contractually, your clients will demand:

Development processes according to the state of the art (ISO/IEC 27001, ISO/IEC 18974 "Open Source Ready"), documented and auditable
SBOM for every delivery, including all dependencies
Secure coding, code reviews, documented testing strategies
Vulnerability handling under Art. 14 CRA with clear response times
Responsible disclosure process, publicly reachable
For DORA clients: inclusion in information register, due diligence support, exit strategy, TLPT participation

Operationally, you must establish:

SBOM automation in the CI/CD pipeline
Continuous monitoring of all deployed components across the entire lifecycle of delivered software
Patch provision and communication to clients, even years after project completion (the CRA support period is at least five years)
Incident response with 24/7 availability for DORA clients
Evidence preservation and documentation of all security decisions for possible audits or liability cases

Financially, you face:

Building or procuring security engineering capacity
Ongoing maintenance costs for delivered software that you can no longer fully allocate to new client projects
Insurance premiums that rise steeply without demonstrable processes
Unlimited liability under the Product Liability Directive

Security is a competitive advantage even without obligation #

Those who develop core software compete against other development houses that sound similarly capable in a pitch. The differentiator arises where professionalism becomes demonstrable: documented SBOM, traceable vulnerability management, a functioning responsible disclosure process, development according to ISO/IEC 18974.

This is not just compliance — it is a quality signal that works in sales: better close rates with demanding clients, higher day rates, more favourable insurance premiums, stronger client retention. Your best developers prefer working where processes are clean. The investment pays off multiple times — even without regulatory pressure.

How OTTRIA supports software developers #

No development house can carry the security of all deployed open source components internally. Modern projects have hundreds to thousands of transitive dependencies in often multiple programming languages. OTTRIA takes over this part:

SBOM analysis and maintenance across all your projects and versions, including transitive dependencies
Real-time vulnerability monitoring, focused on components actually deployed in your projects
Silent fix detection through active code analysis and commit monitoring
Bug fixing directly in the open source project for components that have no active maintainer or that you cannot fix yourself
Early warning through OTTRIA's role as Open Source Steward — you learn about critical vulnerabilities before the public CVE disclosure
Responsible disclosure channel for your products as a service
Audit-ready documentation per project and per client, presentable during DORA and NIS2 supplier assessments
Support for exit strategies — OTTRIA's public work in open source projects remains available even when you exit a project

You focus on what is your core business: developing software. OTTRIA delivers the open source due diligence part that no development house can handle alone.

Schedule initial consultation

Back to overview for software service providers