Cyber Resilience Act: Trilogue negotiations

| CYBERSICHERHEIT

Cyber Resilience Act

September 2023

Executive Summary

With the adoption of the General Approach by the European Council on July 13, 2023 and the adoption of the ITRE Committee’s report on July 19, 2023, the co-legislators have now formulated their opinions on the EU Commission’s proposal for the Cyber Resilience Act. German industry continues the European Union’s (EU) aspiration to enhance Europe’s cyber-resilience holistically by introducing cybersecurity requirements for all products with digital elements. For the upcoming interinstitutional negotiations, German industry encourages all policymakers to stick to the principles of proportionality and practicality of the requirements. Instead of introducing over-arching bureaucratic requirements, the colegislators should aim at risk-based solutions that help significantly enhance Europe’s cyber-resilience. On the one side, such an approach would support essential and important entities in their steps to implement the requirements under the NIS 2-Directive; while on the other side it would ensure that manufacturers of products with digital elements can dedicate their efforts into developing and producing cyber-resilient products rather than in fulfilling administrative duties.

The CRA should create a simple, coherent, and effective legal framework that horizontally regulates the cybersecurity of all covered products when placed on the market. It should be designed in such a way that existing, product-specific regulations are not taking precedence according to the “lex specialis” principle. This includes existing and upcoming legislation (e.g., RED Delegated Regulation, Machinery Regulation, Artificial Intelligence Act). Simplification of the existing legal framework is crucial to allow a correct implementation by all stakeholders to strengthen cyber resilience.

Our top seven recommendations at a glance:

 Art. 2 covers all products that possess an indirect logical or physical data connection. This broad scope of application of the CRA will lead to significant problems and delays in implementation, especially in standardization, and consequently in conformity assessment. Limit the scope to products connected to a public telecommunication network, at least in the first step.

 The CRA should equally address harmonised standards, common specifications, and certification schemes with respect to the presumption of conformity. CSA schemes and common specifications need to be subject to the same test procedure and assessment with regard to the coverage of essential requirements of the CRA as harmonised standards.

 Exclude “security updates” and “minor functionality updates” from the definition of substantial modification, to ensure a swift dissemination of such updates among users and thereby to maintain the cyber-resilience of such products;

German industry’s recommendations for the trilogue negotiations

 Exclude spare parts for products, which have been placed on the internal market before the coming into effect of the CRA as well as for products for which the update period guaranteed by the manufacturer when placing them on the market has expired, from the scope of the CRA;

 Cover only products made available on the European market in the course of a commercial activity. This ensures that the “downstream” usage of Open-Source products is as well covered by the CRA. Companies must be able to benefit from the Open-Source community’s input;

 Allow manufacturers of products with digital elements to define and transparently communicate a support period that suits their product rather than introducing a one-size-fits-all timeframe, and

 Prolong the implementation period to at least 36 months. However, we would have appreciated a further extension to 48 months.

 Nota bene: BDI’s paper takes as a baseline the assumption that only those points that have been raised by any of the three co-legislators have a chance to be included into the Regulation’s final wording. Therefore, we do not flag again those points that we would have appreciated to be changed, introduced or deleted but rather compare the available three options and outline our preferred one, even if this option does not mirror our preferences as stated in earlier position papers. Moreover, we only highlight selected articles, which are of particular concern for German industry. The European co-legislators must ensure that the trilogue’s outcome enhances Europe’s cyberresilience while maintaining the necessary risk-based approach.

Deep Dive: German industry’s recommendations for the trilogue negotiations

Recital 1

preferred option: European Parliament

German industry appreciates the insertion of “address cyber resilience at Union level”. Introducing cybersecurity requirements at Union-, rather than at Member State-level is paramount to ensure uniform product-related requirements across the single market since thereby manufacturers and developers of products with digital elements, as well as users of such products, benefit from economies of scale.

Recital 4a

preferred option: European Parliament

