Regulations and standards

The NIS2 Directive 2022/2555/EU (NIS2) is an EU directive aimed at strengthening the cybersecurity of organizations. Although NIS2 has already been adopted as a directive by the Europe Parliament and the Council of the European Union, it will not come into force in the member states until it has been transposed into national law. Through this directive, the EU is requiring certain public and private institutions to strengthen their resilience to cyber attacks by consciously managing cyber risks – including those present in the supply chain.

The international standard ISO/IEC 27001 provides an established basis for introducing and implementing cybersecurity management processes of this kind. It describes the structure of an information security management system (ISMS), which companies can use to organize, manage and continuously develop their information security with a methodical approach.

Implementation schedule

The NIS2 Directive was originally intended to be transposed into national law with a view to taking effect in all member states by October 2024. In Germany, however, the NIS2 Implementation Act (NIS2UmsuCG) did not come into force until December 2025.

Activities at Beckhoff

The Beckhoff headquarters in Verl are also obliged to meet the requirements of the NIS2 directive. The company has already registered on the portal set up for reporting incidents. Beckhoff is also in the process of implementing measures designed to strengthen information security: in particular, these include introducing and certifying an information security management system (ISMS) in accordance with ISO/IEC 27001, scheduled for completion in 2026.

Other regulations and standards in focus:

• Machinery Regulation
• Cyber Resilience Act (CRA)
• International standard IEC 62443

The Machinery Regulation 2023/1230/EU is an EU regulation that relates to machinery and components, and has been adopted by the European Parliament and the Council of the European Union. This means that it has legal effect in all member states without having to be translated into national law. The EU is replacing the successful Machinery Directive with the Machinery Regulation. Both the Machinery Directive and the Machinery Regulation define requirements for the properties and development of machinery with functional safety. They also regulate relevant components with functional safety features. The process of replacing the Machinery Directive with the Machinery Regulation has created more requirements for providing protection against cyber attacks.

Implementation schedule

The new Machinery Regulation will come into effect on January 14, 2027, which means that all machines and components placed on the market from this date must meet its requirements.

Activities at Beckhoff

Beckhoff will ensure the suitability of its functional safety products through additional certifications in accordance with IEC 62443. Specifically, the development process for functional safety products will be certified in accordance with Part 4-1 of IEC 62443 (IEC 62443-4-1) in addition to the standards already in use. Products will receive a certificate in accordance with the requirements of Part 4-2 of IEC 62443 (IEC 62443 4-2) that apply to functional safety. These measures will be completed in good time ahead of the Machinery Regulation coming into force.

Other regulations and standards in focus:

• NIS2 Directive (NIS2) and ISO 27001
• Cyber Resilience Act (CRA)
• International standard IEC 62443

The regulatory landscape had another regulation introduced to it in December 2024: Regulation 2024/2847/EU on cyber resilience – better known as the Cyber Resilience Act or CRA for short. The CRA contains requirements for product design, development and warranties. It intends for organizations to introduce vulnerability management for the entire product life cycle, sets out strict reporting obligations in the event of cyber incidents, and imposes severe penalties for any breaches.

What the CRA regulates

The Cyber Resilience Act defines requirements for the cybersecurity of products. The aim is for products to be developed from the outset in a way that minimizes cybersecurity risks and keeps products safe from potential threats (secure by design/secure by default). In addition, the CRA considers the next stages in the life cycle and sets requirements for these as well. For example, any vulnerabilities that could be exploited in products must also be identified and actively remedied after delivery to the customer by providing vulnerability fixes. There is no obligation to apply or install the vulnerability fixes.

Why the CRA makes sense

According to Bitkom, a digital industry association in Germany, cyber threats caused damage amounting to €267 billion in 2024 – and that was just in the German economy. 81% of companies have knowingly been victims of cyber attacks, and a further 10% strongly suspect or are convinced that they have been. In times where digitalization is becoming pervasive, these figures are unlikely to improve.

