The Cyber Resilience Act (CRA) is an EU regulation that affects any digital product that can interact with another device or a network. For machine builders, this means that connectivity such as remote support, cloud connectivity or Bluetooth interfaces trigger obligations, including cyber risk assessments, an incident response team and a CE declaration of conformity.
Key Takeaways
- The Cyber Resilience Act affects any digital product that has the ability to interact with another device or network, i.e. not only when it is actually connected, but as soon as this ability exists.
- Those who involve external consultants and CISOs at an early stage secure more favorable conditions, as increasing demand from many affected companies is driving up the market prices for security experts.
- Machine manufacturers that use remote support, cloud connectivity or over-the-air updates are just as affected by CRA as pure software companies, because machine connectivity is the decisive factor.
- The biggest obstacle to CRA implementation is not in the development team, which is responsible for the issue, but in management, which does not accept additional costs, even though a missing CE declaration of conformity blocks sales in the European market.
- A well-maintained security backlog with known vulnerabilities helps when starting the cyber risk assessment because the team can immediately assess which vulnerabilities are actually relevant to a reported vulnerability.
Who the Cyber Resilience Act affects
The Cyber Resilience Act affects any digital product that can interact with another device or network. What matters is not whether a product actually communicates, but whether it has the ability to do so.
This means that almost everything that contains software falls under the regulation: from a smart coffee machine to a washing machine with an app to a networked industrial machine. A woodworking machine that is connected to the customer network or the internet is just as much a part of this as a Bluetooth caliper gauge or a barcode scanner with a wireless connection.
There are exceptions, but they are narrower than they appear. Pure web services and websites that are not embedded in an app are excluded. Open source is partially excluded. However, as soon as you use open source software in your company, you are responsible for it again. Changes can also be expected here in the long term.
Why connectivity makes mechanical engineering a software topic
As soon as a machine is connected to the network, security becomes an obligation. This is true even where software has long been considered a marginal phenomenon.
In traditional mechanical engineering, software was often a necessary evil. This is exactly what is changing. Networked machines, cloud data collection and remote support are fundamentally changing the picture. For some machines, support is now provided exclusively via remote solutions; no one has to travel there anymore. This saves time and effort, but means that the machine is permanently connected to the internet.
This permanent connection results in specific areas of attack. Operating system, firewall, antivirus software - all of these need to be taken into account. Christoph Ranalter, responsible for quality at a Tyrolean mechanical engineering company, soberly describes the driving force as user convenience:
Why can I operate my refrigerator remotely? It’s a convenience. And it’s the same with our machines.
For the small carpenter, the benefit is less in productivity than in information: seeing how far the machine is, realizing that material is running out, and planning for both on the way to the machine.
How to find out if the regulation affects you
The first step is a screening, ideally with advice at your side. In the case of legislation and a later self-assessment or audit, the classification must be right.
The screening answers two questions: Does the regulation affect us? And how much time do we have? For a manufacturer of networked machines, the first answer is almost always “yes”. The second answer has shifted in the course of the legislative process. Originally, there were twelve months after adoption to set up the incident response team and fulfill the reporting obligation to ENISA. In the revised proposal, this has become 21 months.
However, more time does not mean less pressure. Many companies will be taking measures at the same time, and the number of security experts on the market is limited. Those who clarify early on with partners and external support will secure capacity before increasing demand drives up daily rates.
CRA and NIS2 often come in a double pack
Anyone dealing with the Cyber Resilience Act will quickly come across NIS2. Both topics often appear in parallel, even in companies that initially do not think they are affected.
The common reflex is: We are not a critical infrastructure, so NIS2 does not affect us. However, the extension to “important” or necessary facilities widens the circle. The manufacturing industry is broadly covered. Even supply relationships can become relevant: If a company supplies a hospital and works together on the software side, NIS2 can take effect.
In practice, both topics can be bundled. An external CISO as a service can initially drive forward NIS2 and the same person can also take on CRA consulting.
This is what a pragmatic roadmap looks like
A sensible sequence starts with training and leads via the cyber risk assessment to the incident response team. There is a clear reason for this sequence.
A reported vulnerability can only be assessed once the risk assessment has been completed for all machines. Without this basis, you cannot assess whether a vulnerability is urgent or can be ignored.
The rough scale looks like this:
| Phase | Content |
|---|---|
| Start | Training for developers and software architects |
| Afterwards | Cyber risk assessment for all machines |
| Following year | Set up incident response team |
| Parallel | External CISO handles NIS2, advises on CRA |
With the incident response team, the question of personnel arises: recruit new staff or train existing ones. As good security experts are rare and expensive on the market, it often comes down to internal training. The price for this is speed. If you invest developers in training and new tasks, you noticeably lose speed when it comes to features.
The developer mindset is usually already there
The biggest hurdle is rarely in the development team, but in management. Security is often met with approval rather than resistance from developers.
Many have previous experience and training from their studies. Statements such as “hard-coded passwords are not cool” are not new learning material, but already accepted attitudes. What is missing is routine: in most cases, no one in such teams has ever carried out a risk assessment themselves. The mindset is right, but the process first needs to be solidified.
In management, the discussion revolves around money. More effort for the same machine price is unpopular. An honest calculation helps here: without CRA compliance, the first machines may not be sold because they are subject to funding guidelines that require this standard. Because the end result is a CE declaration of conformity, in extreme cases the entire European market is at stake.
Security backlog instead of fire alarm
An ongoing security backlog makes more sense than waiting for the first penetration test. This is where vulnerabilities that are discovered during development end up, along with the question of the expected damage.
One example is the inter-process communication between the PC software and the machine controller. This communication should be encrypted to ensure integrity. The consequence of a lack of encryption, such as a man-in-the-middle attack, is technically conceivable, but unlikely for the end customer. An attacker would first have to gain access and then invest a lot of time.
This risk assessment is precisely the point. A backlog keeps such issues visible without every theoretical vulnerability immediately blowing up a sprint. If the regulation forces the effort, the backlog can be worked through in a targeted manner, with the necessary additional time.
Which tools help with secure development
Static code analysis is a realistic place to start because many manufacturers of such tools now integrate security guidelines. There is a clear trend towards further expanding these checks.
There are also tools that issue warnings directly in the IDE, for example if a package used has a vulnerability, and immediately refer to the version that needs to be fixed. Such tools start early, during programming.
One caveat remains: Not every tool covers every environment. In a company with a large Windows and a large Linux world, some tools only work for one side. If you operate several platforms, you should check the coverage before making a selection instead of being dazzled by the range of functions.
Software becomes a differentiator
In mechanical engineering, competition is shifting from mechanics to software. Many providers have mastered sheet metal welding, even in the low-price segment. You can’t win on price in a high-price location like Tyrol.
That leaves quality and innovation. And the majority of new features today are either directly software or require software in order to function. This also increases the appreciation of software in sectors where it has long been of secondary importance.
The advice to anyone who comes into contact with the topic is therefore unequivocal: deal with it early on, because it’s coming anyway. It remains to be seen whether the CRA, like the GDPR, will lose its excitement over time. Cyber damage will not, and with better tools, attackers will also become more powerful.