German industry welcomes the clarification that the specificities of each sector shall be taken into account, that the requirements and implementation measures shall be proportionate and that the European Commission shall issue guidelines, way before the mandatory application that help all stakeholders, including but not limited to small and medium enterprises (SMEs), when implementing the Cyber Resilience Act. Thereby, the CRA will cater to the needs of specific sectors, will not impose unduly high requirements, and ensures that SMEs receive the guidance necessary for a speedy and hassle-free implementation.

Recital 9

preferred option: European Parliament

German industry welcomes the Parliament's decision against the categorical exclusion of SaaS from the scope of the CRA. SaaS should remain in the scope of the regulation, as the secure provision of SaaS integrated or interconnected with a digital product is becoming increasingly essential to determine the cyber-resilience of that product. However, regulatory clarity in relation to the NIS 2 Directive is paramount to avoid double regulation. Moreover, we appreciate that cloud enabled functionalities provided by the manufacturer of smart home devices that enable users to control the device at a distance, shall fall under the CRA’s scope as they are an integral dimension of respective solution.

Recital 9b

preferred option: European Council

German industry appreciates the wording introduced in recital 9b (new) that Member States cannot impose further cybersecurity requirements for the making available on the market of products with digital elements. This will help manufacturers and developers of such products to offer their products across the EU Member States without having to adapt them to local requirements. But we also look with concern at the sentence setting out the possibility for member states to impose additional or stricter cybersecurity requirements for the use of ICT products by essential or important entities under the scope of the NIS-2-directive (EU) 2022/2555, as such requirements could contradict the Cyber Resilience Act’s harmonisation effort. We recognise that the NIS-2-directive gives member states the competence to do so, but looking at the wide range of affected entities, especially under the new category of important entities, which includes the main part of manufacturing companies, we urge legislators to limit the use of this competence. Otherwise, this would lead to fragmentation, which should be avoided

Recital 10

preferred option: European Council in conjunction with European Parliament

German industry welcomes the wording introduced by the European Council stressing that only products made available on the European market in the course of a commercial activity (“downstream”) fall under the CRA: We very much appreciate that the Council’s text – unlike the ones proposed by the European Parliament and the European Commission – does not focus on Open-Source Software but is technology-neutral. Like other compliance obligations, cybersecurity obligations shall remain with the companies that place Free and Open-Source Software on the market and use it commercially (“downstream”), not with the developers who make Free and Open Source Software available for free in the form of source code (“upstream”), regardless of whether the developer is employed by a commercial company or not.

With regards to distribution and hosting, though, German industry would prefer, if the co-legislators were to agree on the European Parliament’s version. The sole act of hosting free and open-source software on open repositories does not in itself constitute making available on the market of a product with digital elements. As such, most package managers, code hosting and collaboration platforms should not be considered as distributors under the meaning of this Regulation. Taking account of the above-mentioned elements determining the commercial nature of an activity, this Regulation should only apply to free and Open-Source Software that is supplied in the course of a commercial activity.

Recital 14a

preferred option: European Parliament

German industry appreciates the exclusion of spare parts for products, which have been placed on the internal market before the coming into effect of the CRA as well as for products for which the update period guaranteed by the manufacturer when placing them on the market has expired, from the CRA. It is already significant progress, that both, the European Parliament’s as well as the European Council’s positions foresee an exemption for spare parts, but further improvements seem necessary, because the exemption should address products and components and should focus on the supply not the exclusive manufacturing of the spare part. The proposal of the European Parliament is already quite good, but it could be further optimised, to be sufficient to repair products using spare parts that are in conformity with the state of the art that was applicable at the point in time the product to be repaired was placed on the market. The vulnerability handling process will safeguard, that the repaired product is updated to the latest available version.

When the manufacturer still provides updates for the product with digital elements, e.g. because the support period of the product hasn’t ended yet, spare parts should also be provided with such updates. Looking at the B2B-context, we expect that this, including the delivered update-version needed, will be solved in the respective contractual agreements regarding the security support or the provision of spare parts. However, should the update period – guaranteed at the moment when the product had been initially placed on the marked, has expired, the offering of spare parts should not re-commence the update period.

