Learn how the Cyber Resilience Act affects open source software. Obligations for FOSS stewards, risk categorization, and the CRA’s impact explained.
Special treatment of FOSS in the CRA
The CRA recognizes the special role and importance of open source software. In general, FOSS is placed in the self-assessment category, which means that most FOSS projects face less stringent requirements than comparable proprietary products.
Who is affected?
To understand whether and how an open source project is affected by the CRA, consider the following diagram:
Flowchart for determining CRA applicability to FOSS projects
Explanation of the main points:
- Providing vs. contributing: The CRA distinguishes between offering or providing FOSS and merely contributing to it. Only providers fall within the scope.
- Direct monetization: FOSS providers who directly earn money from it are considered “manufacturers” under the CRA.
- Support for commercial activities: Legal entities that continuously support the development of FOSS products for commercial activities, without directly monetizing them, fall into the category of stewards of open source software.
- Development within commercial activities: If development takes place as part of a commercial activity (in the broad sense), the entity is also considered a “manufacturer”.
The role of the ‘open source software steward’
The CRA introduces the term ‘open source software steward’. This is a lighter regulatory approach for legal entities that support FOSS projects without directly monetizing them. Examples include:
- Foundations that support specific FOSS projects
- Companies that develop FOSS for their own use but make it publicly available
- Nonprofit organizations that develop FOSS
Obligations for stewards of open source software
The obligations for stewards of open source software are less extensive than for “manufacturers”, but still include important points:
- Cybersecurity policy: Stewards must implement a cybersecurity policy that takes into account the specific nature of their role as stewards of open source software. This policy should address the particular challenges and risks associated with developing and providing open source software.
- Cooperation with authorities: Stewards are expected to cooperate with market surveillance authorities. This may include responding to inquiries about security aspects of the software, providing information, or assisting with investigations.
- Reporting incidents and vulnerabilities: Stewards are required to report security incidents and discovered vulnerabilities insofar as they are involved in the development. This promotes transparency and enables a faster response to potential security risks.
Risk categorization of products
The CRA provides for a risk categorization for products with digital elements:
- Standard category (self-assessment): This includes most FOSS projects, as well as products like storage chips, mobile apps, smart speakers, and computer games.
- Important products: These require the application of standards or assessments by third parties. Examples are operating systems, antivirus software, routers, and firewalls.
- Critical products: In the future, this category may require certification. Examples include smartcards, secure elements, and smart meter gateways.
It is important to note that FOSS generally falls into the self-assessment category unless it is classified as a “critical product”.
Further information on conformity assessment can be found in our detailed article on the Cyber Resilience Act.
Assessment and outlook
The CRA attempts to strike a balanced approach for open source software. While commercial FOSS providers are subject to obligations similar to those of proprietary software manufacturers, there is a lighter regulatory approach for non-commercial FOSS projects and supporters.
The introduction of the category of open source software steward shows that lawmakers recognize the special role and importance of FOSS and aim to avoid unnecessary burdens. Nevertheless, certain measures to ensure cybersecurity are expected from FOSS projects.
FOSS developers and organizations should familiarize themselves with the CRA requirements and determine which category they fall into. In particular, they should consider developing an appropriate cybersecurity policy and establishing processes for cooperation with authorities and for reporting security incidents.
