My Offering
How Can You Comply with the CRA with Reasonable Effort?
When it comes to compliance with the EU Cyber Resilience Act (CRA), you – a machine or device manufacturer – ponder one question.
How can you comply with the Cyber Resilience Act with reasonable effort so that you can keep selling your products after 11 December 2027 and avoid hefty penalties?
The crucial words are “with minimal effort”. You don’t have the time and money for turning your embedded systems into Fort Knox. You rightly feel that this is unnecessary anyway. You just want to survive the CRA penalty date (11 December 2027) unscathed.
Your top priority is to get a rough idea how much effort it would be to make your embedded systems CRA-compliant. You must answer the upgradability question first.
Can you upgrade your embedded system to a current version, free it from exploitable vulnerabilities and keep it that way – with reasonable effort?
The Upgradability Question
Your legacy embedded system inevitably contains known exploitable vulnerabilities with unacceptably high risks and violate the requirement of having no known exploitable vulnerabilities. It most likely contains actively exploited vulnerabilities. You won’t be allowed to sell your product in the EU after the penalty date. Hence, you must be able to upgrade your system to a current version without known exploitable vulnerabilities. If the effort is prohibitively high, you can stop here.
If your answer to the upgradability question is yes, you perform a risk assessment of the essential product requirements with the following goal:
Identify a small set of security measures that is just enough to satisfy the essential product requirements.
Step 1 – Risk Assessment (Annex I, Part I)
The risk assessment is by far the most important instrument for fulfilling the CRA. Together with the intended purpose, the risk assessment helps you narrow down the set of security measures. Done well, it saves you time and money during the implementation. In some rare cases, the costs for implementing the security measures might exceed their value, especially if your machines weren’t built with security in mind. Then, your machines are ready for retirement before the penalty date.
If your machines are upgradable and you can implement the security measures with reasonable effort, you start with the implementation work from the highest risk downwards. In parallel, you tackle the second most important problem for CRA compliance:
Reduce the hundreds of irrelevant vulnerabilities in your product quickly and reliably to the very few relevant ones and put them through risk assessment.
Step 2 – Vulnerability Handling (Annex I, Part II)
You must check all software components of your product for exploitable vulnerabilities. If you find any, you put them through the risk assessment from Step 1. You decide whether to mitigate, accept, avoid or transfer the risk. Choosing the right vulnerability management tool is paramount to separate the wheat from the chaff.
The rest of CRA compliance is tedious “paperwork”. As you have diligently documented the risk assessment and the vulnerability handling process, you have already completed large parts of the technical documentation.
Complete the technical documentation with the intended purpose, support period, vulnerability disclosure policy, user information and other necessary information.
Step 3 – Technical Documentation (Annex VII)
You don’t need fancy and expensive tools to compile the technical documentation. You can write the documentation in markdown format and store it in a repository. This makes it easy to update the documentation regularly during the support period and to pull out any old version for the market surveillance authority, if ever needed.
You must give the technical documentation (Annex VII) to the competent authorities for validation and get the CE marking in return. Only with the CE marking, you are allowed to sell your product after the penalty date.
My post Surviving the EU Cyber Resilience Act provides a deeper discussion how to minimise your effort for complying with the CRA.
My Offering: The CRA Survival Bootcamp for Your Embedded System
With my help, you will perform the risk assessment and define the vulnerability handling process for your embedded system.
CRA conformance for your embedded system
As the manufacturer, you must perform a conformity assessment for your whole product, which may contain 1, 2, 5, 10, 20 and more embedded systems. For example, harvesters contain 25+ ECUs, metal-sheet bending machines one HMI and one PLC, and X-ray fluorescence analysers a single SoM for HMI and controller.
If your product is made up of multiple embedded systems, we select one developed by you. The selected system is typically the one with the HMI or with the connection to cloud services. It should be a good stand-in for the whole product like the driver terminal for a harvester (see Overview: Risk Assessment of the Essential Product Requirements). We subject the selected system to the conformity assessment. Once you know how to assess the selected system, you can complete the assessment for your entire product on your own.
Before we dive into the CRA assessment, we must answer the upgradability question for your system. Unfortunately, a positive answer largely depends on the vendor providing your Linux system. This is typically the SoC, SoM, SBC, ECU or terminal manufacturer – chip vendor, for short. Pondering the following questions will help you decide whether you should stop selling the harvester before 11 December 2027 or not.
- What is the release schedule for the Linux system of your vendor?
- Does your chip vendor offer an up-to-date Linux system, which is CRA compliant?
- How difficult is it to update the software components to current versions?
- What OTA update solutions are suited for your embedded system? Does the Linux system include an out-of-the-box solution?
- Do the SoCs in your embedded systems support secure boot? If no, what is plan B?
- How difficult is it to set up a chain of trust including U-Boot, Linux kernel and root file system?
- How secure are the private keys used for signing the U-Boot images? How do you install the public keys in one-time-programmable memory during the factory installation?
- How difficult is it to encrypt sensitive data?
- Is it cheaper to switch to a different chip vendor with a CRA-compliant Linux system or to upgrade the Linux system of your existing vendor?
- How can you replace your SoC, SoM or SBC, when it reaches end of life in 7 years?
If you conclude that your system is not worth upgrading, you’ll have to retire it before 11 December 2027. Otherwise, you’ll work through the three steps for conformity assessment – risk assessment, vulnerability handling and technical documentation – with me as a teacher and facilitator. The following questions will guide you.
- Is your system a critical, important or default product? Which conformity assessment procedure (Annex VIII) do we have to follow?
- What are the important dates for CRA compliance? Can we avoid CRA compliance for an existing system and, if so, how?
- How long is the support period for the harvester? What is the justification for its length? What are the consequences?
- What do the essential requirements related to product properties (Annex I, Part I) mean?
- How does a pragmatic risk assessment of the essential product requirements look like? Which standard security measures help you avoid violating the essential product requirements?
- What do the essential requirements related to vulnerability handling (Annex I, Part II) mean? How does a pragmatic process for handling vulnerabilities look like? How much time do we have to fix exploitable vulnerabilities?
- What are our reporting obligations, when we become aware of an actively exploited vulnerability in the harvester or of a severe incident having an impact on the harvester?
- What information does the Technical Documentation (Annex VII) contain? When do we have to change the Technical Documentation?
At this point, we have gathered significant parts of the Technical Documentation: the risk assessment of the essential product requirements (Step 1) and the definition of the vulnerability handling process (Step 2). Additionally, you have a plan how to mitigate the violations of the essential product requirements. You can feed the user stories for the necessary security measures into your normal development process. Similarly, you have a plan how to implement the vulnerability handling process. Adding the remaining information like the intended purpose, the user information or the list of harmonised standards applied is mostly paperwork. You can complete the technical documentation (Step 3) on your own.
Delivery
I’ll deliver the CRA Survival Bootcamp over three weeks. We will have full-day sessions – 9:00 – 12:30 and 13:30 – 17:00 – every Tuesday, Wednesday and Thursday. The first week can be onsite at your premises. The other two weeks will be online. The agenda looks roughly like this.
- Day 1: Introduction of the participants. Overview of the CRA.
- Day 2-5: Risk assessment of the essential product requirements.
- Day 6: Evaluating an upgrade path.
- Day 7-8: Definition of a vulnerability handling process (including demo for example embedded Linux system).
- Day 9: Technical documentation and wrap-up.
For each topic, I’ll explain the requirements of the CRA first. Then, I’ll guide you through preparing significant parts of the risk assessment, upgrade path and vulnerability handling process – for your embedded system. You will have a clear idea what to do and how to do it so that you can complete the tasks without my help.
Here is how you book a CRA Survival Bootcamp.
- Press the button below to send me an email about your interest to
burkhard.stubert@embeddeduse.com. I’d appreciate some information about the embedded system and the time period for CRA compliance. - In response to your email, we’ll set up a one-hour online meeting to clarify your questions about the bootcamp, to decide about the embedded system scrutinised and to agree on the start date.
- If we want to move forward with the bootcamp, we’ll sign a contract. In return, you receive the invoice (see What are the payment terms?).
If the provided dates for the bootcamp don’t suite you, please let me know in the email which 3-week time slots suit you better. I’m planning to run two or three more bootcamps in the second half of the year.
Questions & Answers
Which CRA product classes are the target for the bootcamps?
Default products. I will only accept manufacturers of default products for the bootcamps.
Most embedded systems including agricultural, construction and industrial machines are default products. Nevertheless, default products are neglected by the law and standard makers. A horizontal harmonised standard explaining how to comply with the essential product requirements will become available far too late on 30 October 2027.
Vertical harmonised standards like for important and critical products (due on 30 August 2026) are not feasible for the hundreds of different default products. Vertical standards provide long lists of security criteria that important and critical products must satisfy to achieve conformity. The good news is: Manufacturers of default products get away with much shorter lists of criteria that they can define and assess themselves – within the vague bounds of the CRA. I’ll help you identify a minimum set of security measures for your product in the bootcamp.
Who is the target audience?
The members of your security team who will perform the CRA conformity assessment. The security team includes technical people like security engineers, senior software engineers and architects and business people like CTOs, VPs and product owners/managers.
Evaluating the risks and deciding what to do about them are business decisions. The business people must play an active role in performing the risk assessment (Step 1) and answering the upgradability question. It’s their neck on the block, when your company must pay penalties or damages. The technical people assist in the risk assessment by identifying the risks, suggesting mitigation options and documenting the risk assessment. Identifying the few relevant vulnerabilities and completing the technical documentation is their domain as well.
Who does the “actual” work in the bootcamp?
You! My role is that of a teacher and facilitator. The goal of the bootcamp is that you can perform the CRA compliance of your system self-dependently.
What about an onsite bootcamp?
I can do week 1 of the bootcamp onsite at your premises, if the traveling time to your site is reasonable. We will agree on this before we sign the contract. Weeks 2 and 3 are online via Zoom or Teams.
Can you cancel a bootcamp?
No, you can’t. Once you have signed the contract for a bootcamp, you can’t cancel it.
What are the payment terms?
Once you have signed the contract for the CRA Survival Bootcamp from Option 2, you will receive two invoices, each for 50% of the fee. The first invoice is due within a week. The second invoice is due one week before the start of the bootcamp. You will pay the full travel costs, if we do the first week of the bootcamp onsite at your premises.