The Device Chronicle interviews Sarah Fluchs, CTO, Admetria, and noted OT cybersecurity expert on the EU Cyber Resilience Act compliance requirements. Sarah is trained in mechanical and automation engineering. In 2017, she started working on cybersecurity for automation as a topic in a role at the German Federal Office for Information Security.
Now, Sarah is the CEO of Admetria, which does OT cybersecurity consulting and offers a software product for managing OT cybersecurity. As a domain expert in operational technology cybersecurity, she also consults for government agencies and is a CRA Expert Group: Type A Member for the EU Cyber Resilience Act (CRA).
The EU CRA Expert Group involves consulting the EU Commission on implementing the CRA in industrial settings. Sarah's role is to translate and amplify industrial product manufacturers' concerns about the CRA back to the EU. Sarah has tremendous experience in standardization work and contributes to the work of the EU CRA Expert Group through her knowledge of industry discussions on risk assessment from her experience as a Co-Convenor on the IEC 62443 3–2 committee for risk assessment.
Sarah begins by stressing that compliance requirements for the EU CRA is not necessarily dependent on the kind of product an OEM offers.
She stresses that “All products with digital elements (PDEs), as defined by the CRA, that are on the commercial market in the EU have to meet the exact requirements. There are a few specific industries, such as medical or military, that are exempt but that is due to pre-existing regulations already in place. The most crucial aspect for OEMs to remember is that all requirements are risk-based.”
Sarah further explains that the first step is to conduct a risk assessment for the product (digital asset), followed by extensive documentation of any discovered risks or gaps. The OEM must adhere to product-specific security requirements that concern product characteristics. There are 15 items that OEMs need to consider, such as ensuring access control, ensuring that data is encrypted, and considering the process for designing the product. Vulnerability handling is critical; the product itself or the components within the product must be free of vulnerabilities, and a process needs to be put in place to monitor for vulnerabilities and to be able to provide updates for the entire product lifespan. If the OEM becomes aware of an actively exploitable vulnerability or a severe incident, it must notify official bodies within the EU country in a timely manner.
She continues, the CRA applies if a product, such as hardware or software, is placed in the EU market. However, if a vendor places a service on the market and a product is used to enable the service, the EU CRA does not apply.
The product characteristics and requirements of Annex 1 must apply to the embedded software. The CRA does not explicitly tell OEMs how to do this; it more so mandates “secure by default” design, and comprehensive and ongoing lifecycle requirements that are non-negotiable.
Harmonized standards across Europe will be published in the Official EU Journal. They will address essential requirements such as vulnerability handling and specify horizontal and vertical standards. For secure software development, you must ensure all requirements are adhered to.
All harmonized standards do not reinvent cybersecurity; they follow standardized software development lifecycles, such as IEC 62443 4-1. The harmonized standards will be released in the coming years, so use existing standards for orientation.
Sarah explains that the EU CRA says OEMs should apply automated update mechanisms, and over-the-air updating mechanisms support this, but it is situation-specific. If there is a risk that automated updates could void a warranty, then there is a condition in the EU CRA that allows them to be disabled. Additionally, standardized machine-readable advisories are being developed and applied. These advisories specify which updates should be applied based on the vulnerability affecting the product's software bill of materials (SBOM). OEMs and affected customers can determine the effect of a vulnerability.
Sarah shares her perspective on the applicability of OTA and it is one that is shaped by her specific perspectives from working with industrial automation and control systems. She says, OTA is applicable in situations where the most important thing is a non-burdensome update process that goes quickly, where users do not have to do much, or have much to worry about. This requirement for a non-burdensome update process is weighted to be more important than the absolute uptime or reliability of the component. Sarah argues that OTA may not be suitable if it is critical that an element should not be changed by the asset owner (on the factory or plant floor) and that it should work precisely as configured.
She adds, “If there are scenarios where the users working with the component will not have the capacity or time to manage the updates, and the updates must be done frequently, and if it does not matter if the component goes out of service for a short period, then OTA is more efficient.”
Sarah concludes by sharing that nothing about the application of OTA is black and white: she provides the example of the German Office of Information Security recommending applying automated OTA updates to all IoT devices (BSI TR‑03173: Conformance Assessment of IoT Devices). However, they stress this is still a risk-based decision. The OEM must assess Internet connectivity risk factors and make an informed choice when selecting an OTA.