For a long time, industrial companies treated cybersecurity as part of office IT. Firewalls, antivirus, passwords, backups — while the production or energy system ran separately, following its own engineering logic.

With the convergence of IT and OT, that dividing line has disappeared. PLCs, inverters, building automation, SCADA, gateways and remote service connections can now all be part of the same digital risk landscape. The consequences, however, remain physical: halted production, faulty control, a lost energy supply or an unavailable service.

This is why NIS2 raises cyber-risk management to management and organisational level. IEC 62443, in turn, provides an industrial security approach and a set of requirements with which the OT environment can also be put in order technically.

NIS2 is not a technology shopping list

The European Union’s NIS2 Directive has created a more uniform cybersecurity framework for 18 critical sectors. Medium-sized and large companies within its scope must put in place appropriate risk-management measures and incident-reporting processes. The Directive also specifically emphasises the responsibility of senior management.

This is an important change: cybersecurity cannot be delegated without limit to a system administrator or an external service provider. Management must understand and manage which digital dependencies put essential operations at risk.

NIS2 does not tell you which vendor’s firewall to buy. It expects risk-based operation, including:

  • incident handling;
  • business continuity and recovery;
  • supply chain security;
  • vulnerability management;
  • access control;
  • cryptography and communication security;
  • security awareness;
  • assessing the effectiveness of the measures.

Whether a given organisation actually falls within scope, and which national requirements apply to it (in Hungary, NIS2 is transposed by Act XXIII of 2023), must be determined individually on the basis of its sector, size and services and the applicable national law. Managing technical risks is nevertheless in a company’s business interest, even if it ultimately turns out not to be an obliged entity.

Why is OT risk different?

OT systems have long life cycles. Equipment that is ten or twenty years old, operating systems that are no longer supported, or controllers that are hard to update without stopping production are not unusual.

In addition, in OT:

  • availability and physical safety come first;
  • changes must be tested because of the process risk;
  • many devices were never designed for a hostile network environment;
  • remote access by manufacturers or maintenance contractors is common;
  • the asset inventory is often incomplete;
  • responsibility is split between IT, automation, operations and suppliers.

That is why simply copying a conventional IT security policy is not enough.

The role of IEC 62443

The ISA/IEC 62443 series of standards addresses the cybersecurity of industrial automation and control systems across their entire life cycle. It is not aimed at operators alone: it defines requirements and roles for device manufacturers, system integrators and asset owners as well.

One key element of the approach is the definition of risk-based zones and of the conduits between them, i.e. controlled communication links.

A zone can contain devices with similar risks and security requirements. Data flows between zones may only take place over defined paths and protocols, according to defined rules.

This way of thinking is far more precise than “we have a firewall towards the internet”. An attack or a fault can just as well originate from the inside — via a remote maintenance connection, from a supplier’s laptop or from a compromised IT system.

The first uncomfortable task: an inventory of assets and data connections

You cannot protect what you do not know exists.

The first meaningful step in OT security is therefore usually not the installation of a new product, but mapping the real environment:

  • which PLCs, HMIs, meters, inverters and gateways are in operation;
  • with which firmware and software versions;
  • on which network they can be reached;
  • with whom they communicate, and over which protocol;
  • who can access them locally and remotely;
  • which business or physical process depends on them;
  • what happens if they fail or are compromised.

The inventory should not remain a static Excel sheet. It is worth linking changes, responsibilities, events and documents into a traceable system as well.

Remote access is a typical weak point

Industrial systems often need support from the manufacturer or integrator. The problem is not remote access itself, but uncontrolled, permanent and direct access.

A defensible solution must define:

  • who may initiate the connection;
  • whether multi-factor authentication is required;
  • which specific system can be reached;
  • in which time window;
  • whether local or management approval is required;
  • whether the session can be logged;
  • how the permission can be revoked;
  • what happens when the supplier contract ends.

A setup along the lines of “AnyDesk is on the machine in case we need it” is convenient, but it is not a security architecture.

The supply chain is part of OT

In an industrial system, security is not determined by your own team alone. The hardware manufacturer, the firmware supplier, the integrator, the telecommunications provider and the cloud platform can all be part of the risk chain.

The technical specification and the contracts should therefore also cover, for example:

  • the support and update period;
  • how vulnerabilities are reported;
  • access and logging requirements;
  • component and version information;
  • cooperation during an incident;
  • the return of data and configurations.

This is where the supply-chain perspective of NIS2 meets the life-cycle and role-based approach of IEC 62443.

Security that works, not just compliance

Ticking off an audit checklist does not in itself stop an attack. The real goal is for the organisation to know its critical processes, reduce its attack surface, detect anomalies, limit propagation and be able to restore operations in a demonstrable way.

In this environment, OrigSmart should be seen as more than a data visualisation platform. Managing field devices, gateways, network connections, identities, events and executable processes together helps turn security requirements into technical operation.

In the projects OrigSmart manages, security has to be designed as part of the architecture: segmented connections, least privilege, logged events, controlled remote access, local fallback operation and traceable action.

NIS2 makes it clear that cyber risk must be taken seriously at organisational level. IEC 62443 helps translate this into the technical reality of OT systems.

Let’s discuss your project

Sources

Note: this article provides general professional information and does not constitute legal or compliance advice.