Attack Detection in OT Networks: Audit and Proof
Operators of energy plants have to notice when someone reaches into their control systems, and prove it to the German BSI. This article shows what an attack detection system must do, how the maturity audit works, why an OT network needs its own solution and what the NIS2 implementation act changes about the proof.
Operators of energy supply networks and energy plants first had to prove the use of an attack detection system to the German BSI on 1 May 2023, and every two years after that. The basis was Section 11(1f) of the Energy Industry Act, backed by Section 8a(1a) of the BSI Act for KRITIS operators in general. Such a system covers three functional areas: logging, detection and response. How good it is gets measured against the BSI guidance OH SzA, whose revised version appeared on 18 November 2024. Auditors rate the maturity on a scale from 0 to 5. The minimum is maturity level 3 with all MUST requirements, the target is maturity level 4 with MUST and SHOULD. An OT network cannot run relabelled office IT. Observation is passive, through SPAN ports or network taps, detection has to understand OT protocols such as IEC 60870-5-104, Modbus, DNP3 and IEC 61850, and without a maintained asset inventory nobody sees anything. The NIS2 implementation act has applied since 6 December 2025. It drops the standalone report under Section 11(1f) EnWG and moves the duty into the IT security catalogue under Section 5c(4)(11) EnWG. The obligation itself stays.
Why attack detection in the OT network becomes a proof obligation
For energy operators an attack detection system is not a recommendation. It is an audited obligation. Operators of energy supply networks and energy plants first had to prove its use on 1 May 2023, and every two years after that. Skip the proof, and your report counts as incomplete. That strict.
The starting point was Section 11(1f) of the Energy Industry Act, backed for KRITIS operators in general by Section 8a(1a) of the BSI Act. The proof goes to the German Federal Office for Information Security, and it is not the operator who checks the work but a registered auditing body. The cycle has run every two years since 2023: 2023, 2025, with the next date in 2027.
The reason for the rule sits in every threat report. Energy plants are a preferred target, and the attacks come not only from criminals but from state-linked groups. The DynoWiper wiper attributed to Sandworm showed how deliberately malware now aims at control systems. An attack like that only gets caught if someone is watching, systematically and automatically.
What an attack detection system must do
An SzA is not a box you buy and bolt into a rack. It is a combination of technology, processes and staff. Section 8a(1a) of the BSI Act splits it into three functional areas, and all three have to hold. Drop one and the rest helps little.
The three areas build on each other:
- Logging: security-relevant events from IT and OT are stored centrally, tamper-proof and for long enough. This is the data foundation. Collect it with gaps and you can neither detect anything later nor reconstruct what happened.
- Detection: stored and live data are compared automatically against attack patterns. Anomalies get raised, not buried in a log nobody reads. This is exactly where a real SzA parts ways with a plain log server.
- Response: a detected incident triggers defined procedures, from alerting the right people to containment. Work out who to notify only when the fire is burning, and you have already lost.
The guidance and the maturity rating
How good an SzA is does not come down to gut feeling. The BSI wrote guidance for it, the OH SzA. It groups the requirements as MUST and SHOULD and maps each one to the three functional areas. The first version came in autumn 2022, the revised one on 18 November 2024.
In the audit, the assessors assign a maturity level from 0 to 5. The minimum is level 3, where all MUST requirements are implemented. The target is level 4, which adds the SHOULD requirements or documents why some do not apply. Level 5 is the full build. Land at 2 and you have not met the obligation, no matter how expensive the technology you bought.
The audit does not ask whether a product is installed but how well logging, detection and response work together. Level 3 is the floor, level 4 the realistic target. That is decided by processes and people, not by the software alone.
Why OT networks need their own attack detection
An SzA from office IT does not simply slot into the control system. OT networks work differently. Old protocols, sensitive processes, plants that have run for twenty years and take a restart badly. An active port scan, routine on the IT network, can knock a controller off balance.
So attack detection in the OT network looks different:
- Passive, not active: observation runs over SPAN ports or network taps that mirror the traffic. The system listens in, it does not ask. That way the process stays untouched.
- Understand the protocols: detection has to know the language of the control system, IEC 60870-5-104, Modbus, DNP3, IEC 61850. A tool that only counts TCP ports misses the actual attack on a protection function.
- Asset inventory as the basis: you can only detect what you know. Without a current list of every device, firmware version and normal communication relationship, there is no baseline against which an anomaly even shows.
This OT view complements the hardening that runs through OT security under IEC 62443 and the Cyber Resilience Act. Hardening lowers the attack surface, attack detection sees it when someone gets through anyway. The two belong together.
What the NIS2 implementation act changes about the proof
The German NIS2 implementation act has applied since 6 December 2025. It reorders the legal basis without dropping the underlying duty. For energy operators that is more than cosmetics, because the familiar reporting channel changes.
The duty stays, the reporting path moves. The standalone SzA report under Section 11(1f) EnWG is dropped. The duty to run an attack detection system moves into the requirements of the IT security catalogue under Section 5c(4)(11) EnWG. Around 29,500 companies now fall under BSI supervision, and the registration window closed on 6 March 2026. If you know the proof from the May cycle, check where it will now come together.
The thread stays the same: run an SzA, have its effectiveness audited, evidence the result. NIS2 shifts the anchor and widens the circle of those obliged, but it does not make attack detection optional. How the act interacts with the KRITIS umbrella law is set out in the piece on NIS2 and the KRITIS umbrella law. And anyone already working on the NIS2 reporting duties for municipal utilities can fold attack detection into the same effort.
What operators should do now
The path to a solid proof is plannable if it starts early. The audit asks for maturity levels, not good intentions. Four steps bring it into shape.
-
Define the scope
Set out which OT networks and energy plants fall under the duty and where the line between IT and OT runs. A fuzzy scope is the most common reason an audit takes longer than planned.
-
Assess the current state against the OH SzA
Work through the MUST and SHOULD requirements of the guidance and set the current maturity level honestly. An over-optimistic self-image gets exposed at the latest by the auditor, and that costs time.
-
Close the gaps to level 3 and 4
Prioritise the gaps between today and maturity level 3, then those to level 4. The focus usually sits with gap-free logging and OT-capable detection, not with buying yet another tool.
-
Book the audit and lock in the cycle
Arrange the date with a registered auditing body early and put the two-year cycle firmly in the compliance calendar. The proof is not a one-off task but a recurring one.
For energy operators, an attack detection system in the OT network is mandatory, proven every two years to the German BSI and rated with a maturity level from 0 to 5. Level 3 is the floor, level 4 the target. Define the scope early, assess the current state honestly and put logging and OT-capable detection first, and you walk into the audit with a proof that holds.
Further reading
Frequently asked questions
An attack detection system is not a single product but a combination of technology, processes and staff. Under Section 8a(1a) of the German BSI Act it covers three functional areas: logging security-relevant events, detecting attacks automatically and responding to identified incidents. It monitors both IT and OT networks.
Operators of energy supply networks and energy plants first had to prove the use of an attack detection system to the German BSI on 1 May 2023, and every two years after that. The proof is delivered through a registered auditing body. A report without this proof counts as incomplete.
The audit rates the maturity of the attack detection system on a scale from 0 to 5, guided by the BSI orientation guidance OH SzA. The minimum is maturity level 3, where all MUST requirements are met. The target is maturity level 4, which adds the SHOULD requirements.
OT networks use different protocols and run sensitive processes that active scans from office IT can disrupt. Attack detection in the OT network therefore observes passively through SPAN ports or network taps, without touching the process. Detection has to understand OT protocols such as IEC 60870-5-104, Modbus, DNP3 and IEC 61850, and it relies on a maintained asset inventory.
The German NIS2 implementation act took effect on 6 December 2025 and reorders the legal basis. The standalone SzA report under Section 11(1f) EnWG is dropped, and the duty to run an attack detection system moves into the requirements of the IT security catalogue under Section 5c(4)(11) EnWG. The underlying obligation remains.