The Cyber Resilience Act: Why product safety should be part of the development process

From 11 September 2026, manufacturers of connected products must report actively exploited vulnerabilities and serious security incidents within 24 hours. On 11 December 2027, all remaining requirements of the Cyber Resilience Act (CRA) will come into force. From then on, breaches will be subject to fines of up to 15 million euros or 2.5 per cent of global annual turnover. (BSI: Cyber Resilience Act)

The timeframe until then sounds comfortable. It is not, however, if responsibilities, processes and expertise still need to be established. And that is precisely the case for many manufacturers.

The CRA is a product issue, not an IT issue

With NIS2, many companies have learnt how to organise information security. The information security officer or CISO, often based in the IT department, takes care of this. It would seem obvious simply to add the CRA to their remit. But that doesn’t work.

The CRA governs the security of products containing digital elements. It therefore concerns what a company develops and sells, not its own infrastructure. As such, it falls under the remit of the CTO, development management and the development teams. Prof. Dr Dominik Merli from the Augsburg University of Applied Sciences made this clear in the ‘Cybersecurity Basement’ podcast: IT operates the infrastructure and actually has no say in product development. Nevertheless, its expertise – for example, in cryptography – can still assist development teams.

It is crucial that someone within the development team takes responsibility for security. Some companies create a dedicated role for this: the Product Security Officer. They drive security forward within the development processes and are therefore closer to the product than a traditional Head of IT.

Embedded systems require bespoke solutions

A server or a cloud environment follows standards. A machine control system, on the other hand, is often a proprietary development: its own circuit board, different chips, sometimes running Linux, sometimes with no operating system at all, and sometimes with integrated safety functions. One-size-fits-all security solutions do not work here.

The example of remote maintenance illustrates just how specific these questions can become.

• Can the device communicate via TLS?

• Is there sufficient processing power for cryptography?

• And can the device even authenticate itself unambiguously, for example via a certificate and a private key?

According to Merli, identity management in particular has so far been somewhat neglected by many manufacturers. Anyone who operates plant is also familiar with the typical OT hurdles: tight maintenance windows, limited patchability and protocols that traditional IT tools struggle to handle. A network scan whilst the system is running can, in case of doubt, do more harm than good.

The risk analysis first identifies the risks, then the measures

The CRA requires an assessment of the cyber security risks for every product. The starting point is a shared understanding of the system: what does the product do, what components does it consist of, and where is it used? The threats faced in a public sector environment, a power station or by a private customer are completely different.

Then it becomes an interdisciplinary process. Alongside the development team, senior management, safety officers, support and service teams each contribute their own perspective. Does the greater risk stem from espionage or from sabotage? Which functions must not fail under any circumstances? What happens at the customer’s site if the machine is attacked?

A common misconception is that the analysis culminates in a ready-made action plan. Its primary purpose is to identify the relevant risks. Only on this basis can protective measures be sensibly prioritised. There are no five standard measures that will make every device secure. Merli explained in the podcast that such an analysis takes several days to complete and that an initial assessment can be achieved within one to two weeks.

Vulnerability management is more than just an email address

The CRA requires manufacturers to investigate and assess vulnerabilities and to provide updates in a timely manner. Vulnerabilities that are being actively exploited must be reported to the relevant national CSIRT via a central reporting platform: as an early warning within 24 hours, with a report within 72 hours and a final report no later than 14 days after a corrective measure has been provided. (European Commission: Cyber Resilience Act – Reporting obligations)

This presupposes that reports actually reach the relevant parties. A simple first step is to include a security.txt file on the website, showing where security researchers, customers or partners can report any vulnerabilities they find. However, a reporting channel alone is not enough. In the podcast, Merli talks about a multinational corporation which, although it had a good reporting form, failed to respond for months. It took a year for a patch to be released, following repeated follow-ups and the involvement of the BSI.

Attitude is also important. A reported vulnerability is not a scandal, but part of everyday life. It only becomes a problem if it is not taken seriously or if there is no process in place to rectify it.

A self-declaration is quick to sign, yet remains vulnerable

For most products, a conformity assessment carried out by the manufacturer itself is sufficient for the CRA. For important and critical products, external bodies must be involved, depending on the category. There is no separate CRA marking. The requirements are incorporated into the CE marking.

The temptation to quickly fill in a self-declaration is strong, particularly when it is unclear what risk analysis and vulnerability management are required to achieve. Anyone who has invested heavily in processes, documentation and protective measures is unlikely to stand idly by whilst a competitor bears the same CE marking with significantly less effort. Reports to the authorities and enquiries regarding technical documentation are then a realistic consequence.

I firmly believe that we will see one or two negative examples that make it clear: If you do not meet minimum standards, then you have no place on the European market.

Prof. Dr Dominik Merli, Augsburg University of Applied Sciences

Responsibility cannot be outsourced

External partners can contribute methodology, facilitate workshops and build up expertise. However, it is the company itself that decides which measures can be implemented in a product and how they fit into the development process. The CRA therefore demands one thing above all else: internal processes that remain effective even after the initial audit.

Getting started does not have to be expensive. In the podcast, Merli recommended bringing together the three or four key people in the company for two to three hours to run through a scenario: What could happen to us? What consequences would an attack have for our products, facilities and machinery? Repeated once a year, for the company and for each product, this provides a solid foundation for everything the CRA requires.