EU Cyber Resilience Act 101 for Embedded Developers
I spent time reading this 338-page act so you don’t have to!
The EU Cyber Resilience Act (CRA) was voted through the EU Parliament in March 2024. All that’s now needed is EU Council assent in the coming weeks, and it becomes EU law.
Here are the questions about CRA that are probably on your mind. Answers too!
Q: Is the CRA an actual law that will be enforced – if so how will that look?
A: Yes. The EU can issue Directives and Acts. While Directives are just instructions to member state legislatures, Acts like the CRA actually have immediate force of law. If you want your product to be CE marked, you will need it to be certified as compliant with the Cyber Resilience Act in addition to prior legislation. As with CE marking, for most product categories, you “self-certify”. However, the penalties for non-compliance start at €15m.
Q: Does the Cyber Resilience Act definitely affect me if I’m in the UK, US, or somewhere else outside the EU?
A: If you normally CE mark your products so that you can sell them in the EU, then it’s a “yes” I’m afraid. If you don’t ship to the EU, or your products are non-commercial, then you don’t have to comply.
Q: OK, what is required for an embedded system to comply with CRA? Just the highlights please.
A:
- The CRA is centred on a “risk-informed” approach. You need to conduct a risk assessment to understand the extent of measures required.
- You need a “Secure by default configuration” and to “protect the integrity of stored data/programs”. This means you should consider implementing authentication via Secure Boot.
- “encrypting relevant data at rest or in transit”. So, secure storage, and/or TLS required.
- “ensure that vulnerabilities can be addressed through security updates” You have to identify vulnerabilities as they arise, and the system must be field updatable. “provide for mechanisms to securely distribute updates”. Vulnerabilities must be addressed for 5 years, security updates distributed f.o.c.
- “identify and document vulnerabilities and components by drawing up a software bill of materials (SBOM)”. This could be delayed as the format is to be defined by a working group, but that’s not guaranteed, and you will probably need an SBOM to know where to check for vulnerabilities.
Q: What about Open Source?
A: Open-source software is mentioned 59 times in the Act, so it has not been overlooked following an initial outcry – but any protections are more aimed at the open-source community than OEMs using Linux etc.. A special working group (“ADCO”) is to be set up. But I don’t see any special exemptions, and it will fall on developers and the open-source community to come up with compliance routes. No magic wand being waved so far.
Q: Seems quite onerous! Surely there’s a “grace period” for all this?
A: Yes! The act will be adopted at some point mid-2024, and there is a 36-month grace period from which point it will apply to any product which is from then first sold commercially or “substantially modified”. However the act does confer liability for significant vulnerabilities on the vendor 18 months before that.
Q: You’ve got my interest. Where can I read the details?
A: I’m going to produce a series of newsletter emails highlighting different aspects of CRA, meanwhile here is the Act itself: https://www.europarl.europa.eu/doceo/document/TA-9-2024-0130_EN.pdf be my guest!
What this means for embedded developers
The Cyber Resilience Act applies both to new and existing products. So as well as ensuring that your current project complies, there’s a question mark over existing products. Clearly 3 years isn’t enough time to redesign all legacy products, so some OEMs are adopting a “wait and see” approach, while others, mindful of the potential market advantage are pressing ahead with redesign.
Since part of our professional remit here is within the safety-critical and medical product development fields, we’re already seeing what meticulous consideration of CRA looks like.
The most important items to start thinking about are secure boot, and a secure update process (ideally OTA), as these may be difficult features to add retrospectively.
As projects in general embedded markets kick off which may not ship by mid 2027 we expect to see a flurry of compliance concerns. Maybe customers will be spurred to move to a commercial OS, where some of the compliance work is already done by the vendor? Maybe a compliance route for Linux will emerge? – I don’t know right now.
Future posts are planned with a deeper analysis of this topic. I plan to cover the interpretation of the act with a sharper focus, and also the technical and project implications, including topics such as hardware root-of-trust and secure boot, over-the-air updating, encryption and documentation. – sign up here for updates.
Next post in series: EU Cyber Resilience Act (CRA) – where do I start?`
David Pashley