1. Cybersecurity on the European agenda
The Cyber Resilience Act (CRA). constitutes the European Union's latest initiative in the field of cybersecurity. This regulation follows on from previous legislation, such as the NIS 2 directive and the DORA Regulation for the financial sector.
The CRA aims to counter the growing cyber threat and requires manufacturers of hardware and software products to address cybersecurity throughout the life cycle of their products. The CRA aims for a higher level of cybersecurity for all products with digital elements - from smartwatches to smart industrial devices.
What makes the CRA special is its broad scope and explicit application to software - including open source components. The CRA imposes extensive obligations on manufacturers, including software developers. Even smaller companies or developers using open source software face new rules and risks. In this post, we explain the main challenges.
2. A broad and horizontal scope that extends to the smallest software developer
The CRA applies to "products with digital elements," which includes software products marketed independently.
Interestingly, the CRA does not distinguish by sector or company size. This means that not only large tech companies, but also small-scale developers of apps or ERP systems, for example, are covered by the CRA. The CRA applies only to software products, so software provided as a service (such as pure SaaS) with no link to a physical product is not affected. Software developed for internal use only (such as a proprietary CRM application) is also excluded.
The CRA applies only to products that are commercialized. This is also met for products offered free of charge if the processing of personal data is imposed for reasons other than the security, compatibility or interoperability of the software. Exceptions only apply to products already covered by other industry regulations, such as medical diagnostic software, aviation software and maritime navigation software.
Small software developers are also covered by the obligations, which in practice means a significant legal as well as financial challenge for many smaller companies without compliance departments.
3. Open source software: partially off-limits, but not exempt
The use of open source software has become indispensable in software development in recent years. Open source software is software where the source code is made freely available (usually for free) for use and modification.
Open source software falls under the CRA only when the offering is considered a commercial activity. This is the case when the provider has commercial intentions (e.g., when a fee is charged for supporting open source software or when a financial benefit is derived from processing personal data through the open source software). In any case, the CRA does not apply to purely free provision of open source software (regardless of the commercial intentions of the users).
The CRA also introduces a new entity: the "open source software steward." This steward, usually a foundation or association that structurally supports the development of open source software, will be subject to a lighter regime. Among other things, they must create a cybersecurity policy and report vulnerabilities to the appropriate authorities.
The concrete interpretation of this stewardship remains unclear. The supervision and interpretation of the concept may also differ from one member state to another, leading to a risk of fragmentation within the EU. The obligations for stewards are lighter, but not non-binding: although fines cannot be imposed, corrective measures are possible.
4. Duty of care for external components
Manufacturers integrating third-party software components must verify that those components meet certain security requirements. This duty of investigation and due diligence includes:
- verifying that a component is CE marked;
- checking for regular security updates;
- Testing for known vulnerabilities (e.g., in public databases);
- Conducting additional safety tests as needed.
This due diligence also applies to open source components. In practice, this is difficult. Many manufacturers integrate open source without checking the source code for any security risks. It is often unclear who the developer is within an open source project. Yet the responsibility remains with the manufacturer. The responsibility cannot be passed on to the developer of the open source component.
Manufacturers may be able to include indemnification clauses in their agreements with software vendors regarding exploited vulnerabilities, but such contractual indemnification is usually impossible with open source software. Collaboration with stewards will therefore be important.
5. Mandatory five-year maintenance period
Manufacturers are required to provide security updates for a maintenance period of at least five years, unless the expected life of the product is shorter. These updates must include open source components within the product.
This means that developers must design their products with long-term maintenance in mind. Business models will have to change: software may no longer be delivered "as is." Long-term support must be planned in advance and will have a financial impact. Although security updates must be free of charge to the user, manufacturers will have to recover these costs elsewhere such as through an increase in license fees.
6. Harmonized standards and attestation.
The CRA provides for the development of harmonized European standards for software cybersecurity. These standards will be produced by standardization bodies (think CEN-CENELEC) and should help manufacturers comply with legal requirements. Voluntary security attestations can be introduced for open source software.
Although the use of these standards is voluntary, a presumption of conformity arises with compliance. Thus, developers will be inclined to conform to these standards.
The content of the standards is not yet known. The challenge lies in not ignoring existing best practices - especially from open source communities such as Linux and Eclipse. Moreover, there is a need for continuous updating of standards to address new threats.
7. Conclusion
The CRA takes an important step toward a more secure digital Europe, but demands a lot from software developers. Especially in the context of open source software and small-scale companies, the practical applicability of some obligations is still uncertain.
Software developers - large and small - face higher compliance costs, new liability risks and mandatory maintenance. Open source projects are only partially spared, but new responsibilities arise there as well. The CRA requires developers to increase collaboration, documentation and risk analysis.
Although the CRA provides for nuance and exceptions, the core message remains clear: cybersecurity is henceforth no longer a casual option, but a legal obligation. The impact of the CRA on the European software industry will be felt. Those active in software development would do well to prepare in time for these new obligations that will apply from 2026.
As a law firm specializing in technology and ICT law, we follow these developments closely. We assist software developers, distributors as well as open source stewards in complying with their legal obligations under the CRA.
Dutch 
English