A Brussels guide specifies the Cyber Resilience Regulation. Manufacturers and open-source projects gain legal certainty before reporting obligations begin.
Before the first reporting obligations of the Cyber Resilience Act (CRA) take effect, the EU Commission is providing manufacturers, developers, and companies with a guide. The guide, published on Monday, explains in about 80 pages how the cybersecurity regulation is to be interpreted. This ranges from defining affected products and essential software updates to rules for open source. The CRA itself has been in force since December 2024 and stipulates uniform minimum requirements for the cybersecurity of digital products across the EU throughout their entire lifecycle.
According to the Commission, the handbook answers key questions from the industry. It is intended to help those affected to implement the requirements legally. The guide explains, for example, which products fall under the CRA, how crucial program revisions are to be classified, and by what standards support periods are to be determined.
In addition, it provides information on how risk analyses and reporting obligations can be practically fulfilled. The EU Commission places particular emphasis on startups and small and medium-sized enterprises. Numerous practical examples and application scenarios are intended to clarify ambiguities and avoid unnecessary administrative effort.
Open source should not be slowed down
The Commission devotes considerable space to free and open-source software. During the negotiations on the CRA, developers and open-source foundations warned that voluntary projects could be discouraged by new liability and documentation requirements.
The Commission is trying to allay these fears. Freely available open-source software generally does not fall under the CRA as long as it is not brought to market as part of a commercial activity. It now explains when such an activity exists. Anyone who sells open-source software, offers paid enterprise versions, or monetizes other services through a program is considered a manufacturer in the sense of the CRA.
The situation is similar if users are required to provide personal data for purposes other than security or interoperability, or if donations are effectively a prerequisite for accessing the software or essential updates. Conversely, voluntary contributions, public funding, or sponsorship funds alone do not constitute commercial activity. Paid consulting, training, or support services also do not automatically mean that an open-source project falls under the CRA – as long as the software itself remains freely available.
What exactly are open-source stewards?
Further clarification will likely be important for many developers. The Commission explicitly distinguishes between project managers and suppliers. Those who merely fix bugs or submit new features generally bear no responsibility under the CRA. The situation is different for individuals or organizations that publish a project and exercise control over releases, roadmaps, and steering. Merely having write access to the source code repository is not sufficient for this.
The role of “stewards” also becomes clearer. This can include foundations or other organizations that provide permanent organizational or technical support for open-source projects without marketing them themselves. Their obligations depend on the intensity of their involvement: Those who only handle community work have significantly fewer obligations than organizations that operate infrastructure or actively participate in development and security management. Depending on the type of support, reporting obligations for security incidents or exploited vulnerabilities may also apply to stewards.
Furthermore, the Commission explains when a change to a product is considered “essential”. Updates that exclusively fix vulnerabilities or maintain or improve the existing security level generally do not trigger a new conformity assessment procedure. The situation may be different if new features alter a product’s risk profile or create additional attack surfaces. The guide also provides clarity on repairs: If only identical replacement parts are supplied, this is not considered a re-release of the product.
The clock is ticking
The guide also specifies requirements, for example for risk analyses and future reporting obligations. Although the guide is not legally binding, it is likely to be decisive for manufacturers and national market surveillance authorities on how the regulation will be interpreted in practice. The German government has designated the Federal Office for Information Security (BSI) for this purpose.
EU Commission Vice-President Henna Virkkunen described the handbook as part of Brussels’ relief agenda. It is intended to help companies implement their new obligations on time and legally. A secure Europe and a business-friendly Europe go hand in hand. In the Commission’s view, the CRA is gaining importance due to the advances in powerful AI models with cyber capabilities. The first reporting obligations will take effect on September 11, 2026. Manufacturers must fully comply with the regulation from December 11, 2027.
This article was originally published in German. It was translated with technical assistance and editorially reviewed before publication.
Paywall, here are the contents
Cyber Resilience Act: EU Commission provides more clarity for open source
Source: heise online
Author: vbr
Before the first reporting obligations of the Cyber Resilience Act (CRA) take effect, the EU Commission is providing manufacturers, developers, and companies with a guide. The guide, published on Monday, explains in about 80 pages how the cybersecurity regulation is to be interpreted. This ranges from defining affected products and essential software updates to rules for open source. The CRA itself has been in force since December 2024 and stipulates uniform minimum requirements for the cybersecurity of digital products across the EU throughout their entire lifecycle.
According to the Commission, the handbook answers key questions from the industry. It is intended to help those affected to implement the requirements legally. The guide explains, for example, which products fall under the CRA, how crucial program revisions are to be classified, and by what standards support periods are to be determined.
In addition, it provides information on how risk analyses and reporting obligations can be practically fulfilled. The EU Commission places particular emphasis on startups and small and medium-sized enterprises. Numerous practical examples and application scenarios are intended to clarify ambiguities and avoid unnecessary administrative effort.
Open source should not be slowed down
The Commission devotes considerable space to free and open-source software. During the negotiations on the CRA, developers and open-source foundations warned that voluntary projects could be discouraged by new liability and documentation requirements.
The Commission is trying to allay these fears. Freely available open-source software generally does not fall under the CRA as long as it is not brought to market as part of a commercial activity. It now explains when such an activity exists. Anyone who sells open-source software, offers paid enterprise versions, or monetizes other services through a program is considered a manufacturer in the sense of the CRA.
The situation is similar if users are required to provide personal data for purposes other than security or interoperability, or if donations are effectively a prerequisite for accessing the software or essential updates. Conversely, voluntary contributions, public funding, or sponsorship funds alone do not constitute commercial activity. Paid consulting, training, or support services also do not automatically mean that an open-source project falls under the CRA – as long as the software itself remains freely available.
What exactly are open-source stewards?
Further clarification will likely be important for many developers. The Commission explicitly distinguishes between project managers and suppliers. Those who merely fix bugs or submit new features generally bear no responsibility under the CRA. The situation is different for individuals or organizations that publish a project and exercise control over releases, roadmaps, and steering. Merely having write access to the source code repository is not sufficient for this.
The role of “stewards” also becomes clearer. This can include foundations or other organizations that provide permanent organizational or technical support for open-source projects without marketing them themselves. Their obligations depend on the intensity of their involvement: Those who only handle community work have significantly fewer obligations than organizations that operate infrastructure or actively participate in development and security management. Depending on the type of support, reporting obligations for security incidents or exploited vulnerabilities may also apply to stewards.
Furthermore, the Commission explains when a change to a product is considered “essential”. Updates that exclusively fix vulnerabilities or maintain or improve the existing security level generally do not trigger a new conformity assessment procedure. The situation may be different if new features alter a product’s risk profile or create additional attack surfaces. The guide also provides clarity on repairs: If only identical replacement parts are supplied, this is not considered a re-release of the product.
The clock is ticking
The guide also specifies requirements, for example for risk analyses and future reporting obligations. Although the guide is not legally binding, it is likely to be decisive for manufacturers and national market surveillance authorities on how the regulation will be interpreted in practice. The German government has designated the Federal Office for Information Security (BSI) for this purpose.
EU Commission Vice-President Henna Virkkunen described the handbook as part of Brussels’ relief agenda. It is intended to help companies implement their new obligations on time and legally. A secure Europe and a business-friendly Europe go hand in hand. In the Commission’s view, the CRA is gaining importance due to the advances in powerful AI models with cyber capabilities. The first reporting obligations will take effect on September 11, 2026. Manufacturers must fully comply with the regulation from December 11, 2027.
This article was originally published in German. It was translated with technical assistance and editorially reviewed before publication.