If spare parts had to be delivered in conformity with the latest state of the art, there was a significant high risk, that manufacturers cannot implement the requirements and therefore will not deliver such spare parts anymore. It is crucial, that manufacturers are not obliged to extend the free of charge provision of updates for the duration, during which they would be able to provide users with spare parts. Thereby, the CRA will contribute to sustainability goals, since products can be utilised for a longer period of time.

Products with digital elements that have been placed on the internal market before the entry into force of the Cyber Resilience Act must be exempt from the requirements set out in this regulation. This must also apply for spare parts that are supplied for products that have been placed onto the market before the entry into force of this regulation but where the spare part is sold after the entry into force of the regulations. Such a step is necessary, since manufacturers and developers of products with digital elements cannot be required to anticipate the CRA’s requirements.

Recital 15

preferred option: European Parliament

In the light of the ongoing challenges for the standardisation of the Radio Equipment Directive (RED) delegated act (DA), which may require the mandatory use of notified bodies starting in 2025, German industry appreciates Parliament’s proposal that a voluntary application of the CRA should be considered to comply also with the RED DA.

Recital 19a

preferred option: European Parliament

To ensure that malicious actors cannot exploit vulnerabilities for which no update is yet available, German industry highly appreciates the following insertion made by the European Parliament, “ENISA should ensure that such notifications are received, stored and transmitted via secure channels and that clear protocols are in place with regard to who can access them and the arrangements for their onward transmission. ENISA should ensure the confidentiality of these notifications with particular regard to vulnerabilities for which a security update is not yet available.”

Recital 22

preferred option: European Parliament

German industry urges the European co-legislators to agree on the wording proposed by the European Parliament since it stresses that security updates and well as minor functionality updates, such as the introduction of additional languages in a user interface, shall not be considered a substantial modification which would require the re-assessment of the conformity of the product. This alteration is crucial to reduce the bureaucratic burden imposed by the CRA and to ensure that the user is provided as quickly as possible with these features which are vital to maintain a risk-adequate level of cybersecurity by fixing respective vulnerabilities in due time.

Recital 27a

preferred option: European Parliament

German industry recognises the rationale behind creating an expert group. However, it is paramount that bother manufacturers and developers as well as users of products are allowed to join such a group to ensure an open consultation of all interested parties.

Recital 30

Preferred option: European Parliament with changes

Noting that article 9 about the Machinery regulation has been deleted in the Council proposal, because in its current form it would generate blind spots in reference to the machinery directive, we see the

need to solve the regulatory conflict between the too specific requirements of EHSR 1.1.9 of the machinery directive and the CRA as intended reference point for cybersecurity. In combination with Recital 30, it is explicit from the Council that the compliance with both regulations is necessary. The intention of the CRA was, to create a simple, coherent, and effective legal framework that horizontally regulates the cybersecurity of all covered products when placed on the market. It should be designed in such a way, that existing, product-specific regulations are not taking precedence for the protection goal of cybersecurity, but it shouldn’t interfere with the protection goals, like those of the machinery directive, either. We therefore understand approach proposed by the Council suggesting a deletion of Art. 9 in conjunction with an extension of Recital 30, but we are not entirely satisfied with this either.

Recital 32 a

preferred option: European Parliament

German industry appreciates the wording introduced by the European Parliament providing manufacturers with the possibility to determine the support period during which they ensure that vulnerabilities are handled. In contrast to the Commission’s fixed five-year timeframe, Parliament’s approach recognises the huge variety of products covered by the Cyber Resilience Act and their respective specificities.

Recital 35b

preferred option: European Parliament

The establishment of a secure digital reporting mechanism at European level to which all Member States’ authorities have access based on the need-to-know-principle is vital to facilitate reporting and minimising the bureaucratic burden as-sociated with the implementation of the CRA.