While NIS2 has already set out requirements for strengthening the cybersecurity of organizations, the Cyber Resilience Act provides new standards for the cybersecurity of actual products, making it an important and useful tool in closing additional security gaps.

Products covered by the CRA

The CRA regulates products with digital elements (PDEs) that are placed on the market in the Europe Economic Area (EEA). This includes all products whose intended purpose or reasonably foreseeable use includes a direct or indirect logical or physical data connection to another device or network (CRA, Article 2).

The scope of the CRA is very broad, which means that it is likely to cover millions of products – from stand-alone software tools and hardware alone to combinations of hardware and software. There are exceptions: products with digital elements that are already subject to comprehensive EU regulations (in the medical technology and automotive sectors, for example) are not covered by the CRA. Products that are relevant to functional safety fall under both the CRA and the Machinery Regulation, which means that there is some overlap in their requirements.

Product classes and compliance certificates

In general, the CRA distinguishes between four product categories:

• simple products that do not have a designation under the CRA and are therefore generally referred to as default products
• important Class I products
• important Class II products
• critical products

These product categories form a hierarchy in the order listed here. This means that any requirements that apply to one of the categories mentioned before also apply to any subsequent categories, resulting in a set of requirements that increases from category to category and becomes more demanding overall.

Products are categorized according to clear criteria, which are described in the CRA and the associated Implementing Regulation 2025/2392/EU. It is important to note that only the main function of a product determines how it is categorized. This can be illustrated using the example of a robot vacuum cleaner. A device of this kind is usually equipped with an operating system, but this technical feature does not define the main function of the product – which is vacuuming. As a result, it falls into the category of “simple products”, even though its operating system is a technical feature that is characteristic of Class I products.

Conformity with the CE marking and the associated EU Declaration of Conformity is specified for all products. All products placed on the EEA market from December 11, 2027 must demonstrate conformity, however, products that have already been placed on the market before this date can remain on the market. For example, products placed on the market before December 11, 2027 can continue to move through distribution channels, but new products of the same type placed on the market after December 11, 2027 must demonstrate conformity with the CRA in order to do this. The CRA has not resulted in any additional CE marking requirements. Only the associated EU Declaration of Conformity will indicate whether a product has satisfied conformity requirements. There is one exception to this, however, in that the CRA is requiring CE marking for software for the first time.

Manufacturers can declare conformity for default products and important Class I products themselves. External notified bodies are only required to assess important Class II products and above. For important Class I products and above, the products must conform to a relevant cybersecurity standard.

Good to know: The Beckhoff portfolio only contains a few products that belong to the “important” category (also true of the automation sector in general). Products in the “critical” category are virtually non-existent in the automation sector and cannot be found in the Beckhoff portfolio.

Who must ensure conformity with the CRA requirements

It is the distributors who are responsible for this. Distributors refer to all companies (manufacturers, importers, and resellers) that manufacture or offer products with digital elements in the EEA.

What companies have to do in concrete terms

Achieving conformity with the CRA requires more than just using components that demonstrate conformity in a product such as a machine. What’s more, a product can still achieve conformity with the CRA even if it has components that do not demonstrate conformity installed in it. The most important consideration is minimizing the overall cybersecurity risk. This means that every manufacturer or distributoris responsible for its own specific product and must guarantee the following for it:

1. Implementation of the CRA requirements based on an individual risk assessment (design, development, provision and warranty)

2. Successfully completed conformity assessment procedure

3. Established vulnerability management (after commissioning, during the support period, and beyond)

4. Fulfillment of reporting obligations (to authorities and customers) – throughout the entire product life cycle

When the CRA came into force

The Cyber Resilience Act came into force back in November 2024 and has applied in all EU member states since then. While EU directives such as the NIS2 Directive first need to be transposed into the national law of the EU member states in order to take effect, regulations such as the Cyber Resilience Act come into force immediately after adoption by the European Parliament and the Council of the European Union. In other words, they do not need to be transposed into national law. In the case of the CRA, however, the requirements are being introduced gradually.

