EU CRA: Essential Requirements Related to Vulnerability Handling

According to Annex I Part II of the EU CRA, manufacturers must actively search for vulnerabilities in their embedded devices, fix them and publicly disclose them to their users and the cybersecurity authorities. Manufacturers must implement a process to release their devices without any know vulnerabilities and to keep their devices free of vulnerabilities during the whole product lifetime by providing security updates in a timely manner.

Introduction

This is the third article in my series explaining the EU Cyber Resilience Act (CRA) from the perspective of manufacturers. The previous articles covered the following topics.

• Embedded Devices Covered by EU Cyber Resilience Act (CRA). The EU CRA covers all embedded devices – except if more specific regulations are already available. Devices are classified into three risk classes: critical, important and default products. Depending on their risk class, devices undergo increasingly stricter conformity assessments. The support period is at least five years or as long as the typical lifetime of the product.
• EU CRA: Essential Requirements Related to Product Properties. Annex I Part I of the EU CRA demands from manufacturers that they make their devices secure by design. Devices must not have any known exploitable vulnerabilities on release and manufacturers must keep it this way over the lifetime of the devices. Annex I Part I specifies 13 security requirements that every device must satisfy. These requirements include user authentication, encryption and integrity of sensitive data, reset to a secure configuration and the availability of essential functionality in case of attacks.

Article 6 does not only require compliance with Annex I Part I but also with Annex I Part II. The latter requirements related to vulnerability handling are the topic of this article.

• Identify Components and Vulnerabilities. Manufacturers must create an SBoM including all vulnerabilities of all software packages installed on the devices. Methods like hardening with compiler options, running sanitisers on test suites or with fuzz tests, tests for the essential requirements of Annex I Part I, and architecture and code reviews help manufacturers find vulnerabilities in their own and third-party software.
• Address Vulnerabilities. Manufacturers must analyse the vulnerabilities found, assess their risk and impact, and fix exploitable vulnerabilities. They must provide the fixes in security updates – separate from functional updates.
• Regular Testing. Manufacturers must regularly run the tests for identifying vulnerabilities – best in an automated way.
• Publish Address Vulnerabilities. Manufacturers must publicly disclose all the vulnerabilities found in any package on their devices. They can postpone the disclosure until they have fixed all the exploitable vulnerabilities. They do this on their website with security advisories and with the SBoM for every release.
• Coordinated Vulnerability Disclosure Policy. Manufacturers must provide a security file security.txt at a defined location on their website. The file describes among other things how to report vulnerabilities by email and anonymously and where to find the security advisories of the device. The requirement demands timelines for the response to and the disclosure of vulnerabilities. Manufacturers must enter vulnerabilities in an official vulnerability database.
• Secure Distribution of Updates. Manufacturers must encrypt security updates and protect their integrity against tampering.
• Dissemination of Updates. Manufacturers must keep their products free of vulnerabilities during the whole lifetime by providing timely security updates.

Article 14 requires manufacturers to notify the European and the national cybersecurity authority about any actively exploited vulnerability or any severe security incident (paragraph 1 and 3) by the notification date, 11 September 2026. Manufacturers, who have implemented the above process for disclosing vulnerabilities publicly, will find it easy to fulfil their notification duties.

Article 15 encourages manufacturers to report vulnerabilities and security incidents voluntarily. As products interact with many other products in possibly unforeseen ways, voluntary reporting helps protect other products. It would also help other manufacturers building similar products. If every manufacturer freely shares information about vulnerabilities with the national and European cybersecurity authorities, all manufacturers will benefit in the end. All for one, one for all!

Essential Requirements One by One

I’ll go through the essential requirements of Annex I Part II of the EU CRA one by one. The title of each requirement – e.g., “Identify components and vulnerabilities (§1, REQ_VH1)” – is taken from the BSI’s Technical Guideline TR-03183: Part 1 – General Requirements. I added the numbering from Annex 1 (e.g., “§1”) and from the Technical Guideline (e.g., “REQ_VH1”) in parentheses after the title. BSI stands for Bundesamt für Sicherheit in der Informationstechnik, which is Germany’s Federal Office for Information Security.

For each requirement, I repeat the original text from the EU CRA. The BSI’s technical report refines the sometimes vague requirements from the EU CRA. The refined requirements are the basis for my explanations and examples. I don’t repeat the BSI’s refined requirements here, because this would increase the length of this article unnecessarily.

Identify Components and Vulnerabilities (§1, REQ_VH1)

[Manufacturers shall] identify and document vulnerabilities and components contained in products with digital elements, 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 products.