Recital 69

preferred option: European Council

The Cyber Resilience Act’s very broad scope has far-reaching implications for its implementation. At the same time, the CRA will only become fully effective once the organisational framework conditions specified in the law are in place. German industry believes that the implementation period of 12 to 24 months foreseen by the European Commission is too short to implement the essential requirements across all products with digital elements according to Article 2 (1). This is the case, as the Cyber Resilience Act constitutes the first regulatory act on the European internal market to horizontally regulate the cyber resilience of products. Consequently, companies across sectors have to review their internal measures for CRA-conformity / or even have to set up respective measures and have to implement a vulnerability handling mechanism that accommodates the requirements set out in Annex I Section 2. Moreover, the Member States must organise the market surveillance outlined in Article 43. To this end, new organisational structures have to be defined and new employees have to be hired.

Moreover, the availability of harmonised standards, that support the correct implementation of the legal requirements into products and solutions, is crucial. Moreover, conformity assessment and market surveillance are supported by such standards. It is unclear, for the time being, whether such standards can be compiled, released and cited in the OJEU in a timely manner. Then manufacturers need also implementation time, once the technical rules and requirements are clear. Therefore, we welcome the European Council’s proposal to prolong the implementation period to 36 months. However, we would have appreciated an even further extension to 48 months.

Article 2 – paragraph 1

Preferred option: European Council

The scope shall consider the intended use and the foreseeable use, as defined by the manufacturer. Further the scope should be narrowed to products, which possess a relevant risk, benign products should be excluded. Therefore, only products with at least a bidirectional data connection shall be in scope. Alternatively, the scope could even be limited in the first step to the regulatory objective of products with digital elements, which have a data connection to a network. The current approach “data connection to a device …” would in practice mean that any product is covered if it communicates, independent of a cybersecurity risk.

Moreover, in the context of the transatlantic dialogue, it is important to note that the US cybersecurity strategy (and related pieces of legislations) considers internet-connected products only, i.e., products with a data connection to a public network. We urge the European legislators to strive for close alignment between the US and EU frameworks.

Article 2 – paragraph 3a

preferred option: European Parliament

German industry welcomes the language introduced by the European Parliament stressing that OSS is only covered by the CRA insofar as it is offered within a commercial activity. Commercial collaboration (“upstream”) in Open Source is key for innovation for European and German industry.

Article 2 – paragraph 4a

preferred option: European Council and European Parliament

German industry appreciates the exclusion of spare parts for products, which have been placed on the internal market before the coming into effect of the CRA, as well as for products for which the update period guaranteed by the manufacturer when placing them on the market has expired, from the CRA. It is crucial, that manufacturers are not obliged to extend the free of charge provision of updates for the duration, during which they would be able to provide users with spare parts. Thereby, the CRA will contribute to sustainability goals, since products can be utilised for a longer period of time. However, for practicability reasons, we urge the European co-legislators to delete the word “exclusively” from the wording, as most companies do not run a separate production line for spare parts but rather produce components and spare parts together.

When the manufacturer still provides updates for the product with digital elements, e.g. because the support period of the product hasn’t ended yet, spare parts should also be provided with such updates. Looking at the B2B-context, we expect that this, including the delivered update-version needed, will be solved in the respective contractual agreements regarding the security support or the provision of spare parts. However, should the update period – guaranteed at the moment when the product has been initially placed on the marked, expired, the offering of spare parts should not re-commence the update period.

Thereby, it would be sufficient to repair products using spare parts that are in conformity with the state of the art that was applicable at the point in time the product to be repaired was placed on the market. The vulnerability handling process will safeguard, that the repaired product is updated to the latest available state. If spare parts must be delivered in conformity with the latest state of the art, there is a

high risk, that manufacturers cannot implement the requirements and therefore will not deliver such spare parts anymore.

Article 3