The next milestones:

• The official conformity assessment bodies will begin their work on June 11, 2026.
• The reporting obligation for actively exploited vulnerabilities and relevant incidents will apply from September 11, 2026.
• From December 11, 2027, all requirements of the CRA will apply in full. Only products that demonstrate conformity may be placed on the market from this date.

Why you gain a technical advantage with Beckhoff

The architectural benefits of PC-based control also extend to the CRA. This is because, unlike conventional devices developed for Programmable Logic Control (PLCs), PC-based control systems benefit directly from extensions and updates to the underlying operating systems. These extensions and updates also provide the latest cybersecurity technology.

Another cornerstone of CRA compliance is EtherCAT. The real-time fieldbus from Beckhoff does not use the Internet Protocol (IP), which makes it almost impossible to attack (since practically all malware uses IP-based communication). EtherCAT is isolated as a fieldbus and is considered a separate zone in accordance with IEC 62433 (i.e., is secure by design), which means that it has always inherently met the requirements of the CRA.

How Beckhoff has been fulfilling key CRA requirements for a long time

For more than ten years, Beckhoff as an organization has already been impressing its customers with internal processes and service offerings that are now becoming standard in the CRA era. The advantage of our approach is that we have already established these processes and refined them over the years – and this in turn brings benefits for ensuring that our customers and users demonstrate conformity with the CRA.

It is primarily the own PSIRT (Product Security Incident Response Team) of Beckhoff that ensures this. We are also a founding member of CERT@VDE, the first Germany-wide IT security platform for companies in the automation industry. Additionally, Beckhoff introduced specific actions on vulnerability management and user information some time ago by starting to publish regularly updated security advisories. Recently, these have even included documentation in the machine-readable CSAF format. As a result, harmonizing these measures with the requirements of the CRA is just a small step away. This is a path that Beckhoff is consistently pursuing, and it has already started to deliver products that demonstrate CRA conformity. The changeover will be fully completed by 2027.

Other regulations and standards in focus:

• NIS2 Directive (NIS2) and ISO 27001
• Machinery Regulation
• International standard IEC 62443

The international standard IEC 62443 outlines the cybersecurity requirements for the automation industry. It consists of several parts under the title “Security for industrial automation and control systems”, with each part dedicated to a general explanation, a process, or a set of technical requirements. The parts are divided into levels according to whether they are to be applied generally (level 1), explain procedures (level 2), are intended for systems (level 3), or are to be used for components (level 4). There are also additional levels explaining profiles for product categories, for example.

To identify the individual parts, the number of the level and an additional number are appended to the standard number: for example, IEC 62443-4-2 designates Part 4-2 of IEC 62443.

Relevant for technical implementation

The following parts are particularly important to the technical implementation of IEC 62443:

Part 2-4, titled “Security program requirements for IACS service providers” (IACS stands for Industrial Automation and Control System), explains which requirements for a cybersecurity program must be met by a machine or system building company in order for it to offer cybersecure operation and cybersecure services to operators. For example, Part 2-4 requires comprehensive documentation so that operators receive cybersecurity information about the machine or system and can do their part to ensure cybersecure operation.

Part 3-2, titled “Security risk assessment for system design”, outlines an example of a procedure involved in risk-based design of systems and machines or risk assessments of existing systems. It is intended to ensure an appropriate depth of threat analysis, risk assessment, and measures derived from these, allowing operators’ cybersecurity needs to be met.

Part 3-3, titled “System security requirements and security levels”, explains common technical cybersecurity requirements for a system. It is possible to choose individual requirements to focus on – ideally based on a prior risk assessment – if a justification for doing so can be provided.

Part 4-1, titled “Secure product development lifecycle requirements”, explains requirements for the development, manufacture, support and servicing of components. The aim is to create cybersecure components and ensure cybersecurity is maintained throughout their life cycle. Some notified bodies believe that Part 4-1 should be applied to not only components, but also systems, because the system is a product and, therefore, a component from the operator’s perspective.

