Cyber Resilience Act: Why companies must invest

In mechanical and plant engineering, almost all companies have to deal with the CRA: From December 11, 2027, only products that can be proven to be secure may be placed on the market in the EU. The Cyber Resilience Act requires that security must be embedded in the product itself (secure by design). This includes secure software architecture, effective handling of vulnerabilities, and the ability to provide updates. 

“Industrial production without digitalization is no longer possible if you want to remain competitive. In the digital factory, a very large number of components are therefore affected by the CRA,” says Dr. Christine Payer, attorney at the Dürr Group, head of the working group on legal framework conditions at the Industrie 4.0 platform of the BMWK, and chair of the VDMA working group digitaLegis.

From the perspective of Jens Köhler, chief expert for cybersecurity at the engineering service provider ITK Engineering GmbH, the respective challenges for CRA compliance are very different. On the one hand, smaller companies that only have a few employees for software are often overwhelmed by the additional topic of cybersecurity. 

On the other hand, larger companies do have more specialists, but they also have an extensive product portfolio with many legacy products and a high variety of variants that have to be brought into line. “I assume that in some cases companies will discontinue legacy products and instead develop new versions directly,” says the ITK expert.

SMEs risk falling behind

CRA, NIS2, the Machinery Regulation, the AI Act, and then last fall the go-live of the EU Data Act: “It is a jumble of new laws that now have to be implemented in a short time. That is a very big challenge, and I wonder how small and medium-sized companies are actually supposed to cope with it,” says Christine Payer, drawing on her practical experience in industry associations.

At embedded systems manufacturer Kontron in Linz, the company has already been working intensively for some time on product security and secure-by-design concepts. Stefan Eberhardt, senior business developer IoT software and CRA expert at Kontron, knows from his own experience how much effort is involved in complying with the CRA requirements. He fears that SMEs in mechanical and plant engineering in particular have not yet fully grasped the implications. “Compliance pressure is increasing especially for medium-sized machine builders whose products are integrated into larger production systems,” says Eberhardt. Until now, a self-declaration was often sufficient for CE conformity. “Depending on the class in which a product is listed, acceptance must now be carried out by a testing organization. That means an immense additional effort,” explains the Kontron expert.

Industry lagging behind on cybersecurity standards

Industry is preparing for the end of the transition period of the EU Cyber Resilience Act (CRA) in 2026/27, but still needs to pick up speed in meeting the associated technical standards.

Stumbling block: The harmonized standards are not finished

The CRA divides products into different security classes. For the default class, a self-declaration is sufficient for CE marking; from class 1 onward, a conformity assessment body must be involved. In principle, for class 1, proof of conformity with a harmonized standard should also be sufficient instead of a test. However, the standards for this are currently not yet finished. Work is being carried out on them at full speed, but many of the vertical standards are planned for the end of 2026, and most of the horizontal standards by the end of 2027.

The fact that there is still no harmonized standard for the CRA is, in Christine Payer’s view, one of the biggest challenges: Waiting for it is not an option for Dürr. The automation company Pilz takes the same view. In some cases, there is still uncertainty about how to classify whether a product still falls into the default class, says Hartmut Paulus, senior manager network systems at Pilz: “In some cases, we seek dialogue with other companies and try to develop a common view. The industry associations are also working on the topic.”

“The CRA states that we as manufacturers are responsible and liable for the end product. For us, this means that we are currently working flat out to ensure that our supply chains meet the requirements of the CRA,” says Payer. At Dürr, too, given the large product portfolio, which includes paint shops, woodworking and balancing machines as well as automation solutions, the question arises for some products as to which class they ultimately fall under. Here, a look at the legislation does not always provide an immediate answer.

Cybersecurity: Painful, but urgently needed

Nevertheless, the cra is being well received and is seen as the right signal from the european legislator to ensure the urgently needed strengthening of cybersecurity, says christine payer. Current calls for tenders already require cra compliance, and there are specific questions about what reporting structures and incident management will look like.

“According to an analysis by enisa, at least 90 percent of products in mechanical and plant engineering fall into the default category,” reports matthias springer, senior vice president functional safety & security at the tüv nord group. For around ten percent, a testing organization has to be brought in. Nevertheless, cra proof must be available for all products, including those in the default category. This is checked by the bsi and the federal network agency. “In the event of damage or an audit, it is highly problematic if companies do not have cra proof ready. Fines can already be imposed in the default class,” says springer. In the case of serious violations, fines can reach 15 million euros or 2.5 years’ revenue; for breaches of reporting obligations, similarly high fines, product recalls, and sales bans may be imposed.

Testing organizations prepare for a rush

TÜV is already seeing strong demand: “Many companies want to obtain accreditation in order to demonstrate the trust aspect of their products – not least for marketing reasons. In all likelihood, not all of them will actually need it,” says Springer. At the moment, they are mainly working with the major players in the industry. Many larger mid-sized companies are also dealing with it. The smaller ones either don’t have it on their radar yet or are often overwhelmed by it, in Springer’s view as well.

