EU Cyber Resilience Act (CRA) – where do I start?
(a.k.a. do I really need to start yet?)
These are the questions I hear quite often. On one hand, it’s all there in black and white in the CRA, in 3 years’ time compliance will be mandatory. No compliance, no CE mark, and no shipping to the EU.
On the other hand, 3 years is quite a while, and perhaps my current project will be on the market by then and therefore be exempt? Maybe the 3 years will get extended? Maybe for non-EU manufacturers there will be an additional grace period? Surely no-one will worry about existing products?
All entirely possible scenarios, but I’m afraid to say that current evidence is more about the screws tightening rather than loosening. And my advice is to stop seeing the Cyber Resilience Act as a problem, because it can be an opportunity.
Keen-eyed readers will have noted on the news that last month’s King’s Speech included a UK “Cyber Resilience and Security Bill”. It’s likely that this will at least include the UK enactment of the EU CRA provisions as well as the more IT-centric (but also wide-ranging ) EU NIS2 Act. Having dissimilar regulations in place would be a disaster for trade, and once regulations can be harmonized there is a “Mutual Recognition Agreement” mechanism within EU CRA which opens the door to interchangeable conformity and compliance arrangements.
The idea that if you can get your product to market beating the 3-year deadline you’re off the hook is an illusion. Although their might be safety in numbers for legacy products, the CRA provisions still apply, and so you will not be able to CE-mark your products. Whatever the out-turn in relation to enforcement for legacy products, compliant products will have a massive commercial advantage.
OK! OK! Let’s get started. Where exactly do I begin?
The first step is a risk assessment that will guide the cyber resilience aspect of the project and become the backbone of your documentation. To understand the importance of this requirement, you have to read what the Cyber Resilience Act actually says, not rely on the bullet points in the Annexes. The Act explicitly requires:
“manufacturers shall undertake an assessment of the cybersecurity risks associated with a product with digital elements and take the outcome of that assessment into account during the planning, design, development, production, delivery and maintenance phases” [Article 13(2)]
So the first step is to know how to undertake a cybersecurity risk assessment, and to perform that assessment against the planned product, and the associated development process, and with regard to the whole product lifecycle.
This assessment must be provided to end-users and maintained for the lifetime of the product. It will also guide the rest of the process.
Moving on, and setting out a framework, following the overarching cybersecurity assessment – with the details of course depending on the conclusions of that assessment – our project is likely to include the following features, many of which will be new to the development team (this list isn’t intended to be exhaustive):
- Secure boot via a hardware-based root of trust. The CRA mentions authentication, and also mandates updating, so secure boot is the obvious way to ensure that only the signed firmware, application and file system can be loaded. Its implementation is hardware-specific.
- Filesystem encryption using a secret key held in hardware. The method of key generation and storage is device-specific. Often, keys can be held securely by the application processor’s cryptographic sub-system. These can be used within that subsystem to decrypt data which in turn can then provide keys to decrypt other data in a “merkle tree” arrangement.
- Transport Level Security (TLS). Although the data on the device may be encrypted at rest, once in use it will usually be decrypted and so all interfaces to the outside world must be secure.
- Generation of an SBOM (Software Bill of Materials) in an approved format
- A starting-point vulnerability assessment, based on the SBOM, and taking into account the threat model, and a mitigation plan
- A documented ongoing monitoring, reporting and mitigation process for vulnerabilities which occur during the product lifetime
- A mechanism to issue and provision secure updates, free of charge – therefore OTA (Over-the-Air).
- Compliant project and product documentation
- A documented risk assessment including threat modelling and mitigation
- A formal conformity assessment procedure
Perhaps these should be the subject of a blog post each? Now the holidays are pretty much over I want to get to more regular posting on the Cyber Resilience Act. Let me know what you think, and please sign up here for the mailing list which will ensure you receive access to each post in full!
P.S. This is Part 2 in a series – part 1 here. Next, part 3: EU Cyber Resilience Act and the Regulatory Landscape