Part 4-2, titled “Technical security requirements for IACS components” (IACS stands for “Industrial Automation and Control System”) explains common technical cybersecurity requirements for automation technology components. These technical requirements are generally not met all at once, but selectively by specific properties of the component. The choice of properties depends on the component’s contribution to the system. System builders and operators make this choice based on the risk assessment, ensuring that the required cybersecurity properties of the system are guaranteed.

Understanding cybersecurity as a process

As the explanations of the individual parts of IEC 62443 show, the standard follows a risk-based approach that starts from the needs of the operator and selectively breaks down requirements for the system and its components. It is also clear that cybersecurity is not just a matter of meeting technical requirements, but also requires life cycle processes and service programs. This is because potential risks change over time. Cybersecurity is not a state that can be achieved all at once: instead, it must be understood and implemented as a process. It would therefore be contrary to the purpose of IEC 62443 if a component were required to meet the technical requirements of Part 4-2 across the board without a risk assessment having been carried out at system level, or the system manufacturer and operator having agreed on a security program. Even if a component can fulfill all the relevant requirements of Part 4-2, the associated technical properties must be taken into account in the design of the system, and must be configured, activated and maintained with the system. Just because a component has the required cybersecurity properties does not automatically make the entire system cybersecure. Cybersecurity properties that are applied unnecessarily or are required simply for the sake of it have the potential to be a competitive disadvantage (a principle that also applies outside the discipline of cybersecurity), especially because cybersecurity properties usually introduce a degree of complexity that becomes apparent during installation and maintenance.

How do IEC 62443 and the Cyber Resilience Act (CRA) fit together?

The IEC 62443 standard is internationally recognized and has been maintained for decades. This work is carried out by the consortium of national committees in the International Electronic Commission (IEC). Many market players in the automation industry regard the IEC 62443 standard as the key critical standard for cybersecurity. However, the advent of Regulation 2024/2847/EU on cyber resilience – better known as the Cyber Resilience Act (CRA) – has caused a new situation to arise. IEC 62443 was previously considered to be all-encompassing in its scope, but the CRA contains some requirements that do not appear in IEC 62443. Conversely, the CRA does not take into account all aspects of IEC 62443. This means that there is some overlap between IEC 62443 and the CRA, but each also defines independent requirements for processes and technical implementations. In addition, the requirements for technical implementations by the CRA are much more abstract than those in IEC 62443, because the IEC 62443 requirements are already tailored to the automation industry.

The evolution of IEC 62443 in Europe

A consortium of automation industry players has now taken on the work of expanding the next version of European standard EN IEC 62443 in order to factor in all the aspects of the CRA. The aim of this is to ensure that compliance with the standard is enough to declare compliance with the CRA. Without these extensions, additional standards would have to be used in order to fulfill the CRA requirements that are not covered by IEC 62443. For the first time in the history of IEC 62443, a European version has been created that is more comprehensive than the international version. The intention of the European consortium is to incorporate the extensions into the international version in the course of subsequent years. Beckhoff is demonstrating its commitment to define industrial-suited standards by actively participating in the development of EN IEC 62443.

As a comprehensive standard with strict requirements, IEC 62443 justifiably has a role to play in the automation industry. From an economic efficiency perspective, however, it does not make sense to implement the same scope of technical requirements for all automation technology components and systems. Many components from the lower levels of the automation pyramid are already naturally protected against attacks and do not require any additional protection. In fact, adding protective measures would have a negative impact as it would lead to additional overhead and make maintenance work more complicated. Ultimately, a sense of proportion is needed – when applying both IEC 62443 and EN IEC 62443.

Other regulations and standards in focus:

• NIS2 Directive (NIS2) and ISO 27001
• Machinery Regulation
• Cyber Resilience Act (CRA)