German industry supports the approach of the EP and EC to refer to existing definitions from other EU laws, in particular NIS2, whenever possible, instead of redefining them in the CRA and thus possibly create inconsistencies with existing laws.

Article 3 (31)

preferred option: European Parliament

The exclusion of “necessary security updates that aim to mitigate vulnerabilities” from the definition of “substantial modifications is paramount for a speedy dissemination of security updates across users. Such a timely dissemination will only be possible, if no re-certification of a product is required following the development of an update.

Article 3 (38)

preferred option: European Parliament and European Council

German industry favours the European Parliament’s and EU Council’s proposed text. For the sake of regulatory harmonization, the baseline definition of vulnerability should be aligned not only with the NIS 2 Directive, but also with the scope of Regulation (EU) 2019/881 (Cybersecurity Act) to cover vulnerabilities in ICT processes. In fact, a vulnerability can also arise from a weakness of flaw not just in software but also, in configuration, operations, or in the process of providing software updates.

Article 3 (38a)

preferred option: European Council

German industry favours the European Council’s proposed text, while considering justification provided to Article 3 (38) above.

Article 6: general approach for classifying products

preferred option: European Council

German industry favours the European Council’s wording where products with digital elements will be categorised based on their primary functions and risks stemming from the actual use of a product. This approach recognises the fact that products of the same type can be used for different purposes and, henceforth, in different risk scenarios. The Commission’s and Parliament’s lists of products in Annex III do not provide a clear view on the categorisation of the different products, because it is not based on a concrete methodology. Moreover, the Commission’s and Parliament’s lists of products mix products, product categories, product types, features, functionalities and systems. Henceforth, it lacks coherence, and consequently legal clarity which could have negative repercussions for Europe’s cyber resilience.

Article 6 – paragraph 1 – 2nd sentence

preferred option: European Parliament

German industry strongly supports the explicit clarification that “The integration of a product of higher class of criticality does not change the level of criticality for the product into which it is integrated.”

Article 6a – Expert Group on cyber-resilience

preferred option: European Parliament

German industry recognises the rationale behind creating an expert group. However, it is paramount that bother manufacturers and developers as well as users of products are allowed to join such a group to ensure an open consultation of all interested parties.

Article 9

Preferred option: European Parliament with changes

Noting that article 9 about the Machinery regulation has been deleted in the Council proposal. The compliance with the two Regulations is now explicit from the Council.

Instead, the CRA should create a simple, coherent, and effective legal framework that horizontally regulates the cybersecurity of all covered products when placed on the market. It should be designed in such a way that existing, product-specific regulations are not taking precedence according to the “lex specialis” principle. This includes existing and upcoming legislation (e.g., RED Delegated Regulation, Machinery Regulation, Artificial Intelligence Act). Simplification of the existing legal framework is crucial to allow a correct implementation by all stakeholders to strengthen cyber resilience. Therefore, the CRA should be construed as a “lex specialis” (a total harmonisation legislation) and should thus replace the existing and upcoming cybersecurity-related harmonisation legislation (“CE directives”).

The Parliament and Commission proposals go in this direction. Nevertheless, even if both positions go in the right direction, it is not enough to create a proper “lex specialis” framework. Hence, Art. 2 (4) of the draft CRA should be modified so that conformity with the CRA results in conformity with other existing and upcoming harmonisation legislation regulating cybersecurity:

Proposal: This Regulation lays down specific rules and essential requirements with regard to cybersecurity for products with digital elements. Where other Union legislation lays down requirements covering all or part of the risks covered by the essential requirements set out in Annex I of this Regulation, those requirements (i.e., from other sectoral rules) in other Union legislation shall cease to apply.

Under the above-described approach, article 9 and recital 30 must be deleted.

Article 10 – paragraph 4 – new subparagraph

preferred option: European Commission (rejection of new subparagraph by Parliament)

