Surviving the EU Cyber Resilience Act

As a machine or device manufacturer, you probably have some sleepless nights because of the Cyber Resilience Act (CRA). What do you have to do so that you can sell your products after 11 December 2027 and don't have to pay penalties threatening the existence of your company?

The Question for Sleepless Nights

Over the last year, you have prioritised core features over security features time and again. Delivering features that make your customers more productive gives you a good return on investment, whereas security measures tend to get in the way of productivity. Your product lacks standard security measures for confidentiality, integrity, availability and access control. The software components of your product are out of date and hard to update. You don't have security expertise in-house. You have trouble to find this expertise externally.

In short, your product does not conform to the EU CRA. If you can't fix the CRA violations by 11 December 2027, your product will be banned from the EU market and your company will face penalties up to 15 million Euro or up to 2.5% of your worldwide annual gross revenue, whichever is higher. These consequences threaten the existence of your company. And - you don't have much time left to become compliant.

Step 1: Risk Assessment

For CRA compliance, it is not enough to write hundreds of pages of documentation. This is the tedious but easy part. For CRA compliance, you must implement concrete security measures to fix any violations of the essential product requirements (Annex I, Part I). You must also demonstrate by tests that your product satisfies the requirements. This is the hard and time-consuming part. It is made even harder, because you must most likely bolt on security to a system that was not designed for security.

You cut through the complexity of this problem by performing a risk assessment of the essential product requirements - the most crucial demand of the CRA. The risk assessment yields a prioritised list of security measures that need implementing. It gives you a plan how to move forward. As time is at a premium, you want to implement just enough security measures to satisfy the essential product requirements. Not more and not less!

The Upgradability Question

Don't start implementing the security measures yet! Your risk assessment must address the supreme requirement of the EU CRA: Your embedded system must have no known exploitable vulnerabilities during its support period. However, legacy systems inevitably violate this requirement. They often run software components that reached end of support 2, 5 or even 10 years ago. Security updates are not available any more. Creating them would be prohibitively expensive. Users install updates manually - or they don't. The system doesn't enforce the installation of the sporadic updates - violating another essential requirement.

If this sounds familiar, you face a tough business decision.

If your answer is no, you must not sell your product in the EU after 11 December 2027 any more. Already sold products must not receive any updates with substantial modifications after that date (see Article 69(2)). Any change increasing the overall risk even slightly can be regarded as a substantial modification. Security and bug fixes are OK. Functional updates are most likely not OK.

If your answer is yes, your highest-priority job is to implement an OTA update solution for your existing system and to roll it out in the usual way (e.g., through a manual update from USB drive). From then on, you use this solution to update your embedded systems automatically to a current version free of exploitable vulnerabilities. Once your system is up-to-date, you start implementing the security measures identified in the risk assessment of Step 1. And most importantly: Keep your embedded system up-to-date.

Products under development fall into the same category as upgradable legacy products. The software components may be slightly out-of-date, as development started several months ago. The effort for upgrading your system should be fairly low. If you haven't done it yet, your highest-priority task is to implement a robust OTA update solution. Now! You use this solution during your development. When you release your product in a couple of months, you can be sure that OTA updates will work. Still hesitating? Then learn from VW's disaster who had to update 30,000 cars manually.

In short, the upgradability question forces you to go through your product portfolio and decide which products you take from the market and which to keep on the market. This is a go/no-go decision. You should make it early. The risk assessment and the answers to the upgradability question give you the best possible basis for this decision.

If you decide to go on, you start feeding the security measures as top-priority features into your normal development process. You document each measure in a security decision record (SDR) and add the SDR to the Technical Documentation (Annex VII). You got the - by far - most important and most time-consuming work for CRA compliance rolling.

Step 2: Vulnerability Handling

The second most important work for CRA compliance is vulnerability handling (Annex I, Part II). Your product must have no known exploitable vulnerabilities during its support period. After you have generated the SBoM with all vulnerabilities for all software components, you must tell apart the few relevant from the thousands of irrelevant vulnerabilities. If, for example, your product neither uses Bluetooth, streams video nor renders web pages, you can ignore the vulnerabilities for these components.

A good vulnerability management tool handles this with ease. The security team behind the tool can rule out a lot more vulnerabilities, if it takes the security measures of the underlying embedded Linux system and the application domain of the product into account. You feed the remaining vulnerabilities into the risk assessment. This last filter leaves the few vulnerabilities that require mitigation.

You annotate the vulnerabilities in the SBoM with a brief reason why they are relevant or not. You add the SBoM, the SDRs for the relevant vulnerabilities and a description of your vulnerability handling process to the Technical Documentation (Annex VII). Tools like the Torizon Vulnerability Manager and ARIANNA can save you a lot of time.

Step 3: Technical Documentation

The rest is paperwork. You add the intended purpose, support period, system architecture, coordinated vulnerability disclosure (CVD) policy, user information, reports of conformity tests, declaration of conformity and other mundane information to the Technical Documentation.

You can write the documents in markdown format. Storing the documents in a git repository makes it easy to update the technical documentation during the lifetime of your product. Or, you can use a tool that guides you through completing the technical documentation. The tool generates the documentation in JIRA, markdown or other formats.