Dear Reader,
Over the last 20 years, I have helped manufacturers build harvesters, cars, metal-sheet bending machines, vending machines, professional appliances, UV cleaning robots, measurement devices, modems and more. None of them would pass the Cyber Resilience Act (CRA). I am guilty of neglecting cyber security.
How about you? Do you have a clean conscience when it comes to cyber security? Don’t feel ashamed. Just say it: “I am guilty of neglecting cyber security.” And so is everyone from engineer over product manager, director and VP to CTO and CEO. It is just so much easier to justify the cost for implementing the next cool feature than for implementing a security measure that is likely never needed.
The situation changed fundamentally with the CRA. If you can’t demonstrate that your products satisfy the essential product requirements (Annex I Part I),
- you must not sell your products in the EU from 2028 and
- you face fines up to 15 million Euro or up to 2.5% of your worldwide annual gross revenue, whichever is higher.
You have two years until 11 December 2027 to avoid this disaster. This is the point to switch into survival mode. The following question should be your North Star:
How can you comply with the CRA with reasonable effort?
The keyword is “reasonable effort”. Bolting security measures on your existing machines and devices is a gargantuan task. Time is at a premium. Finding people who understand the CRA, your embedded systems and your business gets harder by the week, because everyone is looking for them.
First and foremost, you must get a fair idea of the effort. For each of your products, you will decide whether to continue selling it in 2028 or not. My offering CRA Survival Bootcamp will help you with this decision. The bootcamp gives you the tools to perform CRA compliance for your products and give you an idea whether CRA compliance is worth the effort.
Finally, I have a special offer for loyal readers of my newsletter:
Special Offer for Loyal Readers
Respond to this email to register your interest in a bootcamp. If this leads to a contract for a CRA Survival Bootcamp, you’ll get a 5% discount.
I’ll use the remainder of the newsletter to give you an overview of my articles about the CRA - including two new articles from the last month. For this newsletter, I add some new things I have learned since writing these articles.
Enjoy reading,
Burkhard 💜
My Content about the CRA
Surviving the EU Cyber Resilience Act
Your ultimate goal as a manufacturer is to sell more units of your product. You do this by making your customers more productive, earn more or happier. You hardly ever achieve this by implementing security measures. That’s why you have largely neglected security up to now.
The CRA changes your situation fundamentally. You must get serious about security. You must implement security measures and demonstrate their effectiveness. If you don’t, you will face heavy penalties and sales bans from 2028. Neglecting security will become really expensive!
You are between a rock and a hard place. On one hand, you want to make your machines and devices better to sell more. On the other hand, you must spend significant time and money on cyber security to avoid penalties and sales bans.
In this situation, I would try to find a way how to implement just enough security measures to pass the CRA. I would try to survive the CRA with as little effort as possible. I am pretty sure that you would do the same. This is the approach that I present in my post Surviving the EU Cyber Resilience Act and that I teach in my CRA Survival Bootcamp.
Overview: Risk Assessment of the Essential Product Requirements
This post is an overview of my posts and talks about the risk assessment of the essential product requirements. I describe in the newsletter episodes 63-67 how to perform a risk assessment for a driver terminal. The risk assessment is by far the most important, most time-consuming and least understood part of a CRA conformity assessment. Hence, it is the central part of my CRA Survival Bootcamp.
In the post, you also find the slides from my talk at the Torizon CRA Summit in Zurich on 23 October 2025. I’ll soon put up a video of my talk there as well.
Adam Shostack links threat modeling to the CRA. The essential product requirements of Annex I.I.2b-m follow the pattern: Protect <property> <against threat> <by security measure>. The integrity requirement (Annex I.I.2f) could be read as follows:
- Protect
- <property>: the integrity of stored, transmitted or otherwise processed data, personal or other, commands, programs and configuration
- <against threat>: against any manipulation or modification not authorised by the user
- <by security measure>: by reporting on corruptions
The given security measures are mere suggestions. They are generic as they apply to all products. Measures for specific products or product categories are missing. This is perfectly OK, as it is your job to come up with the appropriate security measures for your product in the risk assessment.
The threat is the opposite of the property. Tampering is the opposite of integrity, information disclosure of confidentiality, spoofing of protection from unauthorised access, and so on. I could go on and map the threats from STRIDE (spoofing, tampering, repudiation, information disclosure, denial of service and elevation of privileges) to the essential product requirements of the CRA.
The lesson here is that the CRA doesn’t reinvent the wheel. The CRA is based on proven approaches like threat modeling and risk assessment. It is also Adam Shostack who gave me the idea of combining threat modeling and risk management into one process. Adam Shostack’s book Threat Modeling is an excellent introduction and reference for threat modeling. Adam has a very pragmatic approach.
EU CRA: Start, Length and End of Support Period
The support period applies to each product instance individually. If the manufacturer places instance #1 of a product on the EU market on 22 April 2028 and instance #7389 of the same product on 17 June 2043, the support period of the instances starts on the respective dates. Assuming the support period is 10 years, the first instance runs out of support on 22 April 2038 and the second instance on 17 June 2053.
Hence, the support for a product starts when the first instance of the product is placed on the EU market and ends when the last instance of the product runs out of support. If instance #7389 is the last put on the market, the manufacturer must support the product for 25 years from 22 April 2028 to 17 June 2053. It must manage its supply chain very well, as many software and hardware components won’t be available for 25 years.
A manufacturer can place a batch of product instances on the market at the same time by transferring ownership or possession to a distributor. The distributor can be a fully-owned subsidiary of the manufacturer (e.g., a distribution branch or sales office) or a separate company. The distributor can be any legal entity.
A manufacturer could produce 1800 instances of a machine for the next three years all at once and sell them to its own distribution branches or independent distributors, say, on 13 March 2029. All 1800 instance would be placed on the market on 13 March 2029. This looks good in theory, but not so much in practice. Here are some doubts.
- Can the manufacturer produce 1800 machines in a fairly short time, say, 3-6 months?
- Can the distributor store 400, 900 or even 1800 machines? What are the extra costs for storing the machines?
- Will the distributors be able to sell 1800 machines in three years?
- What is the premium charged by an independent distributor for taking on the risk of selling 400, 900 or 1800 machines?
The bigger and more expensive the products are the less likely it is that this approach will work. It might work for SoMs, HMI terminals or ECUs but it needs a thorough cost-benefit analysis.
Stocking chips for several months got Toyota fairly unscathed through the chip shortage of the first year of the COVID pandemic. It takes a risk assessment to know when to stock supplies and when to produce just-in-time. Toyota had learned its lesson from the chip shortage caused by the Fukushima nuclear incident in 2011.
EU CRA: Essential Requirements Related to Vulnerability Handling
As a manufacturer, you must define and implement processes (Article 6b) that comply with the essential requirements for vulnerability handling of Annex I Part II. In particular, these processes shall enable you to detect vulnerabilities in all software and hardware components of your embedded system, to remediate them according to their risk, to notify users and to provide timely security updates.
A vulnerability scanner like Yocto’s cve-check produces a list with hundreds of known vulnerabilities, of which many are not yet fixed. The CRA demands that you release your products without any known exploitable vulnerabilities (Annex I.I.2a). But which vulnerabilities are exploitable? Good vulnerability management tools like ARIANNA and the Torizon Vulnerability Manager can sort out most irrelevant vulnerabilities quickly and reliantly.
This leaves one or two dozen relevant vulnerabilities that you feed into the risk assessment of the essential product requirements. You can mitigate, accept, avoid or transfer these vulnerabilities - depending on the risk they pose to your specific embedded system.
EU CRA: Essential Requirements Related to Product Properties
I explain the essential product requirements of Annex I Part I with examples from the machines and devices I have helped build over the last two decades. The examples breathe life into the vague requirements. As manufacturers, you should know the requirements by heart. You must check in the risk assessment whether interactions between humans, processes, embedded systems, cloud services and suppliers violate any of these essential product requirements.
The drafts of the vertical standards for important products may be a good source for understanding the essential requirements related to both product properties (Annex I Part I) and vulnerability handling (Annex I Part II). The standard draft for routers, modems and switches (PDF) could be a good starting point, as these devices are embedded systems. These drafts are no easy reading but necessary reading.
Keep in mind that these vertical standards are for important products. Your products will most likely be default products. Hence, your default products must only satisfy a subset of these requirements and can use weaker security measures. You justify in the risk assessment how much security is enough for your product.
The authorities may disagree with your assessment. If you put in a serious effort to make your embedded systems more secure, the authorities will typically be lenient. If you try to fool the authorities, you are in for a well-deserved fine of up to 5 million Euros or 1% of your annual global revenues, whichever is higher (Article 64.4).
Embedded Devices Covered by the EU Cyber Resilience Act (CRA)
TL;DR: All embedded systems are subject to the CRA.
Embedded systems like medical devices for human use, cars, marine equipment or civil aviation systems are not subject to the CRA, because typically stricter regulations exist for them already. If some rules in existing legislation are weaker than those in the CRA, the CRA rules prevail.
Taken individually, tamper-resistant SoCs, container runtimes, boot loaders, browsers, 5G modems, Ethernet/WiFi interfaces and operating systems are important class-I or class-II products. If you integrate these things, for example, in the driver terminal of a harvester or excavator, the terminal is a default product.
Telematics units are important class-I products, as they have the core functionality of a modem (Article 7.1). However, a harvester comprising a driver terminal, a telematics unit and 25+ ECUs is a default product. By integrating an important or critical product into a (default) product with a different purpose, you can save a lot of effort for the risk assessment.