TÜV is currently adapting its processes and testing programs in order to be able to reflect the CRA. The testing organization will apply to be designated as a notified body for the CRA by the deadline of June 11. All testing bodies are to be confirmed by December 11: a very tight schedule, because after that there will only be one year left for product accreditation. “That’s why we are already starting on a broad front to work with companies on CRA compliance, based on the standards intended for harmonization, and can later formally convert the test report into a certificate,” explains the TÜV expert. His appeal: “Any manufacturer that wants to be finished by December 2027 must start now at the latest. After that, you will no longer be allowed to place the product on the market if the CRA is not fulfilled.”

CRA implementation: Personnel resources and organizational change

“From an organizational point of view, implementing the CRA is a huge undertaking that requires many resources. For topics such as development, vulnerability management, and software updates, you need at least a small cyber team,” notes Springer. Essentially, the existing quality management system must be completely expanded to cover all aspects of the CRA. “We already followed the CRA during its drafting and decided two years ago to launch a major, central, cross-departmental transformation project, because the requirements affect a great many areas of the company,” reports Paulus. 

There are many overlaps with the new EU Machinery Regulation, which will apply from January 2027 and already includes industrial security requirements under the heading “protection against corruption.” A lot can be done “in one go,” so to speak. Pilz intends to make use of this for its own benefit. It also helps that many of the safety products already meet high regulatory requirements and that the secure development process has already been certified in accordance with EN IEC 62443.

EU regulation: Why industrial companies need to take a close look now

Cyber Resilience Act, AI Act, NIS2 and CBAM: Since early 2026, numerous new EU regulations for companies have taken effect. Some already apply, others will follow over the course of the year, and 2027 is also coming into the regulatory spotlight.

Manfred Godek

At Dürr, cybersecurity has also been treated as a group-wide topic for many years now, and processes have been aligned accordingly—for example, in line with IEC 62443—in order to offer customers reliable solutions. The CRA therefore mainly requires an addition, which should not be underestimated, says Payer. An expert team is responsible for implementing the CRA across the group as a knowledge transfer. In particular with regard to security by design for product security development processes and the legally required reporting channels, staff has been increased and a secure customer portal has been set up to provide updates.

Challenge: Lifetime updates

“The support period can no longer be chosen entirely freely by the manufacturer, but must in particular be based on users’ expectations. Security updates are certainly one of the bigger pain points here,” confirms Köhler. Most companies are still not capable of remote updates today; service technicians are often still sent into the field. “On top of that, industrial products in particular often have long service lives. For one of our customers, this meant, for example, that they must still be able to compile a security patch in 30 years’ time,” notes Köhler. He sees two approaches among customers: either keeping the so-called build chains for the software in the product alive for the entire period, or archiving them and reviving them in an emergency with a task force.

"One of the biggest challenges is above all the long-term maintenance of updates: The life cycles of software and machines are not very compatible," is how Hartmut Paulus describes it. Often a product is supposed to be operated for up to 20 years, during which new attack vectors on the software can continually emerge. As a result, it is necessary over very long periods in the maintenance phase to look after software modules that require significantly more effort than the initial software solution.

Hurdle of continuous vulnerability management

With the CRA, manufacturers are obliged to carry out continuous vulnerability monitoring. The software bill of materials plays a central role here. There are tools for matching the SBOM with vulnerability databases. “However, companies themselves must perform the assessment for the specific use case as to whether a vulnerability can actually be exploited and is critical,” says Jens Köhler.

Hartmut Paulus from Pilz sees difficulties regarding continuous updates for machine operators who have components from many different suppliers installed. A steel furnace or a baking line, for example, cannot simply be shut down for an update; operators therefore need smart mechanisms to decide for themselves whether a security vulnerability is actually critical for their product at all and whether the update is necessary. The basis for this is the vulnerability warnings that an increasing number of component suppliers are issuing due to their reporting obligations.

Putting software and product development on a new, secure footing

In the future, it will be a competitive factor that companies know precisely and can prove which software components are used in their product. Many companies still face a great deal of investigation and evaluation work to examine all components and verify whether legal requirements can be met, says Stefan Eberhardt: “Companies now also have to look more closely, for example in the open source environment, at which licenses and components affect a product – and keep appropriate documentation available.” 

Particularly challenging is a profound change that becomes necessary under the CRA: Wherever existing components have previously been cobbled together or quickly adapted to solve a problem or during the development process, rework will be required. Quick fixes or short-term new releases to solve problems are basically no longer possible, says Eberhardt.

“The software development process is fundamentally changing with the CRA requirements and is becoming significantly more formal. Considerably more documentation is required in advance, and at the same time a clear security concept with corresponding evidence must be in place from the very beginning,” explains the Kontron expert. In addition, unlike before, developers who sit at the extended workbench in other countries need defined interfaces. Testing also has to become more formal.” 

For some companies, this change may mean that their product portfolio will also change if ad hoc development for smaller product series is no longer possible in the usual form.

Keeping a cool head

For companies that are tackling the issue now, Jens Köhler recommends prioritizing risk analysis: “The CRA requires an appropriate level of cybersecurity, which can be determined with a product-specific risk analysis. It can be legitimate to accept non-critical risks without having to invest directly in countermeasures.” The risk analysis must take into account possible usage scenarios and target groups—for example, increased security requirements for critical infrastructure. For those who feel overwhelmed by the effort involved, the ITK expert offers reassurance: “Cybersecurity is not rocket science. In many cases, it is possible to arrive at very pragmatic solutions.”