OT penetration testing and assessments
We test your automation the way an attacker would: passively during operation, actively only in an agreed window. At the end there is a map of the real communication paths and a list of findings separated by urgency.
What we do not do in your production plant
- No active vulnerability scan on the production network.
- No fuzzing against a running controller.
- No exploit without written approval and without somebody reachable while it happens.
- No write access to process values while the plant is producing.
- No tool that has not run on our own hardware first.
Every departure from that is written into the contract, with a time window, an abort criterion and a name. Whoever is responsible for the plant should know what is coming before signing.
What is documented in a grown OT network, and what runs
An automation environment grows over decades. It outlives several integrators, several generations of control system and a great deal of rebuilding during operation. What comes of that is a plant whose network plan describes the intended state and whose communication describes the grown one. That holds at every level of the industrial control system, from the PLC and the HMI through the SCADA system to the crossings into the office network.
Between the two sit the remote maintenance path left open after a project, the historian with two network cards, the access granted to a supplier three years ago. That is a consequence of systems that must not be switched off: whoever removes a connection has to prove the plant does not need it.
An assessment supplies exactly that proof. It shows which paths are actually open today, which of them somebody uses, and which can be closed without touching the process.
Three questions, three formats
They answer different things, and the order is rarely arbitrary.
Assessment: where do we stand?
Breadth against a target level. Architecture, segmentation, access concepts and detection capability get assessed and held against the requirements of IEC 62443. The result is a prioritised order of work, not an exploit.
Penetration test: is it exploitable?
Depth on a defined scope. What the assessment named as a risk is actually attempted here, with evidence and reproduction steps. That answers whether a finding is real or theoretical.
Red team: would anyone notice?
Goal-driven over weeks. The point is not the finding but whether detection and response work. Worthwhile only once monitoring exists that could notice something.
Testing without touching the plant
A vulnerability scan that passes unnoticed in an office network can cause a fault in a control environment or trip safety mechanisms. Availability and safety come before confidentiality, and the approach follows from that.
Passive methods first: architecture analysis, configuration review and evaluation of captured communication. That yields most of the answer during live operation. Active tests run only in agreed windows, on spare or lab rigs, with abort criteria fixed beforehand and in agreement with those responsible for the plant.
Where a finding could only be obtained by intervening, we reproduce it on our own hardware rather than forcing it on your plant.
What each step sets off in the plant
The most common question before a test on an industrial control system, an ICS, is whether the plant will stop. This table answers it step by step and is meant to travel with the offer.
| Step | What happens | Effect on the process | Where it runs |
|---|---|---|---|
| Architecture and configuration review | Network plans, project files and rule sets are read | none | at the desk |
| Passive capture | A TAP or a mirror port reads the traffic | none with a TAP. With a mirror port it depends on the load of the switch, which is why we measure it | production network |
| Evaluation of the capture | Devices, protocols and conversation pairs are extracted | none | at the desk |
| Passive device discovery | What is being broadcast anyway is evaluated | none | production network |
| Read query of individual devices | A named device is queried deliberately | slight. Old controllers sometimes answer unexpected queries differently than documented | agreed window |
| Exploiting a finding | The path is actually taken, with evidence | possible, so only with approval and an abort criterion | spare rig or window |
| Reproduction in the lab | The same setup on our own hardware | none | lab |
Which protocols get tested
| Protocol | Standard | Where it runs | What gets tested |
|---|---|---|---|
| Modbus TCP and RTU | vendor independent | field and process level | reachability, function codes, write access without authentication |
| S7comm and S7comm-plus | Siemens | controller level | protection levels, access to program states, classic against integrity-protected |
| PROFINET | IEC 61158 and IEC 61784 | field level | device discovery over DCP, name and address assignment |
| OPC UA | IEC 62541 | crossing into IT | the security policy offered, anonymous login, address space |
| IEC 60870-5-101 and 104 | IEC 60870-5 | telecontrol | reachability, commands, missing authentication |
| IEC 61850 with MMS, GOOSE and sampled values | IEC 61850 | substation automation | device inventory, GOOSE subscriptions, plausibility of readings |
| DNP3 | IEEE 1815 | telecontrol | reachability, secure authentication |
| CAN, CANopen, UDS, MVB | ISO 14229, IEC 61375 | vehicle and rail vehicle | diagnostic access, telegrams, bus access |
If a protocol applies that is missing here, we say beforehand whether we can read it. An unknown protocol can be derived from the capture, but that costs time and belongs in the scope.
What ends up in your hands
A zone and conduit model to IEC 62443-3-2 that reflects the real communication and not the planned one. A risk register in which every finding is rated by likelihood and impact. A gap analysis against the level required for your plants.
Out of that comes an order of work: what has to be fixed immediately, what belongs in the next maintenance window, and what is documented and accepted as residual risk. Plus a management summary that works as a basis for decisions on budget and priority. Both arrive as a test report whose findings are rated against a scheme agreed beforehand, usually the BSI one. Once the findings are fixed, a retest establishes whether they are really closed.
What a finding looks like in the report
This example is constructed. It comes from no customer project. It shows the shape in which every finding appears in the test report.
| Field | Entry |
|---|---|
| Finding ID | OT-2026-014 |
| Rating | high |
| Affected | engineering access to a controller on the process level |
| Observation | A maintenance access left over from a closed project is still reachable. Through it the controller accepts program and operating mode changes without asking for a login. |
| Evidence | Established passively from the capture. Exploitation was reproduced on a spare rig in the lab and not attempted on the plant. |
| Impact | Anyone reaching that access can halt the controller or alter its program. The control room sees nothing of it at first. |
| Recommendation | Close the access or route it through a named jump host, set the protection level on the controller, report the event to monitoring. |
| Retest | after implementation, in the next maintenance window |
What this ties up on your side
A test ties up time on your side too, with people who are short of it anyway. What is needed is listed here. The concrete hours are in the offer, because they depend on the size and the number of sites.
- Plant responsibility. Approvals, abort criteria, availability during the active steps. This is the key role and the only one that cannot be delegated.
- Network or automation. Access to the handover points, installing a TAP or setting up a mirror port, information on the existing documentation.
- IT security. Agreeing the scope, receiving the findings, agreeing the order by urgency. The result is the basis for the zone concept and the evidence and for placing the sensors in a SOC build.
- Procurement or legal. Contract, confidentiality, and the question of who signs the approval for active steps.
When an assessment is the right step
Most often it starts with a requirement from outside: NIS2, IEC 62443, or a customer who wants to see evidence. An assessment supplies that evidence and, along the way, the basis without which any further measure is guesswork.
The second trigger is an investment coming up. Before rebuilding the network architecture, before introducing a control system, or before procuring monitoring, it is worth asking which communication paths actually exist today. Otherwise an intended state gets secured that does not exist in that form.
The third is a planned SOC build. The plant and communication overview from the assessment is exactly what sensors and use cases build on later.
From plants, from our own lab, from research
We have carried out penetration tests at power plant and substation sites, security assessments in network control rooms, and tested an interlocking landscape over six months without intervening in live traffic. The sectors we work in regularly are energy, rail, manufacturing and public administration.
Preparation and reproduction happen in our own lab. It holds a model city with real telecontrol and substation technology, a Siemens production cell with controllers of the S7-1500 and S7-300 series, a train model and a vehicle rig. Testing procedures that do not run cleanly there do not go into a client plant.
Plus the research side: three and a half years in a federally funded project on vehicle security, together with partners from rail, the automotive industry and research, with an extension of our own to the tactics and techniques model for domains it did not cover until then.
How an OT assessment runs
A week for a focused section; distributed environments with many sites take correspondingly longer. The work is passive during operation; active steps only in an agreed window.
Scope and releases
Which parts of the plant, which network areas, which time windows. Plus the question of who inside is reachable if something stands out, and which abort criteria apply.
Passive capture
Capture at the handover points, evaluation of the protocols that actually run, and the existing documentation laid alongside. No active scan in the production network.
Assessment against IEC 62443
Architecture, segmentation, access concepts and detection capability held against the target level. Where a finding could only be obtained by intervening, we reproduce it on our own hardware.
Zone model and order of work
A zone and conduit model to 62443-3-2 that reflects the real communication, and a list of measures separating immediate, next maintenance window, and residual risk.
Common questions about OT assessments
Testing an automation environment for reachable paths and weaknesses, with regard for the process. Most of it runs passively: capture at the handover points and evaluation of the protocols that actually run.
Active testing takes place on spare or lab rigs, or in an agreed window, with abort criteria fixed in writing beforehand.
In IT you scan, patch and, if need be, restart. In automation each of those three is an intervention in the process. A port scan can put a controller out of step that has run for twelve years.
So the emphasis is on observation and on the question of which communication paths are really open, rather than on a list of version numbers.
IEC 60870-5-101 and 104, IEC 61850 with MMS, GOOSE and sampled values, Modbus, DNP3 and OPC UA in control technology. In the vehicle and rail environment, CAN, UDS to ISO 14229, MVB to IEC 61375 and CANopen.
The risk cannot be ruled out, but it can be bounded. In the scoping we fix which test scenario suits your appetite for risk. We validate our tools beforehand on comparable systems, and for production environments we agree abort criteria. Where no test environment exists, we usually begin with passive analysis and a configuration review.
That depends on the scope. A focused analysis of individual systems is finished within a week. Plants with several network segments take correspondingly longer. After the first conversation we can evidence the effort.
Yes. Send us the hardware and we examine it in the lab: firmware analysis, protocol implementation, debug interfaces. That is worth it before procuring new components and for security approvals.
Certifications and memberships.
Talk to us.
A first conversation usually takes 30 minutes. We look at where you stand and tell you frankly whether we are the right partner.