Annex I Part II §1

Manufacturers must create a software bill of materials (SBoM) for their embedded devices. The SBoM lists the vulnerabilities for each software component – better known as package in Linux systems – installed on the device. In Yocto builds, manufacturers enable SBoM generation by inheriting the class create-spdx in a configuration file:

INHERIT += "create-spdx"

They can check an embedded Linux image for security vulnerabilities – so-called CVEs (Common Vulnerabilities and Exposures) – and generate per-package reports by inheriting the class cve-check in a configuration file:

INHERIT += "cve-check"

For each package, the CVE check retrieves a list of CVEs from the National Vulnerability Database (NVD) and generates a report with the status, severity and description of each CVE.

Manufacturers can save a lot of time by building a minimal Linux image. Every package not in the image need not be checked for vulnerabilities and licenses. As a nice side effect, builds run a lot faster. Manufacturers should check at project start, whether the vendor of the selected SoM or SoC provides a minimal Linux image for them to extend. Almost all vendors provide a Linux image with the number of packages maximised.

While the SBoM covers the software side of embedded devices, manufacturers must not forget the BoM for the hardware side. The contents of the BoM differs with the manufactured product. A harvester manufacturer lists the 20-30 ECUs and other electronic devices as the BoM. The ECU manufacturers contribute the BoMs for their ECUs. The BoM for the driver terminal (HMI ECU), for example, includes the case, connectors, the touch display, LVDS cable, SoM and main board: all the pieces needed for assembly. The BoM of a measuring instrument, medical device or professional steamer doesn’t look much different.

So far, manufacturers have only looked at vulnerabilities in third-party software. They must hunt for vulnerabilities in their applications and in their interactions with internal components (e.g., services, kernel, system resources) and external systems (e.g., ECUs, sensors, cloud). They have several methods to detect vulnerabilities:

• Hardening our C and C++ code against memory safety issues by turning up the compiler options. Some options like -Wextra, -Wconversion and -Wformat are compile-time checks, whereas other options like -D_FORTIFY_SOURCE=3, -D_GLIBCXX_ASSERTIONS and -Wl,-z,noexecstack enable run-time checks. The latter options perform, for example, bounds checks for C++ strings and containers and buffer overflow checks for C functions like memcpy, strcpy and sprintf. The article Compiler Options Hardening Guide for C and C++ is an excellent guide.
• Running available tests and applications instrumented with checks from different sanitisers. The address sanitiser (ASan) checks for buffer overflow, dereferencing of dangling pointers and other memory issues. The leak sanitiser (LSan) discovers memory leaks at run time. The thread sanitiser (TSan) finds data races between two threads. The undefined-behaviour sanitiser (UBSan) checks for C and C++ constructs that do not conform with the respective standards.
• Fuzz testing or fuzzing of components and applications. Fuzz tests execute one or more “functions” with random, invalid, unexpected and valid input combinations and check whether the components or applications crash or produce invalid outputs or strange behaviours (see FuzzTest, which is an extension of GoogleTest). Manufacturers could fuzz function inputs, user inputs in a GUI, command-line options, connections to TCP ports, files in formats like XML, JSON or YAML, or messages in formats like HTTP, MQTT or Bluetooth. Fuzz testing works for black, grey and white boxes. The whiter the box the more issues fuzz testing will find. Hackers use blackbox fuzzing to find weaknesses in applications.
• Running fuzz tests with sanitisers. Sanitisers are most effective, if manufacturers have a high-quality test suite with a high coverage. Let’s face it: few teams have such test suites. Fuzz tests can make up for this – to a certain extent. Running fuzz tests with sanitisers can find a good amount of memory safety issues, race conditions between threads and code snippets with undefined behaviour. The runtime checks added by compilers also benefit from fuzz tests.
• Providing manual or better automated tests for all the essential requirements of Annex I, Part I like access control, integrity protection, minimising negative impact and limiting attack surfaces. For example, manufacturers could test that
  • the device doesn’t boot with a tampered bootloader,
  • a rogue ECU cannot flood the CAN buses and is rebooted or shut down, or
  • the main applications run with normal user privileges and not with root privileges.

The above methods combined with code and architecture reviews focused on security yield an ample list of vulnerabilities. Manufacturers add these vulnerabilities to the SBoM. Requirement Address Vulnerabilities tells them to analyse these vulnerabilities, to determine their severity, to fix the worst ones quickly and to provide timely security updates. Requirement Regular Testing requires them to check for vulnerabilities regularly, which forces them to automate the above checks as much as possible.

