Planned standard for dealing with vulnerabilities

The new Cyber Resilience Act (CRA) 2024/2847 is intended to make digital products (such as machines, IoT devices, but also pure software) more secure from December 2027 onwards.

A key requirement of the CRA will be the prevention of vulnerabilities and other security incidents, which manufacturers must remedy by means of software updates. To this end, the technical files for the legal act provide for ‘a description of the design, development and manufacture of the product with digital elements and the procedures for handling vulnerabilities’.

The prEN 40000-1-3 standard, entitled ‘Cybersecurity requirements for products with digital elements - Part 1-3: Vulnerability Handling’, will serve as the basis for the technical implementation of these requirements in the future. Since the beginning of 2026, there has also been a draft standard that explains the first details of its implementation. This technical article presents the most important contents of the standard.

Even though many manufacturers may already be familiar with the IEC 62443 series of standards, the new standard EN 40000-1-3 (currently prEN) offers a crucial tool for practical application. EN 40000-1-3 translates the abstract legal requirements into concrete requirements. To this end, manufacturers are instructed to create structured processes and internal and external guidelines for dealing with vulnerabilities. These should take into account the content explained in the following chapters:
 

Integrated inventory management: SBOM meets HBOM

The standard specifies that vulnerability management must not stop at the software application. According to the standard, identification means knowing what is installed where in order to be able to react quickly when an actively exploited vulnerability is discovered.

Manufacturers must have an overview of the entire bill of materials, which includes a hardware bill of materials (HBOM).

• Separate parts lists: In addition to the software bill of materials (SBOM), the hardware components involved must also be recorded as a parts list (HBOM) and thus clearly identified.
• End-to-end supply chain security: Identification must reflect the depth of the supply chain. It is not enough to know the product – you need to know which software version is running on which hardware revision.
• Up-to-date: Parts lists are not static documents, but dynamic data sets that must be kept up to date throughout the entire support period of the machine.

Continuous review and identification

The standard describes systematic testing processes throughout the entire support period.

• Automation: Use of analysis tools that continuously check the SBOM for new known vulnerabilities.
• Intervals: Defining regular review cycles, even if no changes have been made to the machine (as new vulnerabilities are discovered in existing code every day).
• Verifiability: Documenting the test results as part of the technical files for market surveillance authorities.

Patch-Management 

If a vulnerability is found, the standard defines a ‘path to patch’:

• Classification of the vulnerability: The priority of the fix must be determined based on a risk assessment. Critical vulnerabilities must be patched before less risky errors.
• Interim solutions: If a final patch takes time, the standard requires the immediate provision of workarounds (e.g. configuration adjustments) to minimise the window of opportunity for attackers.
• Secure distribution: The standard specifies requirements for the integrity of the update so that the update itself does not become a gateway for attackers.
• Duty to inform: Creation of advisories – clear instructions to the machine operator on what measures (workarounds or updates) they must take.

Crisis response and reporting workflows

This is the most critical point of the standard from an administrative perspective, as it establishes a link to the legal reporting obligation.

• Event categorisation: The standard helps to determine whether an event constitutes a ‘security incident’ that must be reported within 24 hours.
• Interface definition: Defining internal roles (e.g. Product Security Officer) that are authorised to submit reports to national authorities (in Germany, the BSI) or ENISA.
• Documentation requirement: Even if a vulnerability is not reported, the standard requires that the reasons for not reaching the reporting threshold be justified and documented internally.

Synergies with the Machinery Regulation  

In most cases, machines must comply with several sets of regulations at the same time. In this context, compliance with the CRA, through the application of standards such as those in the EN 40000 series, can also facilitate compliance with the cybersecurity aspects of the new 2023/1230 EU Machinery Regulation. EN 40000-1-3 acts as a ‘horizontal’ bracket that standardises processes.