Security Easier Than You Think?

Security has been a major topic in the mechanical engineering industry for some time now, particularly with the Machinery Regulation coming into effect on January 20, 2027. Many companies are uncertain about what lies ahead, expecting complex requirements for OT network communication and significant implementation costs. However, the mechanical engineering sector cannot afford excessive costs if it wants to remain competitive. René Heidl from Indu-Sol is surprised by the level of concern surrounding the topic. In his view, there is not much “new under the sun.” Instead, he believes the industry can build on the extensive experience and expertise it has already developed over the years. When examined more closely and from the right perspective, many of the required solutions are both straightforward and cost-effective.

What is the actual objective of the security measures required by the Machinery Regulation, the Cyber Resilience Act, or NIS2? Many people immediately think of protection against Russian cyberattacks or similar scenarios – highly skilled attackers with strong malicious intent. This perception often creates fear, and fear tends to lead to paralysis rather than constructive action. However, a closer look at the Machinery Regulation reveals that these concerns are generally unfounded for most machine builders.

Breaking Out of the “Rabbit-in-the-Headlights” Effect

Security itself is not a new topic. The mechanical engineering industry has experienced similar developments before in relation to electrical safety and functional safety in industrial systems. Before legal requirements existed in these areas, electrical safety and safety concepts were rarely considered during machine and plant design. The result was equipment damage, injuries, and in some cases even fatalities. These incidents led not only to compensation claims, but also to stronger safety requirements. Insurance companies, naturally reluctant to pay out large claims, became one of the driving forces behind improved safety standards. Over time, directives, laws, and regulations established a recognized state of the art that machine builders were required to follow. Today, risk assessments related to electrical safety or functional safety are standard practice for machine builders. Concepts such as Performance Levels (PL a–e) and Safety Integrity Levels (SIL 1–4) are well established throughout the industry. Beginning in January 2027, security levels will need to be approached in a very similar way. Up to now, inadequate security measures rarely resulted in direct legal or financial consequences for machine builders, as insurance providers typically covered the damages. With the Machinery Regulation coming into force, this changes. Insurance companies will only continue to cover damages if the machine builder can demonstrate that their security measures were not implemented with gross negligence. The good news is that achieving this level of compliance is far easier than many companies expect.

Understanding Security Levels

Security also begins with a risk assessment – specifically according to IEC 62443. This assessment determines a Target Security Level (SL-T), meaning the minimum level of protection required for the system. Similar to SIL classifications, manufacturers define a Security Level Capability (SL-C) for their components, indicating the level of security a component itself is capable of achieving. IEC 62443 then proposes seven foundational measures that can be used to achieve the required security levels (Figure 1).

Figure 1: Seven measures defined by IEC 62443 that can be used to achieve the required security levels. (Source: Indu-Sol)

However, the component alone is not expected to “solve” security. It is part of an overall system design – referred to as the Achieved Security Level (SL-A) – which also contributes to the overall security of the application. In short: the achieved security level must cover the required target security level. The component plays an important role, but it is only one part of the bigger picture. René Heidl (Figure 2) raises an important point: “But what if the required security level is significantly lower than many people assume? The scenario described earlier involving Russian hackers would correspond to SL4. Most industrial applications, however, require no more than SL2 – and in some cases SL3, as shown in the SL chart in Figure 3.”

Figure 3: Overview of the security levels and corresponding attacker profiles. (Source: AI-generated image – ChatGPT, 2026)

Let us take a closer look at SL2 through a practical example. SL2 focuses on “protection against intentional misuse” and assumes the following attacker profile: attackers with simple means, limited resources, general skills, and low motivation. “What reason would an attacker have to go through the effort of extracting the temperature of a boiler from a PLC protocol?” asks Heidl – before answering his own question: “Perhaps to manipulate the temperature and destroy a production batch? But what would the attacker gain from that? Aside from that, this would not be achievable using simple means. The attacker would need to configure a mirror port on a switch and then use tools such as Wireshark to intercept and manipulate network traffic. That is not something that can be done with limited resources, basic skills, and simple tools. On the other hand, anyone who actually possesses those capabilities would have no interest in carrying out such an attack because there is little to gain.” Against this backdrop, most industrial systems are simply not attractive targets for external hackers. The situation is different when valuable recipes, personal data, or similarly sensitive information can be stolen. However, this only affects a very small portion of industrial facilities.

The Worst-Case SL2 Attacker

In reality, defending against external attacks is primarily the responsibility of whoever provides the remote access solution – not the internal machine network communication itself. In approximately 95% of cases today, external connectivity ends at the PLC without a direct connection into the machine network. This makes it far more interesting to examine the worst-case SL2 attacker scenario. According to Heidl, that attacker typically comes from inside the company, not from outside. “Imagine an employee who believes they were unfairly dismissed and is now frustrated,” Heidl explains. “It would be very easy for that person to connect to the machine network using the USB port of a smartphone or a laptop and – unintentionally, because we are still talking about SL2 with ‘general means and capabilities’ – introduce something like a Windows worm that disables the visualization PC.”

Figure 4: PROmesh Switches (Source: Indu-Sol)

Unlike office IT environments, physically restricting access to the OT network is often nearly impossible. Switches are installed inside control cabinets that can typically be opened with standard cabinet keys (Figure 4), while many PROFINET devices throughout the machine or production line still provide open ports at the end of network segments. Heidl adds: “This example clearly shows how little sense it makes to distinguish strictly between trusted and untrusted zones. What really matters is detecting internal interference within the network and responding to it quickly.”

Problem Identified – Problem Solved?

These findings lead to a two-part solution. First, machine builders must be able to credibly demonstrate that they have performed a security risk assessment for their OT network communication and that the assessment concludes, for example, that Security Level 2 is sufficient for the specific application. “This is not rocket science,” says Heidl. “Still, we are happy to support our customers in preparing the required documentation.” Second, the necessary protective measures must be implemented. In the scenario described above, this means solutions capable of detecting unauthorized devices or suspicious activity quickly enough to prevent damage – or at the very least to identify responsibility in the event of an incident. “And that is easier than many people think,” Heidl explains. “It is actually very easy to define which devices belong to a network and which devices are newly connected. Every managed switch already maintains an overview of all MAC addresses within the network. However, our switches are currently the only ones on the market capable of generating an alert when a new MAC address appears on the network. Of course, this can also be monitored using our PROmanage software or the PROFINET-INspektor, along with many additional diagnostic details. But in most applications, a PROmesh diagnostic switch is already the most efficient and cost-effective solution (Figure 5). Strictly speaking, there are no additional costs involved because a switch is already required for network communication anyway.”

Figure 5: The PROmesh diagnostic switch is currently the only managed OT switch on the market capable of generating an alert when a new MAC address appears within the network. (Source: Indu-Sol)

Making Security Simple Again

One of the biggest concerns surrounding the Machinery Regulation is the assumption that implementing security measures will increase machine costs by five-digit amounts. In reality, this is usually not the case, since the vast majority of machine-building applications do not process personal data or highly valuable information such as proprietary recipes. Heidl summarizes the situation as follows: “It makes little sense to secure a pair of work overalls with both suspenders and a belt. What matters now is that machine builders finally move forward and develop practical solutions. We are happy to advise customers on which approach makes sense in each individual case – or, if desired, even carry out the complete risk assessment ourselves.”

• Back to the overview

Authors

Nora Crocoll, Dipl.-Ing. (FH), Editorial Office Stutensee

Alex Homburg, Dipl.-Wirt.-Ing. Editorial Office Stutensee