New cybersecurity requirements are hitting industrial companies at an awkward point: machines, controllers and service interfaces are becoming more connected, while expectations for security, evidence and responsibility are rising. NIS2, the Cyber Resilience Act, the EU Machinery Regulation and IEC 62443 are not one neat switch. They are several layers that need to be understood together.
The key question is not: “How do we implement every standard at the highest possible level?” It is: which machines really need connectivity, what risk does that create and which security architecture is economically sensible? For some machines, strong network separation is the best answer. For others, Root of Trust, secure updates, certificates, controlled remote access and monitoring become necessary.
Why this matters for industry now
Many industrial environments have become connected gradually: for remote maintenance, production data, reporting, predictive maintenance or easier updates. That can create real value. It can also mean that controllers, old operating systems or service access points suddenly sit in a risk environment they were never designed for.
This is where the new rules and standards overlap. NIS2 addresses the security of network and information systems for essential and important entities. The Cyber Resilience Act focuses on products with digital elements. The EU Machinery Regulation brings product safety and digital risks closer together. IEC 62443 provides a technical framework for industrial automation and control systems.
That is complex, but it is not only a burden. Companies that design machine fleets, remote service and security evidence properly reduce outage risk, improve incident visibility and build trust with customers, partners and insurers.
The main frameworks at a glance
The following table is an orientation as of 23 June 2026. It is not legal advice, but it shows which topics companies in Austria, Germany, Switzerland and Liechtenstein should keep on their radar.
NIS2
Core question: operations, risk management, reporting and supervision. In the EU it requires national implementation; Austria states the EU deadline of 17 October 2024. NIS2 is not directly applicable in Switzerland, where the local reporting duty for critical infrastructure is more relevant.
IEC 62443
Core question: technical OT-security framework, zones, components and security levels. There is no general statutory date; it becomes important through customer requirements, contracts, tenders and state-of-the-art expectations.
Cyber Resilience Act
Core question: products with digital elements, vulnerabilities and secure product development. Most EU obligations apply from 11 December 2027; manufacturers outside the EU should care when selling into the EU/EEA market.
EU Machinery Regulation
Core question: machinery safety and digital risks. In the EU it is mainly applicable from 14 January 2027; outside the EU it matters especially for machines placed on the EU/EEA market or used in EU supply chains.
Sources
Sources for this orientation include the Austrian NIS contact point on NIS2, the EU legal texts for NIS2, the Cyber Resilience Act and the EU Machinery Regulation, the IEC pages for IEC 62443-3-3 and IEC 62443-4-2, and the Swiss information on the reporting obligation for cyberattacks on critical infrastructure.
In practice, not every company is affected by every framework in the same way. But machine builders, operators of critical or important services, suppliers and providers of connected products should already check which obligations apply directly and which expectations arrive through customers, insurers, tenders or supply chains.
How far does machinery security need to go?
The most expensive mistake is to plan for the maximum technical requirement before checking whether connectivity actually creates business value. IEC 62443 Security Level 3 or 4 can become demanding depending on the system and risk. At higher levels, it is often not enough to place a firewall in front of a machine or change a password.
If a machine needs a high security level because of safety, customer requirements or its operating context, hardware-level security may become necessary. This can include a TPM, secure fuses, a protected boot process or other mechanisms that make manipulation detectable and protect keys more effectively.
That technology costs money: hardware, development, testing, certification, operations and maintenance. So the honest question matters: does the machine really need this connectivity? Is there a clear business case for remote service, data analysis, continuous updates or predictive maintenance? Or was the connection added mainly because it was convenient?
If connectivity has no business case, separate it
If an older machine has no economically relevant reason to be connected to the internet or to a broad corporate network, separation is often the most pragmatic security measure. That may mean a true air gap, with no network connection, or very strict segmentation with clearly controlled transitions.
The cost is convenience. Technicians may need to install updates physically on site. Data may have to be collected locally or transferred through tightly controlled processes. Remote maintenance becomes harder or slower. In the end, this is a question of cost and practicality.
Still, it may be the economically sensible choice. Bringing an old controller up to a modern, permanently connected security level can cost more than the value created by the connection. In that case, “less connected” is not outdated; it is deliberate risk reduction.
If connectivity is needed, build it properly
Sometimes separation is not a real option. Machines need data from other systems, customers expect remote service, production planning depends on current status information or predictive maintenance reduces downtime. In those cases, security architecture should not be bolted on afterwards.
The first step is a risk-based assessment: which function must not fail? Which data is critical? Which communication is truly necessary? Which people, systems and service providers may access the machine? From there, you can define zones, transitions and requirements for updates, identities, logging and monitoring.
IEC 62443 is useful here because it looks beyond individual safeguards. It considers roles, zones, conduits between zones, system requirements and component requirements. The practical value appears when those concepts are translated into a concrete machinery and operations architecture.
Why everything starts with Root of Trust
A Root of Trust is the trusted starting point of a system. In simple terms, the machine needs somewhere to begin when it checks whether it can trust its own state, keys and software. If that starting point can be manipulated, every higher-level security function is built on unstable ground.
That is why this starting point ultimately has to be hardware-based. Software can provide strong protection, but if an attacker already controls the software environment underneath it, a purely software-based trust anchor can be manipulated too. Hardware can isolate keys, measure boot steps and make system state more verifiable.
A TPM is a typical example of such a building block. But it is important to be precise: a TPM is not a general-purpose cryptographic accelerator for every workload. It is more like a protected security anchor for keys, measurements and attestation. For high data rates or modern algorithms, the platform may also need sufficient CPU performance or a separate cryptographic accelerator.
What Root of Trust enables
Once the Root of Trust is planned properly, several important security functions can be built on top:
- Secure updates: The machine only installs software that is correctly signed and comes from a trusted process.
- Secure boot: During startup, firmware, bootloader and important software components are checked for integrity.
- Certificates and identities: Machines can receive unique, better-protected identities instead of relying on distributed passwords or shared keys.
- Controlled remote access: Remote access can be governed through certificates, roles, logging and time-limited approvals.
- Attestation: A system can provide evidence about the state it booted into or whether certain security measurements are plausible.
Longevity matters. Industrial assets often run for many years. The platform needs enough headroom for future cryptography, new certificate requirements and secure update processes. If the platform is designed too narrowly today, tomorrow’s security problem may be expensive or impossible to fix.
Monitoring makes security visible
Many companies invest in security measures but then have little visibility into whether the fleet is actually becoming safer. This is where security monitoring is valuable. It makes states, anomalies, failed logins, update problems and unusual communication visible.
For operators, monitoring helps detect company-wide issues earlier. For manufacturers, it can become an additional service: customers receive not only a machine, but more transparency about its security status. Traceable logs can also matter for insurers, experts or disputes after an incident.
Monitoring does not replace machine security. If an asset accepts unsafe updates, exposes unprotected access or operates without clear identities, monitoring can only help to a limited degree. It amplifies good architecture; it is not a substitute for it.
What industry can learn from automotive
Many companies look at the automotive industry because cybersecurity, secure updates, ECU identities and security engineering have been pushed into its development processes earlier and more forcefully. That is a useful reference point: vehicles show how important secure supply chains, hardware anchors, update processes and clear responsibilities can become.
Those experiences should not be copied blindly. A production machine, a medical device, a special-purpose machine and a vehicle have different risks, lifetimes and business models. Good orientation means using lessons learned while still taking your own risk assessment seriously.
My recommendation for getting started
Do not start with the most expensive security component. Start with a sober assessment of your machines and connections:
- Which machines are connected to which networks?
- Which connection creates real business value?
- Which assets can be separated or segmented more strongly?
- Where are secure updates, remote access or machine identities necessary?
- Which evidence and monitoring data do customers, operators or insurers need?
This is not only a theoretical topic for me. My Bachelor thesis dealt with this area, and my Master studies added hardware security, TPMs and related topics. That is exactly why I prefer to keep technical terms grounded: the right solution has to match the risk, the machine, the budget and the planned lifetime.
If you want to understand which requirements may affect your machines, products or asset fleet, Schiemer Software can support the assessment and technical planning. Write to info@schiemer-software.com. Together we can clarify whether network separation is enough, whether a modern security architecture is needed and which steps make economic sense.
Frequently asked questions
Is IEC 62443 legally mandatory?
Not automatically for every company. IEC 62443 is a standards series, not a single law. It can become practically mandatory when customers, tenders, contracts, conformity assessments or state-of-the-art expectations refer to it.
Is an air gap enough as a security measure?
A real air gap can be very effective if a machine does not need connectivity. It also increases operational effort: updates, data exports and maintenance have to happen physically or through tightly controlled processes. You also need to check whether the air gap is real and not bypassed by service laptops, USB drives or hidden connections.
Why is a TPM not a cryptographic accelerator?
A TPM is primarily a protected trust anchor for keys, measurements and attestation. It can perform cryptographic functions, but it is not designed to encrypt large amounts of data quickly. Depending on the platform, performance may require CPU headroom or other cryptographic acceleration.
Does every machine need confidentiality and encryption?
Not always to the same degree. In some cases integrity matters more than confidentiality: the machine must know that software, configuration and commands have not been changed. If no sensitive data is transmitted, the focus may shift. That decision should come from a risk assessment, not from gut feeling.
What is the first useful step?
Start with an inventory: which machines are connected, why they are connected, which risks arise and which legal or customer requirements apply. Only then should you decide whether separation, segmentation, hardware security, secure updates or monitoring should come first.