Although we understand the intention of the Parliament to ensure a secure integration of components in products with digital elements, we reject the current addition of the Parliament in the subparagraph: Manufactures shouldn’t be forced to reveal information about products, which could include trade secrets or intellectual property. Surely in some cases additional information for a secure integration may be needed, but the way how this information is exchanged should lay in the hands of the concerned business parties and would be part of the contractual agreement, including possible compensation for additional integration support.

Article 10 – paragraph 6 – subparagraph 1

preferred option: European Parliament

German industry welcomes Parliament’s wording of Article 10 paragraph 6 subparagraph 1 since it recognises that a one-size-fits-all approach in terms of support period for such a huge variety of products, as covered by the Cyber Resilience Act would not be proportionate. It is a very appropriate idea to grant manufacturers of products with digital elements the possibility to define – proportionate to the expected product lifetime, the product and users’ expectations, the availability of the operating environment and, where applicable, the support period of the main components integrated into the product with digital elements – the supporting period of such a product. Similarly, we appreciate the idea that – wherever possible – manufacturers shall indicate the supporting period on the product.

The concept of a “support period”, which is transparently determined by the manufactures allows both a fair assessment by the user and an informed choice, and it recognises given realities. For example, some long lasting B2B-products require an exchange of their digital elements during planned maintenance during their lifetime. Since the capability for updates lies in the digital element, it would be wrong to link the update period to the product itself and not proportionate to the lifetime of the digital element.

Notwithstanding our appraisal of Parliament’s wording in principle, we would appreciate if the reference to “user’s expectations” would be deleted from the wording of Article 10 since different user groups might have highly diverging expectations – of which some might even be unrealistic when taking the nature of a product as well as the price paid for a product into account.

However, we welcome the addition of Article 10 – 6(a) in the Council’s version because it takes a focused approach and encourages consumers to use latest version of software.

Article 10 – paragraph 10 a

preferred option: European Council

German industry supports a transparent communication of the timeframe during which the manufacturer will handle vulnerabilities in accordance with the requirements set out in the CRA.

Article 10 – paragraph 12

preferred option: European Parliament

German industry appreciates the deletion of a fixed period during which updates are provided since the CRA covers a huge variety of product groups for which one abstract timeframe is not useful. The concept of a “support period”, which is transparently determined by the manufactures allows both a fair assessment by the user and an informed choice, and it recognises given realities. For example, some long lasting B2B-products require an exchange of their digital elements during their lifetime. Since the capability for updates lies in the digital element, it would be wrong to link the update period to the product itself and not proportionate to the lifetime of the digital element.

Article 10 – paragraph 15

preferred option: European Parliament

German industry urges European policymakers to refrain from developing EU requirements for Software Bills of Materials (SBOM). Rather, we strongly recommend that SBOMs specifications are left to

international conventions and standards developed through multistakeholder expert engagements ensuring that SBOMs specifications are aligned with widely adopted international standards and proven software development practices. Moreover, we further strongly support the current regulatory approach and recommend that SBOMs are not made obligatory except for products falling under Annex III due to their higher criticality. In the latter cases, the legislators should choose and set an established standard for reasons of greater certainty, to avoid duplications and have data formats and content clearly defined.

Article 11

preferred option: European Council in conjunction with European Parliaments

German industry welcomes the notification regime proposed by the European Council since it is grounded on a fully digital reporting mechanism (cf. paragraph 2c) and is limited to two reports per vulnerability / incident. Thereby, it maintains a good balance between the need to disseminate information on a need-to-know-basis to market surveillance authorities as well as user, while being not overtly bureaucratic, such as Parliament’s proposal which envisions a total of three reports.

Moreover, the below paragraph seems to have been deleted from the very last version of the Council (it was included in the previous Council compromises): In duly justified cases and in agreement with the CSIRTs referred to in paragraphs 1 and 2, manufacturers can deviate from the deadlines laid down in paragraphs 2a and 2aa. In particular, a deviation from the deadlines provided for in paragraph 2a can be justified in cases where there is an ongoing process of developing a mitigation measure.

