EU Cyber Resilience Act and the Regulatory Landscape
On October 10th 2024 I was giving a talk on the CRA at the UK Engineering Design Show. I mentioned on a slide that it was possible that the CRA might be adopted by the Council on that day – and I was correct! Next, a few signatures have to be gathered, then the Act will be published in the EU Journal. 20 days later it will become law.
After my talk there were some very good, detailed questions. I couldn’t answer them all on the spot. One problem is that there is not yet any established best practice, and at the same time, the CRA is lacking in technical detail. It stipulates that we start with a Risk Assessment, and then implement its requirements accordingly, which further broadens the uncertainty.
It’s important to remember that the Cyber Resilience Act is a regulation not a “standard”. This means that it is by nature a legal rather than a technical document. Actionable detail is lacking, but unfortunately this can’t be used as an excuse for non-compliance. Over the coming years, EU harmonized standards will fill this vacuum. While some of these standards may be new, experience suggests that most of the gap will be filled by pointing to existing standards.
What will this look like? Fortunately, the CRA doesn’t exist in isolation, and to get a sense of how to deliver compliance, it’s therefore reasonable to fall back on an understanding of other regulations and standards. Understanding of the regulatory landscape is also necessary to make sure that we know exactly which regulations and standards actually apply to our products.
PDEs outside the scope of the CRA
The Cyber Resilience Act mentions some regulations simply in order to specify that if our Product with Digital Elements (PDE) is caught by those, then the CRA does not apply.
Medical Devices subject to Regulation 2017/745 or 2017/746 are excluded. At first reading, it’s hard to see why these regulations, which in their texts offer little concrete guidance on Cyber Security should be a preferred compliance route over CRA. However, these regulations have already been “fleshed out” with actionable guidance by the EU’s Medical Device Coordination Group (MDCG), in particular MDCG 2019-16 mirrors many provisions of the Cyber Resilience Act, while offering detailed guidance, and is worthwhile reading for anyone contemplating CRA compliance for a non-medical product for that reason alone.
Automotive Devices subject to 2019/2144 are similarly excluded
Aviation systems subject to 2018/1139 are also exempt
Finally, a broad exemption is given for any PDE developed “exclusively for national security or defence purposes”
Regulations and standards which overlap
ETSI EN 303 645
Published in 2020, this EU standard has been widely adopted and referenced in various EU-wide and national regulations, including RED (EU Radio Equipment Directive) and the UK’s PSTI (of both of which more below). Like CRA it is device-centric, however unlike CRA it restricts its scope to consumer devices.
Because ETSI EN 303 645 is a standard rather than a regulation, it’s far more accessible than the CRA in terms of getting to the technical specifics of compliance. It has 13 “Chapter 5” provisions (each with sub-provisions). So for example, 5.7 is “Ensure Software Integrity”, which is also something stated in CRA. However, rather than beating about the bush, we have “Provision 5.7-1: The consumer IoT device should verify its software using secure boot mechanism”, and so on.
This level of detail means that ETSI EN 303 645 can to some extent be our “how-to” guide for achieving EU Cyber Resilience Act conformity once we have decided what cyber security features to embrace. ENISA, the EU body charged with oversight and development of the CRA has issued a “Standards Mapping” document which strongly references ETSI EN 303 645, supporting the view that compliance with a particular clause is likely to be at worst adequate, and at best the gold standard, as a way to demonstrate conformity with the relevant clause in CRA
PSTI
The UK’s Product Security and Telecommunications Infrastructure Regulations came into force in April 2024. Relying on ETSI EN 303645 which is frequently and directly referenced, PSTI again is focused on consumer IoT devices. UK manufacturers of consumer devices are therefore highly focused on PSTI compliance. In general, it is slightly less demanding than the CRA. The UK Government has announced a forthcoming “UK Cyber Security and Resilience Act” which will no doubt closely mirror the CRA and other European regulations, directives and standards.
RED
The EU Radio Equipment Directive 2014 – updated in 2024 with cyber security provisions, and referred to as RED II – is a Directive rather than a Regulation, setting high-level requirements for all radio-communicating devices which are then brought into law by EU Delegated Regulations (usually per country). A new standard – EN 18031 – covers these new provisions, and also many requirements are underpinned by ETSI EN 303 645. These standards are certainly required reading if the PDE contains a radio.
Cyber Trust Mark
This is the US’s voluntary equivalent of ETSI EN 303 645. According to the FCC website “the FCC is creating a voluntary cybersecurity labeling program for wireless consumer IoT products.” Nothing for industrial devices so far. Interesting in so much as many vendors will want to mark their devices – the scheme is open to foreign entities, but the product must be in-scope. The underlying standard is NIST IR 8425.
Another valuable source
The IoT Security Foundation (IoTSF) provides both input and guidance on Cyber Security regulations and standards which affect the IoT. The IoTSF publishes an “Assurance Framework” which as a 2021-dated PDF is surprisingly useful and comprehensive. I believe there are plans to update this and make it an interactive resource.
Conclusion
ETSI EN 303 645 is a particularly good source of practical guidance for anyone striving for Cyber Resilience Act conformity. Standards mapping and the introduction of any further harmonized standards are likely to reinforce this link and mean that where a CRA provision is covered by EN 303 645, compliance will be exactly what is required – the problems will come where the CRA provision doesn’t exactly match. I also recommend reading of MDCG 2019-16 and PSTI as well as the IoTSF Assurance Framework.
Thank you for reading. This is the 3rd blog article in an ongoing series. You can jump to the first article here – CRA 101. If you’re interested in the topic, please join my mailing list by adding your email address here.
David Pashley