Voices

Voices on the Cyber Resilience Act.

The objective of the Cyber Resilience Act enjoys broad support: products with digital elements are to be developed more securely, and vulnerabilities are to be handled effectively throughout their life cycle. The debate centres mainly on how the extensive requirements can be implemented in practice – particularly by SMEs, manufacturers with large product portfolios and open-source organisations.

Why the CRA is supported

Before the CRA, there was no comprehensive horizontal EU legal framework with binding cybersecurity requirements for products with digital elements. Recital 1 identifies as the central problems the low level of cybersecurity of many products, widespread vulnerabilities, and security updates that are provided insufficiently and inconsistently. Added to this is a lack of information, which makes it harder for users to select suitable products and use them securely.

The CRA therefore places greater responsibility on manufacturers: security requirements are to be taken into account as early as the development and production stages, and vulnerabilities are to be handled throughout the support period.

The German Federal Office for Information Security (BSI) supports practical preparation with its Technical Guideline TR-03183. Its three parts cover general requirements for manufacturers and products, formal and technical requirements for an SBOM, and the handling of incoming vulnerability reports. The guideline is being developed on an ongoing basis.

The TÜV Association (TÜV-Verband) likewise welcomed the introduction of binding requirements in principle. Johannes Kröhnert stated on 1 December 2023 (translated from German):

“It is right and important to finally introduce mandatory requirements for the cybersecurity of connected products in the EU.”

At the same time, the association called for a more ambitious set of rules and faster application.

Where criticism is directed

During the legislative procedure, open-source organisations warned against unintentionally impairing established forms of collaborative software development. A statement signed by the Eclipse Foundation, the Linux Foundation Europe and other organisations called for the particular characteristics of free and open-source software to be given greater consideration.

The adopted Regulation therefore distinguishes between free and open-source software that is made available on the market in the course of a commercial activity, and non-commercial open-source development. Under Art. 24, open-source software stewards within the meaning of Art. 3(14) CRA are subject to a separate framework of obligations tailored to their role. Not every foundation, association or open-source project is automatically such a steward.

Industry associations also support the objective of uniform cybersecurity requirements but point to difficulties in implementation. Bitkom calls, among other things, for realistic timelines, harmonised standards that are available in good time, clear transitional arrangements and a practicable treatment of existing products. The ZVEI warns in particular of the scale of the adjustments required for large product portfolios and of possible effects on supply chains.

What this means for SMEs

The effort involved cannot be expressed as a single, universally applicable figure. It depends, among other things, on the number and complexity of the products, the existing development and security processes, the supply chain and the conformity assessment procedure required.

For SMEs, it is therefore crucial to clarify at an early stage to what extent the CRA applies to them, to record products and responsibilities, and to establish processes for SBOM, vulnerability handling, reporting and technical documentation. Existing security and quality processes can continue to be used, but must be checked against the specific CRA requirements.

Our assessment

The CRA establishes a binding framework for the cybersecurity of products with digital elements. For manufacturers, this means additional organisational and technical effort. At the same time, it produces traceable processes and records that can also be helpful in responding to customer enquiries, supplier audits and internal approvals.

Depending on your location and project, support may be available from consulting, innovation or digitalisation programmes. We list open and announced programmes in our funding overview, which is reviewed every two weeks.

View current funding programmes →

Methodology

This assessment is based on the official text of the Regulation and the publications linked below. Statements by associations and organisations reflect the position of their respective publishers. The published text of the Regulation remains authoritative.

Sources: