Vulnerability handling according to the European Cyber Resilience Act (CRA)

So far, cybersecurity regulations in Europe have been primarily driven by the NIS2 regulations. The NIS2 regulations are currently active, and asset owners and service providers must comply with these regulations. On March 12 the European parliament passed a new regulation specifically to improve product security, so new regulations aimed at product manufacturers. This Cyber Resilience Act (CRA) and its annexes specify the requirements products with so-called “digital elements” must meet. Digital elements refer to both hardware (e.g., microprocessors and microcontrollers) and software that contribute to the functionality, operation, and security of the product.

CRA is essentially an extension of the CE marking. The European CE marking was introduced in 1985. It is a mandatory conformity marking for products sold within the European Economic Area and indicates that the product meets the essential requirements of relevant European Union directives and regulations related to health, safety, and environmental protection. The new regulation adds cybersecurity regulations to the CE marking after 40 years. As such, the CRA has a very wide scope that includes products used in homes as well as products used in refineries. However, the requirements for the products differ based on their criticality. In this blog I focus my discussion on vulnerability handling because it is an area with a major impact for the product manufacturers.

One of the most important requirements, as far as I am aware not covered in other regulations, are the new EU requirements on vulnerability handling. I start the discussion with the following clause:

• Certain tasks provided for in this Regulation should be carried out by ENISA, in accordance with Article 3(2) of Regulation (EU) 2019/881. In particular, ENISA should receive notifications from manufacturers of actively exploited vulnerabilities contained in products with digital elements, as well as incidents having an impact on the security of those products. ENISA should also forward these notifications to the relevant Computer Security Incident Response Teams (CSIRTs) or, respectively, to the relevant single points of contact of the Member States designated in accordance with Article [Article X] of Directive NIS2 and inform the relevant market surveillance authorities about the notified vulnerability.

The question that arises is what is an actively exploited vulnerability? According to the definition given by the CRA regulations it is:

•  ‘actively exploited vulnerability’ means a vulnerability for which there is reliable evidence that execution of malicious code was performed by an actor on a system without permission of the system owner.

So, does an actively exploited vulnerability include the vendor’s internal list of vulnerabilities discovered through its threat modeling/risk analysis of its products? Does an actively exploited vulnerability include vulnerabilities discussed in proof of concepts? Is research considered an activity that actively exploits vulnerabilities? The question arises here: “When is a vulnerability actively exploited?” Are vulnerabilities communicated to ENISA exclusively reactive (after a verified breach or attempt) information or also proactive information?

Another CRA regulation that mentions ‘actively exploited vulnerabilities’ is:

• In order to ensure that products with digital elements are secure both at the time of their placing on the market as well as throughout their life-cycle, it is necessary to lay down essential requirements for vulnerability handling and essential cybersecurity requirements relating to the properties of products with digital elements. While manufacturers should comply with all essential requirements related to vulnerability handling and ensure that all their products are delivered without any known exploitable vulnerabilities, they should determine which other essential requirements related to the product properties are relevant for the concerned type of product. For this purpose, manufacturers should undertake an assessment of the cybersecurity risks associated with a product with digital elements to identify relevant risks and relevant essential requirements and in order to appropriately apply suitable harmonized standards or common specifications.

Part of the CRA sets requirements for the technical documentation, one of the requirements is:

• complete information on the design and development of the product with digital elements, including, where applicable, drawings and schemes and/or a description of the system architecture explaining how software components build on or feed into each other and integrate into the overall processing.

• complete information and specifications of the vulnerability handling processes put in place by the manufacturer, including the software bill of materials, the coordinated vulnerability disclosure policy, evidence of the provision of a contact address for the reporting of the vulnerabilities and a description of the technical solutions chosen for the secure distribution of updates. 

• complete information and specifications of the production and monitoring processes of the product with digital elements and the validation of these processes. 

• an assessment of the cybersecurity risks against which the product with digital elements is designed, developed, produced, delivered and maintained as laid down in Article 10 of this Regulation. 

For me a threat modeling exercise as executed during product development is part of the risk assessment and as such should document which threats have been analyzed as part of the mandatory documentation. But this only covers this “gap” at the point of releasing the new product, not during the product life cycle.

Annex 1, specifying the essential cybersecurity requirements, seems to broaden the concept of ‘actively exploited’ by specifying:

• identify and document vulnerabilities and components contained in the product, including by drawing up a software bill of materials in a commonly used and machine-readable format covering at the very least the top-level dependencies of the product.

• take measures to facilitate the sharing of information about potential vulnerabilities in their product with digital elements as well as in third party components contained in that product, including by providing a contact address for the reporting of the vulnerabilities discovered in the product with digital elements.

But a new ambiguity arises by discussing top-level dependencies in the first rule, and simultaneously suggesting that underlying 3rd party components need to be included too. A specification of what top-level dependencies are is missing.

Other requirements seem to be clear though don’t always enforce a strict response time.

• in relation to the risks posed to the products with digital elements, address and remediate vulnerabilities without delay, including by providing security updates.

What is without delay, and what are the rules if such risk would require new engineering efforts. Some vulnerabilities require to enhance the functionality, which would mean a functional release and not a simple maintenance release as is the case for patching a software vulnerability. And how would this relate to the following regulation:

• ensure that, where security patches or updates are available to address identified security issues, they are disseminated without delay and free of charge, accompanied by advisory messages providing users with the relevant information, including on potential action to be taken.

Does this mean that functional enhancements need to be distributed free of charge? There need to be better definitions of what the definition of a vulnerability is. Is it merely a software flaw, or does it include functional shortcomings in, for example, the security control mechanisms.

Another point of interest is that these requirements are conformity testing for new products entering the European market, however the process automation industry has many legacy products that do not meet these conformity requirements. Many automation products have a lifespan of 10 to 20 years, and sometimes even longer. How is this handled?

Though there is a lot of good stuff in the CRA, there are also points that need clarification. But the good thing is we still have time to anticipate the new ruling, the CRA will not be active before 2027.

Sinclair Koelemij

With 45 years of experience in process automation, Sinclair brings a wealth of expertise, with 25 years dedicated to process control and an additional 20 years specializing in networking, security, and risk management for process automation systems. During his extensive 43-year tenure at Honeywell, he played key roles in servicing, engineering, and securing diverse control and process safety solutions, spanning basic and advanced control systems. Sinclair also possesses hands-on experience in software development and the implementation of control and safety solutions for over 100 installations owned by various asset owners, varying in scale from smaller setups with fewer than 1,000 I/O points to large installations exceeding 100,000 I/O points. Furthermore, Sinclair holds several patents in the field of cyber-physical risk evaluation and mitigation..