Connected machines, digital services, and software-based safety components have made production more flexible. However, they have also created a new form of vulnerability. Whereas in the past, a safety guard, a safety switch, or a control system largely operated in isolation, today there are connections: to networks, maintenance systems, cloud applications, or other machines.
The Cyber Resilience Act, or CRA for short, takes this development into account. It makes cybersecurity for products with digital elements a requirement that must be met not only at the time of market launch. Manufacturers are expected to monitor their products throughout their entire lifecycle, assess vulnerabilities, and respond appropriately.
What initially sounds like yet another task for IT has far-reaching implications for product development, design, documentation, and service. In an interview with PRODUKTION, Marc Wiederoder and Xabier Antolin from Euchner explain what this means for manufacturers, suppliers, and operators.
PRODUKTION: Mr. Antolin, Mr. Wiederoder, the Cyber Resilience Act is often perceived as a new IT security law. Is that the key misconception?
Xabier Antolin: Yes. Anyone who views the CRA as solely a matter for the IT department underestimates its scope. The regulation applies to products with digital elements and thus to their development, manufacturing, and maintenance. In mechanical engineering, therefore, it’s not just IT managers who are affected, but also design, product management, purchasing, quality management, documentation, and service.
This is an important shift in perspective. Cybersecurity is becoming a product characteristic. Companies must not only protect their own networks but also assess the risks a product may pose, how it is intended to be used, and the limits for safe operation.
What does this mean for safety components, which are increasingly networked or software-based?
Marc Wiederoder: First, manufacturers must describe the application context in great detail. They specify the intended areas of use for a product, the conditions under which it can be operated safely, and which applications must be excluded.
At first glance, this sounds like documentation. In reality, however, the work begins much earlier. Communication interfaces, firmware, update mechanisms, and the software libraries used must be evaluated from a cybersecurity perspective as early as the development phase. With safety-critical components, there is an additional concern: tampering can affect more than just data or availability. In the worst-case scenario, it can compromise a safety function.
So a security problem can directly result in a risk to people or equipment?
Marc Wiederoder: Exactly. Functional safety and cybersecurity have different starting points. Safety is intended to prevent dangerous machine states. Security is intended to protect systems from, among other things, unauthorized access, tampering, and misuse.
In a networked production environment, however, these two areas can no longer be clearly separated. If a safety-critical function is digitally compromised, a cyberattack can lead to a dangerous situation. That is why companies should pay particular attention in their cybersecurity assessments to functions that are critical to the safety of people, machines, and manufactured goods.
Does the CRA primarily affect manufacturers of complete machines?
Xabier Antolin: No, the entire supply chain is affected. A component manufacturer must assess which cybersecurity features its product requires and what information the machine builder needs for integration. The machine builder, in turn, must evaluate the individual components within the context of the overall system. And the operator is responsible for using products in their intended application context and following the manufacturer’s instructions.
This interplay is crucial. Cybersecurity cannot be delegated to a single participant in the supply chain. Requirements must be communicated, operating conditions understood, and changes made transparent.
Are all digital components evaluated according to the same standards?
Xabier Antolin: No. A product’s function and risk profile play a key role. A device that controls access between different security zones serves a different protective function than a simple sensor. Accordingly, the requirements and assessment criteria also differ.
Manufacturers must therefore analyze where a product is used, how heavily it is networked, and what consequences a successful attack could have. This leads to a trade-off: restrictions can reduce the attack surface but must not unnecessarily complicate industrial use. Security and usability must be considered together.
Can’t manufacturers simply meet many of these requirements by adding additional notes to the operating instructions?
Marc Wiederoder: In some cases, only the documentation will need to be updated. However, that alone is often not enough. Depending on the product, changes to hardware, firmware, interfaces, or update mechanisms may be necessary. Cybersecurity cannot be retrofitted to a finished product—or can only be done so with great effort. If fundamental requirements are not considered until shortly before market launch, making changes can become very costly. That is why security-by-design is so important: threats, potential attack vectors, and protective measures must be taken into account as early as the concept and development phases.
How early should OEMs start?
Marc Wiederoder: As early as possible. The earlier cybersecurity requirements are incorporated into the development process, the easier it will be to adapt a product later on to new findings or changing threat landscapes. This not only saves resources; it also prevents the need to retroactively correct fundamental architectural decisions.
A secure development process in accordance with IEC 62443-4-1 can provide a robust framework for this. It supplements existing functional safety processes with systematic cybersecurity activities—from requirements analysis through implementation to addressing discovered vulnerabilities.
In traditional product development, a product is considered complete upon series production approval. Does that still apply under the CRA?
Marc Wiederoder: From a cybersecurity perspective, market launch is not the end of development, but rather the beginning of a new phase. New attack methods, vulnerabilities in software components used, or changed usage scenarios can call an earlier risk assessment into question. As long as a product is in its active lifecycle, relevant developments must be monitored and evaluated. Cybersecurity does not end with product release. Companies therefore need procedures that allow them to regularly review their products and respond to new vulnerabilities or requirements.
What constitutes robust vulnerability management?
Xabier Antolin: First and foremost, clear reporting channels are needed. Customers, security researchers, or partners need to know who to contact if they discover a potential vulnerability. Internally, there must be established procedures for how a report is reviewed, assessed, and forwarded to the appropriate departments. A Product Security Incident Response Team (PSIRT) can play a central role in this process. Such a team consolidates information, coordinates the technical assessment, and manages communication. This is primarily an organizational task. Without defined responsibilities, even good technical tools are of limited help.
How important is technical documentation throughout the product lifecycle?
Xabier Antolin: It’s becoming more dynamic. With new software or firmware versions, operators must be able to verify what changes have been made, what prerequisites apply, and whether the intended application context has changed. An update can close a vulnerability, but at the same time introduce new requirements for configuration or compatibility. That’s why documentation must not be viewed as a one-time accompanying document. It is an integral part of secure operation and must be consistently taken into account with new versions.
Does this mean that all existing systems must now be reevaluated?
Marc Wiederoder: Not automatically. Existing systems are not affected simply because the CRA comes into effect. However, a reassessment may become necessary if a significant change is made.
Companies should therefore carefully consider what happens during a modernization. New networking, the replacement of key components, or a changed software architecture can significantly alter the original application context. What matters is not just the age of a machine, but whether its risk profile fundamentally shifts.
Many companies have already established structures for NIS2. Does this also largely cover the CRA?
Xabier Antolin: NIS2 structures can serve as a solid organizational foundation. Companies have often already defined responsibilities, established reporting channels, and established information security as a management priority. However, the CRA additionally requires a thorough examination of the product itself. General information security is no substitute for security-by-design, the assessment of product components, or vulnerability management throughout the product lifecycle. Both sets of regulations overlap, but they have different priorities.
How can we prevent the additional complexity from falling entirely on the machine operator?
Marc Wiederoder: Manufacturers must translate requirements in a way that makes them understandable and implementable in industrial practice. This includes clear configuration guidelines, transparent operational limits, and concrete application examples.
The topic remains complex. However, it is of little help if companies merely pass on abstract standards or regulatory texts. Publications, workshops, and practical applications can help illustrate the implications for specific machines and systems. Equally important are points of contact who can support operators with security assessments.
What should machine builders and manufacturing companies do first?
Xabier Antolin: First, the CRA must become visible within the company. Executive management, R&D, product management, IT, procurement, service, and quality management need a shared understanding of what is changing.
Next, responsible parties should be designated to track regulatory developments and coordinate internal matters. An assessment is equally necessary: Which products contain digital elements? Which libraries, interfaces, and communication protocols are used? Which components perform safety-critical functions? And how are vulnerabilities currently identified, assessed, and communicated?
Marc Wiederoder: Companies should also engage with suppliers and customers early on. What information will be needed in the future? What update and support periods are promised? How can vulnerability reports be shared along the supply chain? Such processes do not emerge within a few weeks. Those who wait until customers demand concrete evidence will quickly find themselves under considerable time pressure.
What measures did Euchner implement after preparing for these requirements? How does the customer benefit?
Marc Wiederoder: We established an internal process for cybersecurity risk management early on and implemented a Secure Development Lifecycle. This includes a certified development process in accordance with IEC 62443-4-1.
In addition, a PSIRT was set up. The product portfolio is continuously reviewed for potential vulnerabilities and CRA-relevant requirements. An automated process helps systematically monitor components in use and newly discovered vulnerabilities.
Xabier Antolin: Equally important is the exchange of information across company boundaries. Participation in security initiatives, CERT structures, and vulnerability databases helps ensure that new findings are addressed early on. No manufacturer can solve industrial cybersecurity in isolation. It is crucial that information is reliably exchanged and translated into concrete measures. The CRA makes this collaboration more binding—and compels companies not only to promise security at the time of delivery but to organize it over the course of many years.
In the future, Euchner will also offer consulting services on cybersecurity requirements in the industrial sector. These include threat and risk analyses, the identification of security vulnerabilities, and support for security-by-design, compliance issues, vulnerability management, and security updates—with the goal of classifying requirements early on and integrating necessary measures into development and operational processes in a planned manner.
The Cyber Resilience Act already entered into force on December 10, 2024. However, the obligations will take effect gradually:
- As of June 11, 2026, the regulations governing the designation and operations of conformity assessment bodies will apply.
- Starting September 11, 2026, manufacturers must report actively exploited vulnerabilities and serious security incidents.
- As of December 11, 2027, the CRA will generally be fully in effect. Products with digital elements that are newly made available on the EU market at that time must comply with the requirements.
Which products are affected? The CRA generally covers hardware and software whose intended or reasonably foreseeable use involves a direct or indirect connection to a device or network. In an industrial setting, this may include, among other things, control systems, networked sensors, communication components, firmware, industrial software, and software-based safety components. Exceptions apply to certain areas—such as medical devices, which are already regulated on a sector-specific basis.
Who is responsible for implementing the requirements? The primary responsibility lies with the manufacturer. A company that commissions the development of a product and places it on the market under its own name or brand is also considered a manufacturer. Manufacturers must, among other things, assess cyber risks, incorporate security-by-design, prepare technical documentation, address vulnerabilities during the support period, and demonstrate the product’s conformity.
Importers and distributors also have verification obligations. For example, they must ensure that the required conformity assessment has been conducted and that the prescribed documentation and markings are present. Machine operators are not considered manufacturers under the CRA simply by using a product. However, anyone who substantially modifies a product and makes it available on the market again may assume the obligations of a manufacturer.
Who verifies compliance? First, the manufacturer must demonstrate the conformity of its product. For most standard products, an internal assessment is possible. Stricter procedures apply to so-called important and critical products; depending on the product class and applicable standards, an independent, notified testing body may be required. After a successful assessment, the manufacturer issues the EU Declaration of Conformity and affixes the CE marking.
Government oversight is carried out by the national market surveillance authorities. In Germany, the federal government has designated the Federal Office for Information Security (BSI) as the market surveillance and notifying authority. The BSI can inspect products and technical documentation and, in the event of violations, initiate corrective measures, including sales restrictions or a recall . The national legal framework is established through the German Implementation Act for the CRA.
What does this mean for existing systems? Existing machines and systems do not need to be completely reevaluated solely because of the CRA. However, the regulation may become relevant if a product or system is significantly modified and subsequently placed back on the market. Companies should therefore document whether new network connections, software changes, or the replacement of key components alter the original context of use and the risk profile.
The interview was conducted by the editorial staff of *Produktion* and edited for publication on the EUCHNER website.