It should be included again. It provides flexibility in terms of reporting when mitigation measures are being put in place. The re-introduction of this paragraph would help manufacturers focus on the mitigation measure and would prevent that, eventually, a non-exploited vulnerability is reported.

Furthermore, the notification regime should be limited to significant incidents and significant, actively exploited vulnerabilities in critical products. If all vulnerabilities and incident was to be reported, it probably would overwhelm both ENISA and manufacturers regarding quantity and response time, while critical issues might be overlooked in the large number of negligible risk notifications or even false notification due to the insufficient investigations resulting from short reporting requirements.

Moreover, we urge the European legislators to agree on the wording proposed by the European Parliament in Article 11 paragraph 1 sentence 3, stating “Where a notified vulnerability has no corrective or mitigating measures available, ENISA shall ensure that information about the notified vulnerability is shared in line with strict security protocols and on a need-to-know-basis.” It must be ensured that vulnerabilities, for which no corrective or mitigating measures are available, the number of people having knowledge of such a vulnerability is limited to the strict minimum. Thereby it will be avoided that cybercriminals get knowledge of such vulnerabilities and can exploit them to the detriment of Europe’s cyber-resilience.

Article 17a

preferred option: European Parliament

In order to ensure a consistent implementation of the requirements set out in the CRA, German industry appreciates Parliament’s proposal that the European Commission shall develop guidelines for economic operators, explaining how to apply the Cyber Resilience Act. It is paramount that the European Commission publishes these guidelines as swiftly as possible after the coming into effect of the CRA to ensure that economic operators can update their internal processes accordingly.

Article 55 – paragraph 2 and 3

preferred option: none

Although we understand the intention to also be aware of vulnerabilities in products placed on the market before the date of application of the Cyber Resilience Act, we urge the legislators to keep proportionality in this regard, at it would be a near impossible herculean task to reconstruct all dependencies for all products with digital elements ever placed on the market before. For the reporting of those products further thresholds are dearly needed, especially regarding the criticality of vulnerabilities and the number of the respective products, which maybe not used anymore in relevant numbers.

Article 55 – paragraph 3 a

preferred option: European Parliament

German industry strongly supports the European Parliament’s approach that the CRA – with the date of application – repeals the RED Delegated Regulation (EU) 2022/30. We further strongly support that manufacturers, which comply with the CRA before it becomes mandatory, shall be considered also compliant with RED Delegated Regulation (EU) 2022/30. Both would help a lot to avoid double regulations, inconsistencies, and legal uncertainties.

Article 57

preferred option: European Council

The Cyber Resilience Act’s very broad scope has far-reaching implications for its implementation. At the same time, the CRA will only become fully effective once the organisational framework conditions specified in the law are in place. German industry believes that the implementation period of 12 to 24 months foreseen by the European Commission is too short to implement the essential requirements across all products with digital elements according to Article 2 (1). This is the case, as the Cyber Resilience Act constitutes the first regulatory act on the European internal market to horizontally regulate the cyber resilience of products. Consequently, companies across sectors have to review their internal measures for CRA-conformity / or even have to set up respective measures, and have to implement a vulnerability handling mechanism that accommodates the requirements set out in Annex I Section 2. Moreover, the Member States must organise the market surveillance outlined in Article 43. To this end, new organisational structures have to be defined and new employees have to be hired. Therefore, we welcome the European Councils proposal to prolong the implementation period to a minimum of 36 months, while 48 months would be even better.

Imprint

Bundesverband der Deutschen Industrie e.V. (BDI) / Federation of German Industries

Breite Straße 29, 10178 Berlin

www.bdi.eu

T: +49 30 2028-0

EU Transparency Register: 1771817758-48

German Lobbying Register: R000534

Editor

Steven Heckler

Deputy Head of Department Digitalisation and Innovation

T: +49 30 2028-1523

s.heckler@bdi.eu

BDI document number: D 1831