Part of our ongoing series on choosing a penetration testing company.

Last month a great group from the Raxis team joined me at the Raxis booth at Black Hat in Las Vegas. As most of our readers know, Black Hat is the security conference to attend each year if you work in cybersecurity.

We met many great people looking for penetration tests performed by real experts, tests which are getting harder and harder to find in a world of AI tools and scanners. Within that conversation, we often heard some version of “wait, you actually test OT?”

From utilities to manufacturers and transit agencies, the pattern is consistent. Many penetration testing companies do not offer Operational Technology testing because of the specialty skills it requires. 

Today I’d like to delve into OT pentesting. Earlier posts in this series covered how to evaluate a testing partner in general. But, if your scope includes SCADA systems, PLCs, HMIs, historian databases, or anything else that makes physical things happen, the selection criteria changes, and organizations looking for a solid and safe penetration test will want to focus on key areas when choosing a vendor. 

Why OT Is a Different Animal

In OT, availability is a safety control. A programmable logic controller that stops responding is not an inconvenience. It can be a tripped process, an alarm on the plant floor, a batch of product in the trash, or a genuine safety event. Many OT devices were engineered decades ago for deterministic, low-noise networks. They were not designed to absorb the volume of probe traffic that a modern server handles without incident.

That is the core problem with pointing standard tooling at an industrial network. A scanner does not know that the device at that address is a field controller running firmware from 2009. It just scans. When the controller freezes or becomes unstable, the pentest takes a backseat to getting systems back online and dealing with critical issues caused by the outage.

Four Ways This Goes Wrong

The vendor treats OT as IT with a different subnet. An experienced OT tester knows which checks have to be performed by hand and which specialized tools can be safely pointed at industrial equipment. They also know how a particular device is likely to react before they ever touch it. A team without that background falls back on the IT playbook and hopes the equipment can take it. Ask who will actually be doing the work and what their operational technology experience is.

The price is suspiciously good. I wrote about this in an earlier post and it’s even more critical with OT. Cheap tests are usually cheap because a scanner did the work and a junior analyst reformatted the output. In OT there frequently is no tool that can meaningfully test the system in front of you, and, where a tool does exist, running it unattended is how you end up explaining an outage to the plant manager. Automation has its place in reconnaissance and in the IT side of the environment. It cannot substitute for someone who has stood in a control room and knows what they are looking at.

Nobody planned for the moment something goes sideways. Ask a prospective vendor what happens if a device stops during testing. The pentesting team should work with your team before testing begins to ensure they know risks and limitations of your systems and infrastructure and to set up a plan for clear and fast communication with key members of your team to ask questions before an event occurs and in case of an issue as a worst case scenario.

The report is generic. This one shows up after the engagement, which is the worst time to discover it. A finding that says “apply the vendor patch” is useless when the vendor stopped supporting that firmware years ago or when the next maintenance window is eight months out. Advice that ignores your operational reality does not get implemented, and unimplemented findings do not make anyone safer.

Key Questions to Ask

Here are a few questions that can set the true OT pentesters apart from the crowd:

1. Where have your testers actually worked? No need to request proprietary info or company names. Instead ask for types of organizations and types of equipment tested.
2. How do you handle passive versus active testing? The sales team should be able to include a member of the tech team on your call so that you can become comfortable with their experience making those decisions. 
3. Do you test the IT to OT boundary, or just one side of it? Many OT compromises start in IT and walk across, so it’s important to test both together.
4. What certifications do your testers hold? While many cybersecurity certifications focus on IT vs OT, strong, industry-focused certifications like the CloTSP and PIPA show that you are dealing with high-level pentesters who will stop, think, and even discuss before trying an attack.
5. When patching is impossible, do you offer usable remediation advice? Ask about their reporting. Some companies offer canned remediation solutions instead of proposing options that will actually work within a complex OT environment.

How We Approach It

Raxis built our OT practice around one non-negotiable premise, that your operations keep running. Testing starts with scoping and coordination alongside your operations team, followed by an architecture review that catches risk on paper before anyone touches a packet. Passive reconnaissance comes next, and active testing happens only where it is warranted, with your people standing by. We have never caused an unplanned outage during an OT engagement, and that record exists because of sequencing and restraint, not luck.

Our team has worked on oil rigs, inside energy companies, across water systems, in manufacturing plants, throughout transportation infrastructure, and within telecom systems. That experience shows up in what we test, including SCADA systems and historian databases, PLCs and RTUs with their default credentials and exposed programming interfaces, industrial protocols such as Modbus, DNP3, OPC UA, and PROFINET, and the segmentation between Purdue levels that everyone assumes is holding.

It also shows up in the report. Findings arrive risk-prioritized with proof-of-concept evidence, and remediation guidance includes compensating controls for the systems you cannot patch. If your only realistic move is tighter segmentation or stricter access control on a vendor connection, we say so, and we tell you where to make the changes.

If you left Black Hat with OT on your list and no clear plan for it, that is a reasonable place to be. It is also a fixable one. Reach out to our team or schedule a time on our calendar to discuss your OT environment and to learn how Raxis can help you keep it secure.