Address Vulnerabilities (§2, REQ_VH2)

[Manufacturers shall, ] in relation to the risks posed to products with digital elements, address and remediate vulnerabilities without delay, including by providing security updates; where technically feasible, new security updates shall be provided separately from functionality updates.

Annex I Part II §2

Requirement Identify Components and Vulnerabilities gives manufacturers a list of unevaluated vulnerabilities. They must have a documented process in place to analyse these vulnerabilities, to assess their risk and to correct them in a timely manner. They must provide security updates for high-risk or actively exploited vulnerabilities. Security updates should not be mixed with functional updates. Manufacturers add their assessment for each vulnerability into the SBoM.

Of course, manufacturers must address all the vulnerabilities in their own software. But – they must also address and eliminate all the high-risk or actively exploited vulnerabilities in all the other software components on their device. According to requirement No Known Vulnerabilities, manufacturers must release their products without any known exploitable vulnerabilities.

A slightly out-of-date version of the Linux kernel comes with dozens if not hundreds of know vulnerabilities. How can manufacturers tame this beast? Manufacturers should

• update to the latest released kernel version available for the SoC in the device.
• ignore all vulnerabilities that are not exploitable in the special context of the device.
• ignore all vulnerabilities from kernel modules not deployed on the device.
• remove all kernel modules not needed by the device for its proper functioning. They iterate this and the previous action until no CVEs can be removed any more.
• fix the few remaining vulnerabilities themselves, hire someone to fix them or hope that kernel developers fix them.

If everyone puts in a little bit of time or money, all will benefit big time. This is the power of community development.

Regular Testing (§3, REQ_VH3)

[Manufacturers shall] apply effective and regular tests and reviews of the security of the product with digital elements.

Annex I Part II §3

It is not enough to identify vulnerabilities once, but manufacturers must run the tests from requirement Identify Components and Vulnerabilities regularly. This helps them to avoid regressions and to find new vulnerabilities early. They should strive to automate testing as much as possible – for example, as part of their Continuous Delivery pipeline. Manufacturers must repeat the testing at least every three months or with every major change of the product – whatever happens more frequently. Manufacturers are on the safe side, if they interpret “major change” as any functional update of the device.

Tests for the essential requirements from Annex I Part I are mandatory. The other tests from requirement Identify Components and Vulnerabilities are best practices to discover security issues.

Publish Addressed Vulnerabilities (§4, REQ_VH4)

[Manufacturers shall, ] once a security update has been made available, share and publicly disclose information about fixed vulnerabilities, including a description of the vulnerabilities, information allowing users to identify the product with digital elements affected, the impacts of the vulnerabilities, their severity and clear and accessible information helping users to remediate the vulnerabilities; in duly justified cases, where manufacturers consider the security risks of publication to outweigh the security benefits, they may delay making public information regarding a fixed vulnerability until after users have been given the possibility to apply the relevant patch.

Annex I Part II §4

Manufacturers must inform the users of their devices about vulnerabilities using security advisories (see Mozilla Foundation Security Advisories for examples). A security advisory must contain information about the impact of the vulnerability and its mitigation. More often than not, the only available mitigation will be the installation of a security update. Sometimes users can just avoid using the device in an insecure network or entering special characters in an input field. Sometimes users can fall back to an older version of the software.

Only the users know about the vulnerabilities so far. Once manufacturers have provided users with a security update and given the users enough time to install the update, they must publicly disclose the security advisory about the now fixed vulnerability. It’s important to note that manufacturers don’t have to publicly disclose any information about vulnerabilities before users had the chance to install a security update. However, they must not delay the fix, the rollout of the update and the public disclosure unduly.

Manufacturers must publish their security advisories in machine-readable form. A good way probably is to enter them as CVEs in the National Vulnerability Database (NVD) or the CVE raw database. Then, manufacturers can make Yocto builds generate the SBoM including the vulnerabilities from their own software. Manufacturers should also publish the security advisories on their websites like Mozilla does. Their websites are more accessible to their users than the official CVE databases.

Just to make this point crystal clear: Manufacturers must publish the addressed vulnerabilities for all software packages installed on their devices – in the SBoM. Addressed vulnerabilities include actively exploited, exploitable and non-exploitable vulnerabilities. Exploitable vulnerabilities must be fixed in a timely manner, whereas non-exploitable vulnerabilities can be fixed later.

One more important note: Manufacturers must not release a product, if it contains even a single exploitable vulnerability in any installed package (see essential requirement No Known Vulnerabilities). It is in their own interest to fix exploitable vulnerabilities quickly and to keep the number of installed packages to the absolute minimum.

