I have shared my impressions of the CRA before in writing[1] and was surprised to hear that a Draft Guide for the CRA was issued for comment[2]. Taking a deep breath, I spent several days reading, taking notes and submitting several comments and suggestions to the organizers. To make a complete study would require tracking down and reading the various references to the CRA and other documents but here are my impressions of this draft guide as presented for comment.
First impression: lots of IT here and not enough ICS
One of my submitted comments was to point out a SOHO IT bias in the draft Guidance which should be balanced with language relevant to control systems that monitor and control processes rather than focus on data or information processing.
One gets this impression after reading this document. A simple word count of key terms gives the IT bias away.
SOHO IT related
Computer – 14
Hardware – 32
Information – 38
Information system – 13
Network – 27
Process (ing) related to data – 83
Protection (related to data) – 7
Printer – 3
Router – 4
Software – 195
Smartphone – 7
Server(s) – 14
Industrial/OT/Process Control Related
Actuator – 0
Automation – 1
Industrial control system – 2
Industrial control procedure – 10
IED – 0
Loops (Control/Closed) – 2 (an engineer put that in !)
OT – 0[3]
PLC – 0
Process (ing) related to data – 83
RTU – 0
Sensor(s) -0
Safety – 5
Transmitter – 0
What is being protected, what is missing.
As I had commented earlier, the CRA gives a vague definition of what it seeks to protect. I was keen to see if any additional explanation was provided in the guidance. No, it kept the same definition: “a software or hardware product and its remote data processing solutions, including software or hardware components being placed on the market separately.” The CRA gives some examples[4] of what it considers to be products[5] with digital elements (PWDE) but it is interesting to note the examples used considering that this is an implementation guidance. The examples given in the guide are most curious. After restating the PWDE definition the examples this time are “network printers” and “fitness wearable.” The latter example was most surprising as this was also mentioned in the US Cybersecurity Strategy of 2023 which I criticized for its failure to mention more appropriate examples of devices used in critical infrastructure like the PLC[6][7].
I take this to be a bad sign that much of the focus of the CRA is about SOHO IT, software and SOHO IoT leaving out the technologies used to monitor and control processes governed by the laws of physics and chemistry found in critical infrastructure. Referring to the Guidance section 1.2 (4) the purpose of the guidance focused on “facilitating compliance by microenterprises and small and medium-sized enterprises (SMEs)”[8]. In my submitted comments I recommended that it should be explicitly stated in the scope language that larger entities responsible for operations of critical infrastructure such as operators of power generation, transmission and distribution, water utilities and transportation systems (rail) are not covered in the CRA – although many “products with digital elements” are key enablers in critical infrastructure services and for their security and safety. This is a BIG GAP in the CRA and will do nothing to protect us from attempts to disable safety systems at oil refineries or protection devices on power grids. I do not know where or when this gap will be addressed, perhaps a new cyber resilience act that applies to critical infrastructure will be considered someday.
It is not just about the data; it is also about monitoring and controlling a physical process
In the data connection section 2.4 nr. 23, there is inadequate understanding of connecting to a control system. It is just not about networks, the devices, and software that make up a control system. Some of these devices do not need to be on a network to perform their function. In my comments I noted that missing is a recognition of a PWDE’s independent capacity to monitor, regulate and/or cause change in the physical process. If the network goes down the physical process will still do something. Since the CRA limits itself to SOHO/SME this aspect is out of scope, but what will be done to address the gap? It is not covered in NIS2 either.
Who is responsible for all the heavy lifting in implementing the CRA
In one of my submitted comments I made note that much responsibility in the CRA and Guidance is assigned to the Manufacturer (the word is used 346 times in the Guidance) of the PWDE. It is not adequately clear what the responsibilities of the system integrator and the asset owner are in the CRA. I work in one of the ISA 99 Workgroups that are writing security profiles for substations. Many of the members, including representatives of manufacturers, system integrators and asset owners are engineers who work or have worked in operations found in the electric sector. Separate sections in the profiles are specifically dedicated to the manufacturer, integrator and asset owner. The Guidance has a gap here or it needs to explain more clearly about roles and responsibilities of these players. Maybe this is ok for SME’s but not for operators of national power grids, refineries or pipeline systems.
In designing and preparing for system (for example in building a substation on a power grid, a pumping/compressor station on a gas pipeline) acceptance the system integrator may employ many different PWDE sources from different manufacturers. Many operational, security and safety issues may arise from assembling these PWDE into a complex system for performing a function or task that will need to be managed by the integrator. Who, in turn, will present a designed and assembled system to the asset owner after acceptance testing. In my submitted comments I suggested adding additional guidance language that directly addresses the peculiar concerns and role of the system integrator and asset owner. This lack of focus on the other roles in the process represents additional gaps in the CRA guidance.
Why does the CRA guidance only focus on the responsibility of the manufacturer? I realize now that this may be because of the limited scope of the CRA. Then in terms of protecting critical infrastructure from cyber-caused incidents, the CRA provides only partial coverage and that is not enough considering the growing number of serious incidents in C.I.
Limitations of those who write these policy documents
In my submitted comments I recognized that there is an impressive list of specialists belonging to the CRA group of experts*. They are good people and impressive representatives from their field of work. However, it is not clear how many experts in the group have backgrounds in engineering and most especially experience in working in operations found in critical infrastructure[9]. Those that have experience in working with the technologies used to monitor and control processes governed not by the laws of data protection and privacy, but by the laws of physics and chemistry. I suggested that, if they are not already in the group, that group consider inviting automation and protection engineers, and Hazop professionals to assist in addressing the gaps in CRA coverage of critical infrastructure operations. Or at least to start working on a new document (CRA4CI)[10] to address the gaps specifically.
Thanks,
Vytautas Butrimas
Vilnius 2026-03-31
*Here I am forced to be humble. I am not an engineer, but rather someone who has an IT background who has come through years of experience and collaborations with engineers. I fully appreciate the importance of understanding the environments found in critical infrastructure that can only come from hands-on experience in operations. When this understanding is lacking IMHO, poor policy will result.
[1] http://scadamag.infracritical.com/index.php/2023/09/19/the-european-union-moves-to-regulate-its-digital-economy-by-proposing-cybersecurity-requirements-is-the-cra-a-bridge-too-far/
[2] https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en
[3] I hate the term “OT” but its appearance and some mention of it in the text would be better than nothing.
[4] https://www.european-cyber-resilience-act.com/Cyber_Resilience_Act_Article_3_15.9.2022.html
[5] I made an error in thinking the definition used the word “device.” Is it an important distinction, I do not know. I checked back to the CRA text, and the word used is “product.” Still, it seems a poor choice when a more technical term could have been used such as “device.”
[6] http://scadamag.infracritical.com/index.php/2023/03/15/impressions-of-the-u-s-national-cybersecurity-strategy-of-2023/
[7] https://www.linkedin.com/pulse/protecting-baby-monitors-plcs-impressions-us-national-butrimas/?trackingId=sXzA7jOIRm2sxweVmzQsIw%3D%3D
[8] https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959-Draft-Commission-guidance-on-the-Cyber-Resilience-Act_en
[9] https://ec.europa.eu/transparency/expert-groups-register/screen/expert-groups/consult?lang=en&groupId=3967&fromMembers=true
[10] Cyber Resilience Act For Critical Infrastructure
