OT security for energy suppliers and grid operators
We test control rooms, substations and telecontrol architectures technically and without disruption, build the detection for them, and prepare your teams for the real thing. For municipal utilities, distribution network operators and generators.
Network control rooms, substations, telecontrol stations and engineering systems form the backbone of energy supply, and together an attack surface that has grown over decades. We assess it technically, without disruption, and with an eye on the evidence that regulators and operators actually need.
Attacks on power grids are documented, not hypothetical
In December 2015 the power went out at three Ukrainian distribution network operators. Attackers operated circuit breakers over the telecontrol system while the fault reporting line was blocked by a telephone flood. Around 225,000 households were affected.
A year later came Industroyer. That malware no longer needed an operator: it spoke the telecontrol protocols itself, IEC 60870-5-101 and -104 as well as IEC 61850, and communicated directly with protection and control devices. In 2022 a reworked version appeared again, configured for one specific substation.
Both were operations requiring considerable effort. The more important part of the picture is a different one: in 2024 the Polish CERT documented a series of accesses to smaller water and heat suppliers where controllers and operator interfaces were reachable straight from the internet, in some cases with no credentials or with default ones. No malware was developed there and no vulnerability exploited. It was enough to find a reachable device and change a setpoint.
That is the point for a German operator. Industroyer takes a state actor. The second case takes a search engine for exposed devices. And the protocols are the same ones in both cases that run in German substations and control rooms.
Six results that turn up in almost every test
This is the state such attacks would meet. Findings we come across regularly in the energy sector. The causes lie in long lifecycles, architectures that have grown over time, and a service provider landscape that has become complex along with them.
Connections missing from the network plan
Office IT and control room are connected directly or through intermediate systems at layer 3. The plan shows one controlled transition; the network holds a second one beside it.
Remote maintenance without a second factor
VPN access for external service providers, often over shared accounts. Who did what and when can rarely be reconstructed afterwards.
Engineering workstations without hardening
The machine that programmes controllers and holds the project states runs without hardening and without monitoring, yet has access to everything it programmes.
Historian and SCADA left behind
Operating systems stay at the state they were accepted in. Patch windows exist, but they are not enough for a backlog of years.
Segmentation documented, not enforced
Between the control level and the process-near systems there is a zone concept on paper. Whether the firewall rule sets implement it is another question.
Protocols running unobserved
IEC 60870-5-104 to the control room, IEC 61850 in the station network, Modbus and DNP3 in distribution. Everything is transmitted, nothing is evaluated. An untypical command goes unnoticed because nobody is looking.
What we have done in the energy sector
Penetration tests at power plant and substation sites, security analysis in network control rooms, segmentation reviews and the hardening of telecontrol architectures. Alongside that, building security operations centres whose use cases bring IT and OT data sources together, running since 2019.
One example further down this page is a test in a power plant environment: a week on site, two OT specialists, findings with reproduction steps rather than a scanner list.
The preparation happens in our own lab. It holds a model city with real telecontrol and substation technology, up to IEC 61850 with GOOSE and MMS. Test procedures that do not run cleanly there do not go into a client plant.
How an OT penetration test runs in an energy environment
A vulnerability scan that passes unnoticed in an office network can cause a fault in a control room. Availability and safety come before confidentiality, and the approach follows from that.
Passive methods first: architecture analysis, configuration review, and evaluation of captured communication on IEC 60870-5-104, IEC 61850 with MMS and GOOSE, Modbus and DNP3. That yields most of the answer during live operation. Active tests run only in agreed windows, on spare or lab equipment, with abort criteria fixed beforehand.
What comes out is a map of the real communication paths, a zone and conduit model to IEC 62443-3-2, and a list of findings separating immediate, maintenance window, and acceptable residual risk.
How an OT SOC for energy environments is built
An IT SOC does not see the attacks described above. It recognises malware on a server, not a switching command at a time when nobody switches. Events like that are protocol-conformant and only stand out against the background of normal operation.
The build therefore starts passively at a mirror port, with no return channel into the process, and with a baseline of normal operation.
Where the sensors sit is decided by the protocol. IEC 60870-5-104 runs over TCP/IP between control room and station gateway and is reachable on the wide area link. IEC 61850 falls into two worlds: MMS as client-server traffic between station control and protection devices, and GOOSE as layer 2 multicast between the devices themselves. GOOSE is not routed, so a sensor for it has to stand in the substation, not in the data centre. On the process bus, sampled values come on top. In distribution and at smaller stations you find Modbus and DNP3. OPC UA appears wherever control technology is connected to higher-level systems, which makes it frequently the actual bridge between OT and IT.
The use cases come from the tactics and techniques model for industrial environments, from publicly analysed malware, and from our own testing work. What should be detected: the switching command at the wrong time, the unknown device on the station bus, the GOOSE message with an implausible sequence number, and the outbound connection that should not exist.
What training and an incident exercise look like
Anyone who has to weigh shutdown against continued operation on the day should not be making that judgement for the first time.
For managers it is about understanding: how a control room is built, the difference between a controller and a server, the concrete demands of IEC 62443. For technical staff it is craft: reading protocols, spotting anomalies, writing detection rules, on real controllers.
The practice happens on our model city: real controllers, real telecontrol and station protocols, and an attack whose effect becomes visible in the model while a SIEM records beside it. The scenarios are derived from the incidents named above.
It closes with a facilitated incident exercise with distributed roles. We also run exercises like that in existing security operations centres, that is, with the teams who would actually be at the screen on the day.
What is required, and what the evidence has to answer
The German KRITIS regulation, NIS2, the IT Security Act and IEC 62443 all meet in the energy sector and demand different things. The practical conflict rarely lies in the text of the standards but in their simultaneity: a requirement satisfied under one rule book does not automatically answer the evidence duty under the next.
In an audit, at the latest, a network plan is not enough as evidence. The question is about technical reality, and it comes down to four points: is the separation between IT and OT actually enforced or only documented? Is remote access restricted in a way that can be traced? Is there transparency over the real communication paths? And are security-relevant events in the OT detectable and analysable at all?
What a way in actually looks like
The usual start is a focused architecture and segmentation review.
First conversation, about an hour
We establish the architecture, the regulatory position and the timing constraints. After that both sides know whether this makes sense, and at what scope.
What you provide
Existing network plans and plant documentation, contacts from OT and IT, and the opportunity to capture passively at a transition point. Incomplete documentation is not an obstacle; it is the normal case.
Focused test, a few weeks
Architecture, segmentation and real communication paths on a defined section. Distributed environments with many sites take correspondingly longer.
Result and priorities
Management summary, documented findings with technical context, a description of the real paths, and a prioritised list of measures. After that you decide what comes next.
What energy suppliers ask us beforehand
No. Passive analysis, configuration review and evaluation of the segmentation all run during operation. Active tests belong in an agreed maintenance window or on a lab rig, with defined abort criteria.
Yes, and it is the normal case. Energy environments have grown over time. Part of the work consists precisely of making the real architecture visible.
Not straight away. An assessment first delivers the asset inventory and the topology needed for sensor placement and use case development. Monitoring without that basis produces noise rather than detection.
Before a regulatory audit, after architecture changes, when introducing new remote maintenance concepts, as IT/OT networking increases, or when there is doubt whether the segmentation actually holds.
IEC 60870-5-104 between control room and station, IEC 61850 with MMS and GOOSE in the station network, sampled values on the process bus, plus Modbus and DNP3 in distribution and OPC UA at the transitions to higher-level systems. Which of those run at your site comes out of the capture, not out of the documentation.
Especially then. The documented accesses to smaller suppliers went after everything reachable from the internet. The way in is correspondingly small: a delimited test of the transitions and the remote access paths.
That depends on the scope and the number of sites, and we name the order of magnitude in the first conversation, not after it. A focused segmentation and architecture review at one site sits well below what a distributed project across several substations requires.
