Industrial Security (OT) for Operators
Attack goals, threat scenarios, business impact
Attacks against OT and automation systems typically aim at three things:
- Availability: production stops, line downtime, delivery delays
- Integrity: manipulation of parameters, programs, communication, measurements
- Confidentiality: theft of know-how, recipes, production and quality data
Typical scenarios are rarely “Hollywood hacks”. They usually grow out of real operational practice:
- Remote access and contractor connections that have evolved over years
- Service laptops, USB sticks and removable media as an infection path
- Vulnerabilities in widely used software and devices combined with long update cycles
- Misconfigurations, unclear responsibilities, shared accounts
- Social engineering / phishing and credential abuse
- Availability attacks on exposed components or connections
The business impact can escalate quickly: downtime, restart costs, forensics, recovery, rebuilding systems, contractual penalties, supply chain effects and reputational damage. Even if “only IT” is hit, OT often goes down indirectly because identities, planning, logistics or central services are coupled with production.
Why operators must act
Several EU rules increase pressure on operators—directly (company obligations) and indirectly (product and supply-chain requirements). The timeline matters:
- NIS2: across the EU, national measures were intended to apply from 18 Oct 2024. In Germany, the NIS2 implementation act entered into force on 06 Dec 2025; from then on, registration and incident reporting obligations apply to affected companies.
- Cyber Resilience Act (CRA): in force since 10 Dec 2024. Reporting obligations apply from 11 Sep 2026, full application from 11 Dec 2027.
- EU Machinery Regulation (EU) 2023/1230: application from 20 Jan 2027.
In practice this means: operators must be able to demonstrate that OT security is not a one-off set of measures, but a managed, documented process.
NIS2 in more detail: who is affected?
NIS2 applies to organisations that operate in defined sectors and exceed a certain company size. A typical threshold is:
- more than 50 employees, and
- more than €10 million annual turnover or balance sheet total
In addition, the organisation must belong to a critical or important sector. Depending on classification, companies fall under “essential” or “important” entities. This is relevant for many industrial companies because production environments are often critical in the supply chain and outages have major consequences.
What does NIS2 require in general?
Affected organisations typically need to:
- assess and manage cyber risks systematically
- implement technical and organisational measures
- report incidents
- address supply-chain risks
- define responsibilities and processes
- review effectiveness regularly
Penalties and enforcement
NIS2 provides for substantial sanctions:
- for essential entities: up to €10 million or 2% of worldwide annual turnover
- for important entities: up to €7 million or 1.4% of worldwide annual turnover
Authorities can also order audits and corrective measures. Cybersecurity becomes a management topic—not just an IT topic.
CRA and the Machinery Regulation: why this affects operators indirectly
Cyber Resilience Act (CRA)
The CRA primarily targets manufacturers of digital products. For operators it matters because it drives:
- product requirements (“secure by design”)
- vulnerability handling and updates
- reporting obligations and more transparency in the supply chain
EU Machinery Regulation (EU) 2023/1230
From 2027 onward, cyber risks are considered more explicitly where they can influence safety-relevant functions. For operators this is especially relevant for:
- new procurement
- retrofits / modifications
- acceptance and “safe operation” duties in day-to-day use
Organisation and responsibilities at the operator
OT security is not only a technical project. Without clear roles and processes, it will be bypassed or “fade away” in daily operations.
Roles that must work together
- Operator / asset owner: responsible for operation, maintenance, rules, approvals and contractor control
- Manufacturer: provides product information, updates and vulnerability information across the lifecycle
- System integrator: plans and implements the solution and translates requirements into an implementable architecture
- Service providers / contractors: maintenance, outsourced operation, commissioning, remote support
A frequent weak point is privileged access. Remote access must be treated like a critical process: clear rules, clear responsibilities, proper approvals and traceability.
What must be in place organisationally
- coordination between IT and OT (who decides, who prioritises, who reports, who controls contractors)
- an OT security program as a repeatable operational process (not a one-off project)
- training and clear rules for internal staff and external contractors
- for higher maturity: metrics that show whether measures actually work
ISMS and OT security: how they fit together
Many companies already have an ISMS (Information Security Management System) or are building one (often aligned with ISO 27001). That’s good—but OT security often fails because ISMS and production/OT run separately.
An ISMS is the framework that makes cybersecurity manageable:
- responsibilities (who decides, who owns risk, who implements)
- risk management (assess risks, prioritise measures, accept residual risk)
- processes (change/config, patching, incident handling, access, suppliers)
- evidence (documentation, audits, effectiveness checks)
Why an ISMS alone is not enough
OT has different constraints than IT: long lifecycles, real-time communication, safety relevance, planned shutdown windows, contractor access and legacy systems. ISMS requirements must therefore be translated into OT reality—otherwise they become impractical, or shadow processes appear on the shop floor.
What operators need in practice
- clear IT/OT coordination (responsibilities, priorities, escalation paths)
- OT-specific implementation of ISMS processes, e.g.:
- access/remote support (approval, MFA/VPN/jump host, logging)
- change/config (who may change PLC/HMI, how it is documented)
- patch/vulnerability management (with maintenance windows and “virtual patching” where needed)
- incident handling (what counts as an OT incident, who is informed when, how isolation works)
- supplier and contractor governance as part of the ISMS (access rules, roles, security requirements)
When ISMS and OT are aligned, industrial security moves from “project” to an operational standard: repeatable, traceable and audit-ready.
Maturity Level (ML) in the organisation: what “ready enough” means
Beyond technology and documents, the key question is whether the organisation can operate security reliably over time. Maturity Levels (ML) describe how robust and repeatable security processes are.
ML1 – Starting point
- security is understood and “somehow done”
- heavily person-dependent
- rules exist partially, but not consistently evidenced
ML2 – Managed
- basic processes are defined
- responsibilities are clear
- training/competence is organised
- procedures exist and are used
ML3 – Standardised and lived
- processes run reliably, not only “when the right person is there”
- changes, access, incidents and contractor access follow a standard
- evidence is consistent across systems/sites
ML4 – Optimised
- effectiveness is measured (KPIs, reviews, lessons learned)
- continuous improvement is part of operations
- security is managed proactively, not only reactively
Why ML matters: a target architecture (segmentation, secure remote access) is worth little if the organisation cannot operate the associated processes. ML makes it visible where the organisation must catch up so OT security actually holds.
Risk analysis as an operator process
A solid OT risk analysis is not a one-time document. It is a repeatable process—restarted regularly, when threat scenarios change, or when new vulnerabilities become known.
1) Establish the factual baseline
- define the scope: machine, cell, line or plant area
- capture the as-is: architecture, inventory, communication paths, access, remote support, external services/contractors
- document dependencies: IT/OT interfaces, central services, identities, backups, remote access paths
2) Initial evaluation and prioritisation
- define tolerable risk
- first prioritisation: where are the biggest risks and leverage points?
- define “top risks” to address first
3) Create structure so measures are possible
- partition into zones and define communication paths between zones
- goal: segmentation as the basis for defence-in-depth
- define which communication is truly necessary (and what is not)
4) Deepen where needed
- go deeper where initial risk exceeds tolerance
- avoid maximum analysis everywhere—focus where the risk requires it
5) Document requirements and make them binding
- result is a clear requirements specification:
- what must be implemented technically?
- what must be organised procedurally?
- which assumptions and constraints apply?
6) Management decision
- which risks are accepted?
- which are reduced?
- what residual risk remains?
Tangible outputs
At the end, the operator should have concrete, usable deliverables:
- architecture diagram and inventory (initial and updated)
- zone and communication model as the basis for segmentation
- prioritised risks and clear action areas
- defined requirements as a basis for implementation, operation and evidence
Typical first measures with high impact
Without a “big bang”, many operators can reduce risk quickly:
- clean up remote access: rules, approvals, traceability, privileged access
- segmentation step by step: clean interfaces, defined communication paths, no unnecessary connections
- sort access and accounts: who may do what, why, and how it is traceable
- basic hygiene: inventory, versions, backups and restore as operational reality
How I support you
I support operators pragmatically in implementing OT security during ongoing operations: with a clear as-is assessment, prioritised risks, an implementable zone/communication model and a clean requirements specification as a basis for technical and organisational measures.
Note: no legal advice. The focus is on technical and organisational implementation including traceable documentation.