OT / ICS Pentest (SCADA VAPT)

No, an OT and ICS pentest from RedTeam Security is scoped so that availability is never the thing at risk.

Active testing against live controllers is excluded by default. Where it is genuinely needed it happens against a lab, a spare or a planned outage window, agreed in writing with your process engineers, and never as a surprise. Most engagements never need one.

The IT-side and boundary work runs during normal production. Anything that would touch the process waits for an outage window if it happens at all, and a named process engineer on your side holds a stop authority for the duration. Using it never requires a justification.

An OT and ICS pentest that does not touch the controllers tests the boundary, which is where the risk usually is.

Reachability from corporate IT to control, Purdue level separation as enforced in configuration rather than as drawn, vendor and remote access paths, engineering workstation posture and monitoring coverage are all testable without acting on the process. The recurring finding is not an exploitable PLC. It is that the separation from corporate IT is thinner than the diagram claims.

Historians and data diodes get particular attention, because systems bridging both sides are frequently the only real link and rarely treated as one.

The difference between an OT and ICS pentest and an IT pentest is that the risk model is inverted: availability leads, and the protocols mostly predate authentication as a concept.

A confidentiality breach in a corporate network is expensive. A loss of availability on a plant floor can be a safety event, so the test has to be designed so that proving reachability never requires disturbing the process. Modbus, DNP3, S7 and OPC are analysed passively on the wire for authentication and integrity, not probed.

Applying an IT methodology to a control network is how testing causes the incident it was meant to prevent. Tools that are routine on an IT network are not safe against a controller, so they do not run against one.

Most of an OT and ICS pentest is passive on the OT side, with active work concentrated on the IT-to-OT boundary where it is safe and where the findings are anyway.

Passive

Traffic analysis, configuration review and reachability proof. We read what is on the wire, review firewall rules and conduits, and reason from diagrams and inventories about what can reach what. Nothing is sent to a controller.

Active

Exploitation and post exploitation against the corporate side, the boundary, jump hosts and engineering workstations, under the same rules as an internal infrastructure test. Active testing against a live controller happens only against a lab, a spare or a planned outage, in writing.

The split is agreed at scoping with your process engineers, and the report states which findings were proved actively and which were established passively.

An OT and ICS pentest should be white box, and it is not close.

White box

Network diagrams, asset inventories, firewall rules and vendor access records in hand. Documentation lets us reason about reachability instead of probing a live process to find out, which is exactly the trade you want here.

Grey box

A position in corporate IT and partial documentation. Workable for the boundary and IT-side work, but every gap in the documentation is a gap we would otherwise have to close by sending packets.

Black box

Black box testing of a control network is reckless. Discovering the network by probing it is the behaviour the engagement exists to prevent, and we do not offer it.

So yes, we need your network diagrams, and the asset inventory and firewall rules too.

An OT and ICS pentest typically takes three to five weeks, driven by site count and the complexity of the IT to OT boundary, not by the number of controllers.

Each site adds its own boundary, its own vendor connections and its own engineering workstations, and each of those is reviewed rather than sampled. Documentation quality moves the timeline more than anything else, because complete diagrams replace reachability work we would otherwise do by hand.

If an outage window is needed for active work, its timing is set by your production schedule, and the rest of the engagement does not wait for it.

An OT and ICS pentest needs three people on your side: a process or automation engineer with stop authority, the owner of the IT to OT firewall, and whoever manages vendor access.

The process engineer is not optional. They hold stop authority for the duration, are reachable at all times, and never have to justify using it. They also confirm which systems are in the lab, which are spares and which are live, because we do not want to find out by trying.

The firewall owner supplies the rules and conduits we reason from. The vendor access owner tells us which standing maintenance paths exist, which are the most common route in and the least owned.

No, an OT and ICS pentest never actively tests safety instrumented systems, in any circumstances.

We assess whether they are reachable and whether they are properly separated from the control and corporate networks, which is the question that matters. A safety system that can be reached from an engineering workstation on the corporate side is a finding whether or not anything was sent to it.

That assessment is passive: diagrams, firewall rules, conduit review and traffic analysis. We do not probe safety systems, and no outage window changes that. A reachability finding against a safety system is reported with the same weight as any other path to the process.

An OT and ICS pentest treats vendor remote access as the most common route in and the least owned, so it is reviewed on every engagement.

Standing maintenance paths, jump hosts, shared credentials and supplier VPNs are enumerated, and for each we establish what a supplier can reach unattended and whether anyone would notice. A path that was opened for one commissioning job and never closed is the typical finding.

Testing is done from the position the vendor holds, with the access you grant, and never by attacking the supplier. Detection coverage is assessed at the same time, since OT telemetry rarely reaches the SOC watching IT.

The deliverables of an OT and ICS pentest are a reachability analysis from corporate IT to control, segmentation findings against the Purdue model, vendor access findings, detection gaps, and remediation ordered by exploitability instead of by CVSS.

CVSS is a poor guide on a control network, because a critical-rated flaw on an unreachable PLC matters less than a medium on a dual-homed engineering workstation. The remediation order in the report reflects which paths an attacker can actually take from where they can actually start.

Each finding carries evidence, reproduction where it was proved actively, a named owner and a mapping to MITRE ATT&CK for ICS. Once fixes land we retest, quoted up front, and issue an attestation of what was tested rather than a certificate.

An OT and ICS pentest follows the same six phases as every RedTeam Security engagement, with the methods inside each phase drawn from NIST SP 800-82 and MITRE ATT&CK for ICS.

The phases are gathering information, threat modelling, vulnerability analysis, exploitation, post exploitation and reporting. On the OT side vulnerability analysis and exploitation are largely passive, and post exploitation is a reachability argument rather than a demonstration against a live process.

Segmentation is assessed against the Purdue model, because that is the language your diagram is drawn in. Running the same structure each time means two reports a year apart are comparable.

An OT and ICS pentest evidences testing obligations under the UAE IAS for critical national infrastructure and under the DESC ISR for Dubai government entities and their suppliers.

UAE IAS

Federal entities and designated critical national infrastructure operators evidence several IAS control families through testing rather than documentation. The IAS was issued by NESA, now the Signals Intelligence Agency, which is why older tenders still name NESA even where a sector-specific standard now governs. Confirm with the issuing entity which applies before scoping.

DESC

Dubai government entities and their suppliers must test proportionately to the classification of the information handled. Supplier connections are explicitly in scope, and on a plant that means the vendor maintenance paths.