Industry groups call for changes to EU Cyber Resiliency Act

Several IT and tech industry groups have issued a list of recommendations for improving the EU Cyber Resiliency Act (CRA), currently being crafted by EU co-legislators. The associations have urged the co-legislators not to prioritize speed over quality in finalizing their positions to avoid unintended outcomes, citing problematic aspects that need to be addressed in the current proposal.

The EU CRA aims to set out new cybersecurity requirements for products with digital elements, bolstering cybersecurity rules for hardware and software to protect consumers and businesses from inadequate security features. It was first put forward by Ursula von der Leyen, president of the European Commission (EC), in September 2021, with an initial proposal published in September 2022.

The recommendations aim to improve cybersecurity and resilience while addressing key concerns shared by companies of all sizes from a variety of sectors including software developers, device-makers, and component manufacturers, according to a document from global tech trade association the Information Technology Industry (ITI) Council. The ITI issued the recommendations alongside the Developers Alliance, The Software Alliance, and the Computer & Communications Industry Associations (CCIA).

CRA’s scope should be narrower and clearer

The first recommendation made by the collective is that the proposed scope of the CRA should be made narrower and clearer. “Any reference to ‘remote data processing solutions’ should be excluded from the scope of the CRA to ensure legal clarity, and to avoid overlaps with existing legislation and unnecessary burden,” they wrote.

Software as a service, platform as a service, or infrastructure as a service should not be considered within the scope of the CRA, and this clarification should be reflected in the core legal text to provide greater legal certainty and to facilitate implementation across the EU, the recommendation read.

It also called for greater clarity regarding open-source software (OSS), suggesting that a clear exception of OSS should be included in the core legal text. “The unique characteristics of OSS must be taken into account through the entire proposal, also when creating obligations for manufacturers for OSS components that are integrated into products.”

More proportionate approach needed to determine product risk levels

The second recommendation calls for a more proportionate approach to determining a product’s risk-level, along with greater certainty for manufacturers to ascertain if a product is deemed a critical one. “A transparent and inclusive review process involving economic operators should be set up to determine whether a product is critical,” the groups wrote. This would avoid wrongfully designating too many products as “critical,” making them more expensive, and forcing organizations to unnecessarily redirect valuable cybersecurity resources towards implementing overly stringent requirements, to the detriment of focusing on tackling real risks, they argued.

For example, while the current approach for simplifying the criteria for allocating the products into the critical category goes in the right direction, the reference to “personal data processing” should be replaced by processing of “sensitive personal data” only, as any device today is processing personal data to some extent.

Mandatory reporting of unpatched vulnerabilities should be removed

The third recommendation is that, under the EU CRA, only patched vulnerabilities that have been actively exploited and pose a significant cybersecurity risk should need to be reported. “Mandatory reporting of unpatched vulnerabilities [currently proposed in the CRA] represents a serious concern recently signaled by a broad industry coalition. In general, it is crucial that the reporting obligations, including the reporting timeline and the competent authority, in both Article 11(1) and (2) are in line with the NIS 2 Directive,” it read.

Furthermore, only “significant” incidents should be subject to the reporting obligations of Article 11 to avoid an unmanageable reporting burden for manufacturers and responsible authorities, the collection added.

Work needed to avoid disproportionate obligations, increasing cybersecurity risks

More work is required to avoid disproportionate or impossible obligations, and obligations that increase cybersecurity risks, the final recommendation read. The CRA’s Annex I on essential requirements should establish proportionate obligations as the absolute obligation to “deliver a product without known exploitable vulnerabilities” is an impossible bar to set, as product security can be influenced by numerous factors including product deployment environment, the groups claimed. It also ignores the manufacturers’ margin of action before and after a product is placed on the market, they added. “This should be limited to any publicly known critical or highly critical vulnerabilities.”

Likewise, a mandatory security update period based on the “expected product lifetime” is a disproportionate and legally uncertain concept, and more clarity is needed. “Linking “expected product lifetime” solely to “reasonable user expectations” will create great legal uncertainty across the EU single market as the actual duration periods will ultimately be determined by national market surveillance authorities and courts, not manufacturers.”

Furthermore, compulsory differentiation between security and functionality updates is not feasible in terms of practicality and necessary flexibility, nor for the convenience of users, the recommendation said. “We would also welcome any changes in the CRA that recognize the difference between two categories of products – consumer and non-consumer products. It is key to acknowledge that in the B2B context, the buyers are organizations which have a sufficient level of cybersecurity awareness and resources to make informed purchasing decisions.” In the case of SBOMs, the CRA should provide flexibility and consideration for best practices and international standards.

“Provisions which would increase risks rather than improve cybersecurity, such as the disclosure of information on the design and development of the product (Annex V, point 2(a)), as well as the disclosure of details about vulnerabilities as part of an SBOM (Annex I, Section 2, point 1), must be avoided.” Similarly, the extension of the GDPR principle of data minimization to non-personal data in Annex I, Section 1(3) (e), will result in poorer and stagnant experiences for users without any security benefits, as manufacturers will be limited in the collection of anonymous data that is used for quality control or track potential security threats.”