Insufficient IT/OT segmentation
Flat networks, firewall rules following an “any to any” pattern, or systems connected to both networks. This lets ransomware from the office network reach production unhindered.
Penetration Testing
OT Penetration Testing for ICS/SCADA and IoT
Security testing that respects your production.
When controllers are manipulated, it’s not just data that’s at stake, but equipment, products, and – in the worst case – people. With OT penetration testing for ICS/SCADA and IoT, we assess your industrial networks, control systems, and connected devices from an attacker’s perspective – with an approach that puts the safe operation of your plants first.
- Fixed price after scoping
- Free retest
- Quote within 24 hours
Definition
What is OT penetration testing?
Operational technology (OT) covers all systems that control and monitor physical processes: programmable logic controllers (PLCs), human-machine interfaces (HMIs), SCADA systems and distributed control systems (DCS), engineering workstations, historians, and safety controllers. Then there are IoT devices – from sensors and building technology to the connected products you develop and sell yourself. OT penetration testing for ICS/SCADA and IoT – often referred to as OT/ICS security testing – shows whether attackers can reach these systems, manipulate them, or use them as a gateway.
Different rules apply in OT than in office IT. Availability and functional safety take priority, plants often run for decades, and many industrial protocols were designed without authentication. Even a careless network scan can crash a controller. OT tests therefore require experience with industrial environments, non-intrusive methods, and close coordination with operations and maintenance.
Penetration tests for ICS (SCADA/DCS) and IoT devices are an established part of our service portfolio. We test the path from the office network into production as well as individual controllers, gateways, and devices – down to firmware and hardware interfaces, which we analyze using reverse engineering techniques.
Regulatory pressure is growing, too: in addition to the classic KRITIS sectors (critical infrastructure under German law), NIS2 covers many medium-sized and large manufacturing companies, for example in mechanical engineering, automotive manufacturing, electrical engineering, and chemicals. The IEC 62443 series of standards is considered the leading standard for the security of industrial automation systems, and the Cyber Resilience Act obliges manufacturers of products with digital elements to implement security by design and vulnerability management. A penetration test provides solid technical evidence for this.
Our approach
How we safely test OT networks and IoT devices
We start passively. Via a mirror port or a network TAP, we capture traffic and identify systems, protocols, and communication relationships without sending a single packet into the control network. Comparing this with your network diagrams often yields the first findings: unknown devices, unexpected connections to the internet, or systems that bridge multiple zones.
Active tests are carried out step by step – first at the IT/OT boundary, in the DMZ, at remote maintenance access points, and at engineering stations. We only test controllers directly after approval: during maintenance windows, on redundant systems, or on a test setup with identical hardware. Abort criteria and escalation paths are defined in advance together with your operations team.
With IoT devices, we go all the way down to the hardware level: we open the housing, look for debug interfaces such as UART and JTAG, extract the firmware, and analyze it for hard-coded credentials, keys, and outdated components. Wireless interfaces, the companion app, and the cloud backend are also part of the test.
Common vulnerabilities
Vulnerabilities in OT and IoT environments
Insecure remote maintenance
Permanently active vendor access, shared accounts without multi-factor authentication, or cellular routers that bypass the firewall entirely.
Industrial protocols without authentication
Via Modbus/TCP, older S7 communication, DNP3, or BACnet, anyone on the network can often read and write values, overwrite control programs, or stop the CPU.
Outdated systems
Operator stations running unsupported Windows versions and controllers with outdated firmware whose known vulnerabilities can’t be patched without the manufacturer’s approval.
Default and hard-coded passwords
Factory passwords on controllers, HMI web interfaces, and IoT devices, as well as credentials and keys hard-coded into the firmware.
Unprotected engineering workstations
They contain project files and programming software and can reach every controller – yet they’re often also used for email and internet access.
Open debug interfaces and insecure updates
A UART console with root access, enabled JTAG, or unsigned firmware updates make it possible to take over a device completely.
Weak app and cloud integration
Flawed authorization checks in the cloud API make it possible to read out or control other users’ devices – in the worst case, the entire device fleet.
Test types
Three ways to stronger security in OT and IoT
We choose the depth of testing to match your goal and your operational risk.
Network boundaries
IT/OT segmentation test
We test whether an attacker can get into production from the office network or via remote maintenance – without direct intervention in controllers.
- Firewalls, DMZ, and jump servers
- Attack simulation from the office network
- Low risk to operations
Plant network
OT penetration test
We analyze the control network passively and test HMIs, SCADA, and controllers in a controlled manner after approval.
- Passive traffic analysis and asset inventory
- Protocol and controller tests during maintenance windows
- Coordination with operations and manufacturers
Devices
IoT & product test
We test a device holistically – from the hardware and firmware to the app and cloud.
- Hardware and firmware analysis
- Wireless, app, and cloud interfaces
- Comparison with requirements from the CRA and ETSI EN 303 645
Process
How an OT and IoT penetration test works
In OT, careful planning is the most important safety factor – which is why it takes up more room in OT tests than it otherwise does in our proven approach to penetration testing.
-
01
Scoping & risk analysis
We clarify plants, networks, and devices, protection objectives, and critical processes – and which systems are excluded or tested only during maintenance windows.
-
02
Fixed-price quote & test plan
Within 24 hours of scoping (on business days), you receive a fixed-price quote. The test plan defines permitted techniques, time windows, contacts, and abort criteria.
-
03
Passive analysis
We capture the traffic, create an asset inventory, and compare the actual communication relationships with your network diagrams.
-
04
Controlled active tests
We test step by step from the IT/OT boundary to the controllers – with non-intrusive tools and in close coordination with your operations team.
-
05
Report & action plan
You receive prioritized findings and realistic measures – including compensating measures if a system can’t be patched. On request, we discuss the results together.
-
06
Retest & test certificate
You receive a test certificate to present to customers, partners, insurers, and auditors. We retest fixed vulnerabilities free of charge.
Reporting
Your OT and IoT penetration testing report
Our report takes the realities of production into account. We rate findings using CVSS and additionally classify them by zone, process criticality, and feasibility. This gives you immediate measures – such as closing an unsecured remote maintenance access point – as well as medium-term steps, for example segmentation into zones and conduits or security requirements for future procurement.
- Executive summary for senior management and plant management
- Depiction of the attack paths from IT into OT
- Rating by CVSS and operational risk
- Immediate measures and compensating measures
- Classification into zones and conduits according to IEC 62443
- Free retest and test certificate
Have your plants tested before an attacker does
Whether it’s a production network, a control system, or your own IoT product, we agree on the scope and safety precautions with you and send you a fixed-price quote within 24 hours of scoping (on business days).
FAQ
Frequently asked questions about OT, ICS/SCADA, and IoT penetration testing
Didn’t find your question? Call us at +49 2932 465265-0 or email info@rootsektor.de.
Can an OT penetration test disrupt our production?
We consistently minimize this risk: we start passively, avoid aggressive scans, and test controllers only after explicit approval – preferably during maintenance windows, on redundant systems, or on a test setup. A residual risk can never be completely ruled out with active tests. That’s why we address it openly and define the abort criteria together with you.
Do you test during ongoing operations?
Passive analyses and tests at the IT/OT boundary are usually quite feasible during ongoing operations. For direct tests on controllers and field devices, we recommend maintenance windows or a test setup with identical hardware. We define the exact approach together with your operations team.
Which protocols and systems can you test?
We work vendor-independently with common industrial protocols such as Modbus/TCP, PROFINET, S7comm, OPC UA, EtherNet/IP, DNP3, IEC 60870-5-104, BACnet, KNX, and MQTT. Typical test objects include PLCs, HMIs, SCADA and control systems, engineering workstations, industrial routers and gateways, and IoT devices of all kinds.
Does the test help with IEC 62443 and NIS2?
Yes. We check whether your zones and conduits are as effective as your IEC 62443 security concept intends, and we provide technical evidence for risk management under NIS2. The penetration test does not replace a certification or an audit.
We develop IoT products – what does the Cyber Resilience Act mean for us?
The Cyber Resilience Act (Regulation (EU) 2024/2847) requires manufacturers of products with digital elements to implement security by design and structured vulnerability management, and it imposes reporting obligations; the requirements take effect in stages. For consumer devices, ETSI EN 303 645 is considered an established baseline, and many radio products are also subject to the cybersecurity requirements of the Radio Equipment Directive (RED). A penetration test before market launch shows where your product needs improvement and supports your technical documentation.
What do you need to test an IoT device?
Ideally, at least two units, because for the hardware analysis we open one device and read out its memory. Firmware images, technical documentation, the companion app, and test accounts for the cloud backend are also helpful. The more information is available, the more efficient and thorough the test.
How do you handle network diagrams, project files, and firmware?
Documents like these are highly sensitive. We use them exclusively for the agreed test and treat them as strictly confidential. On request, we sign a non-disclosure agreement before scoping.
How much does an OT or IoT penetration test cost?
The effort depends on the number of plants, networks, and devices, the depth of testing, and the available testing windows. After scoping, you receive a fixed-price quote within 24 hours (on business days) – with no additional charges for the agreed scope.
Related pages
Request an OT or IoT penetration test
Briefly describe your plant or your product. We’ll get back to you to arrange a no-obligation initial consultation and agree on the scope and safety precautions with you – in Germany and internationally.