Coordinated Vulnerability Disclosure Policy (§5, REQ_VH5)

[Manufacturers shall] shall put in place and enforce a policy on coordinated vulnerability disclosure.

Manufacturers of products with digital elements shall 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.

Annex I Part II §5

The BSI details the coordinated vulnerability disclosure (CVD) policy in a separate technical report TR-03183 – Part 3: Vulnerability Reports and Notifications. The CVD policy defines a process how entities – users, customers, security researchers, white-hat hackers, individuals and groups – can report vulnerabilities to a manufacturer. The reporting process is specified in the plain-text file security.txt based on RFC 9116: A File Format to Aid in Security Vulnerability Disclosure. The file must be located at the URI https://www.example.com/.well-known/security.txt and contain the following information.

• The canonical URI https://www.example.com/.well-known/security.txt so that reporters can check whether they are looking at the original security file.
• Contact information: an e-mail address like security@example.com for identifiable contact and a web form for anonymous contact.
• A link to a file with the manufacturer’s public OpenPGP key so that reporters can encrypt their communication with the manufacturer.
• An expiry date for reporters to decide if the security file is stale and should not be used any more. The expiry date should be less than a year in the future.
• A link to the security or CVD policy of the manufacturer.
• A list of preferred languages in which reporters send their reports. The list must at least contain English.
• A link to the file containing the security advisories, which the manufacturer must publish in accordance with requirement Publish Addressed Vulnerabilities.
• The digital signature of the security file so that reporters can check its authenticity.

Note: The security file Security.md recommended by the Yocto project for Yocto layers is much simpler than the official security.txt. It only contains the contact information for reporting vulnerabilities. I doubt that Security.md is enough for compliance with the EU CRA.

The security or CVD policy demanded by security.txt describes in more detail how reporters can contact the manufacturer, how a good report should look, how a good and respectful communication looks like, what the guaranteed response times are and what the timeline for vulnerability disclosure is. Let us look at the last two points in more detail.

Manufacturers must guarantee the following response times to an incident report – unless the report was anonymous.

• They must provide a simple response to a report in five working days. The response must not be automated.
• They must provide detailed feedback after further analysis within ten working days.
• Also within ten working days, they must tell the reporter whether they accept or reject the vulnerability.

Manufacturers must disclose vulnerabilities within the following timeline.

• They must publicly disclose vulnerabilities within 90 days – on their website as security advisories. If they have a good justification (e.g., preventing severe damage from their customers), they can delay the disclosure once by another 90 days.
• Additionally, they must publicly disclose vulnerabilities in the National Vulnerability Database (NVD) or any other public database like the CVE raw database. The same deadlines apply.

Secure distribution of updates (§6, REQ_VH6)

[Manufacturers] shall provide for mechanisms to securely distribute updates for products with digital elements to ensure that vulnerabilities are fixed or mitigated in a timely manner and, where applicable for security updates, in an automatic manner.

Annex I Part II §6

The essential requirement Security Updates details the secure distribution of updates. The preferred solution is that the device installs security updates automatically. However, users have the option to postpone the installation a couple of times (three times looks like a good default) but not indefinitely. The device will force the installation if the user postpones it too often. The EU CRA clearly prioritises timely fixing of vulnerabilities over uninterrupted work.

The transfer of security updates must be encrypted in accordance with requirement Confidentiality Protection. The archive with the security update must be protected against tampering in accordance with requirement Integrity Protection.

Dissemination of updates (§7, REQ_VH7)

[Manufacturers] shall ensure that, where security updates are available to address identified security issues, they are disseminated without delay and, unless otherwise agreed between a manufacturer and a business user in relation to a tailor-made product with digital elements, free of charge, accompanied by advisory messages providing users with the relevant information, including on potential action to be taken.

Annex I Part II §7

Requirement No Known Vulnerabilities demands from manufacturers that they release their products without known exploitable vulnerabilities. This requirement Dissemination of Updates calls for manufacturers to keep their products free of known exploitable vulnerabilities. When manufacturers become aware of a new exploitable vulnerability in any of the packages installed on their devices, they must quickly provide a security update with a fix.

Security updates are free of charge by default. If manufacturers have agreed with their business users about a fee upfront, they can charge for the security updates. They must not charge any fees for private users, a.k.a. consumers.

Security updates must contain information about the vulnerabilities and how to fix them. Most of the time, the fix is to apply the security update. The information should be worded in a language users can understand.