OT Security Vendors: How to Vet Real Industrial Capability

Here's the quickest way to sort OT security vendors. Ask what they'd do on day one at a plant they've never walked. If the answer is scan the range and see what comes back, you're done. Older controllers fault under ordinary scanning, and a firm that doesn't know that has never stood on a plant floor.

Two kinds of company will pitch you and their websites are indistinguishable. One has negotiated a test window with an operations manager and watched an engineer's face change when a device stopped responding. The other added an OT slide to an IT deck.

MSP Pentesting is channel-only and delivers OT and ICS work under our partners' brands, so what follows is the vetting process we'd want you to run on us.

The stakes aren't the same as IT. On a corporate network the worst case of a clumsy tester is an outage and an awkward email.

On a plant network the worst case is physical.

Why OT vendor selection is its own exercise

Assume you've already sorted the commercial side. Channel terms, branding, non-solicit, all of that applies to any testing vendor and you should have it locked before this conversation starts.

What changes in OT is competence. The specific failure mode is a capable IT firm operating confidently in an environment it has misread.

Here's the tell. Ask a vendor to describe the worst outcome of a badly run test. If the answer is a data breach, they're still thinking in IT.

On a plant floor the thing being protected is a process that has to keep running safely. A tester who drops a line to prove a point hasn't found the incident. They've caused it.

Every question below tests whether a vendor has internalized that or just read it somewhere.

What OT-specific competence looks like

They name the protocols before they see the network

Ask what they expect on the wire at a mid-size manufacturer. A real OT team answers immediately: Modbus TCP, DNP3, EtherNet/IP with CIP, PROFINET, S7comm on Siemens sites, BACnet where building systems are in scope, OPC UA where anything modern was installed.

Then ask the follow-up that separates reading from experience. Which of those authenticate?

The correct answer is that most of the legacy set doesn't, because they assumed a trusted serial link and got carried onto IP without anyone revisiting that assumption. DNP3 has a secure authentication extension that's rarely deployed. OPC UA was designed with security in mind and often gets configured without it. A vendor who talks about testing credential strength on Modbus has never touched Modbus.

The practical consequence matters more than the trivia. When the protocol can't authenticate, the control is segmentation, monitoring and access discipline. Not a patch.

They think in zones and conduits, not subnets

IEC 62443 is the working vocabulary of this industry, and a competent vendor reaches for it without prompting. IEC 62443-3-2 covers risk assessment and the partitioning of a system into zones and conduits. IEC 62443-3-3 defines system security requirements and security levels. IEC 62443-2-4 sets security program requirements for service providers, which is worth quoting back at them, because it's describing the vendor themselves.

They should also place assets on the Purdue model without hesitating.

• Level 0. Field devices and sensors.
• Level 1. Controllers and PLCs.
• Level 2. Supervisory control, SCADA and HMIs.
• Level 3. Site operations, historians and MES.
• Level 3.5. The industrial DMZ.
• Levels 4 and 5. Enterprise IT.

None of that is academic. Most genuine OT findings are boundary failures, not software vulnerabilities.

A historian dual-homed into both the plant and the corporate network. An engineering workstation with a browser and internet access. A vendor remote support tool that reaches from the internet straight through the DMZ into Level 2, because commissioning was easier that way.

NIST SP 800-82 Revision 3, the guide to OT security, is the other reference you want to hear. If a vendor cites only NIST SP 800-53 and applies it unchanged to a plant floor, they're running an IT playbook somewhere it doesn't fit.

Passive first, and they say so before you ask

Ask how day one starts.

The answer you want involves listening. A SPAN port or a network tap, passive traffic capture, an asset inventory assembled from observed conversations, configuration review from exported files rather than live interrogation of devices, and firewall rule analysis between zones.

Active work comes later, if at all, against agreed targets in an agreed window, at rates chosen so a controller doesn't get swamped. The caution isn't superstition. NIST SP 800-82 warns against active scanning of live OT without environment-specific validation, and every controls engineer you meet has a story about the day somebody tried it.

So a vendor who opens with we'll scan the range and see what comes back is describing an IT engagement. In OT that answer on its own ends the evaluation.

Ask in the same breath what hardware they own. Mature teams validate exploitation against a bench PLC, not a live one.

Safety, abort conditions and rollback are agreed up front

A real OT test plan is written before anyone connects, and it contains things an IT scope document never has.

• Per-activity risk rating. Each action rated for process impact, with the risky ones moved into a shutdown or dropped.
• A named abort authority. Someone client-side, usually operations, who can stop the test with one sentence and never has to justify it.
• A rollback position. What gets restored, by whom, and how long it takes if a device needs a power cycle.
• Explicit treatment of safety systems. Safety instrumented systems governed by IEC 61511 don't get actively tested on a live process, and a vendor should state that boundary before you have to.
• Kickoff attendance. If nobody asked for operations and controls engineering in the kickoff, they plan to test a plant using the IT department's mental model of it.

Ask to see a redacted test plan from a previous OT engagement. Sales decks are easy. Test plans aren't.

They know what testing does to warranties and validated systems

Industrial estates carry contractual constraints that have nothing to do with security. OEM support agreements that void if you touch a controller configuration. Validated systems in pharma where any change triggers requalification. Vendor-locked robot cells.

A competent vendor asks who owns support for each system before scoping. A generalist finds out afterwards, when the OEM refuses a warranty claim.

OT-capable vendor versus IT firm with an OT slide

Six questions that expose a generalist

• How would you inventory assets where scanning isn't permitted? Good answer: passive capture, switch and firewall configs, controller project files, interviews with the controls engineer. Bad answer: we'd get permission to scan.
• Which protocols here support authentication, and what do you do about the ones that don't? Good answer moves straight to segmentation and monitoring. Bad answer talks about credential policy.
• What's your abort condition and who can call it? Good answer names a client-side role. Bad answer describes an internal escalation process.
• How do you write up a finding on a device nobody can patch for three years? The real test, covered below.
• Where do safety instrumented systems sit in your scope? Good answer excludes them from active testing without being asked.
• Give me an OT finding an IT tester would have written up wrong. A vendor with real engagements has the story ready. One without starts speaking in generalities.

Compensating controls are the proof of experience

This is what decides whether an OT report is usable. In IT the answer to most findings is patch it. In OT that option often doesn't exist, because the OEM stopped shipping firmware years ago and the change window opens twice a year.

An inexperienced vendor writes patch to current firmware and hands over a document the plant will ignore.

An experienced one writes recommendations that survive the constraint.

• Segmentation between Purdue levels with an actual DMZ, not a VLAN tag and a hope.
• Conduit hardening, so traffic between zones is limited to known protocols between known endpoints.
• Vendor remote access through a brokered jump host with MFA and session recording, replacing the always-on tunnel.
• Protocol-aware monitoring that alerts on engineering commands, firmware writes and mode changes.
• Application allowlisting on engineering workstations, which are usually the softest target in the building.
• Removable media controls, because that's still how a lot of code reaches a controller.

Every item there has an owner and a change window. That's what makes a report actionable in a plant. If your client needs the risk picture before committing to testing, a scoped risk assessment is usually the right first engagement rather than jumping straight to hands-on work.

Red flags worth ending the call over

• They quote a fixed price on IP count alone, without asking about device types, criticality or production schedule.
• They describe OT experience but every reference is an IT network test at an industrial company. Testing the office network of a manufacturer isn't OT experience.
• They want to install agents on control system hosts.
• They can't name a single OT asset discovery approach that isn't a scanner.
• They have never asked what the process actually makes.

Frequently asked questions

Our IT pentest firm says they cover OT. Do we need a separate vendor?

Ask them the protocol question and the abort authority question. If both answers are solid, they cover OT. If they hedge, what they cover is the IT network at an industrial site. That's a legitimate service. It just isn't this one.

Is an OT security assessment the same as an OT penetration test?

No, and mixing the two up causes most of the scoping arguments in this space. An assessment reviews architecture, segmentation, configurations and processes, largely without touching live devices. A penetration test attempts exploitation against agreed targets. In OT most clients should buy the assessment first, because it finds the boundary failures that matter and it doesn't put the process at risk to do it.

Can OT testing happen without stopping production?

Much of it can, as long as the vendor stays passive and works from configurations and captures. Active testing against controllers usually waits for a planned shutdown. A vendor who claims full active testing on a live process with no risk is either misreading the environment or overselling it.

Which standards should the report map to?

IEC 62443 for architecture and system requirements, NIST SP 800-82 Revision 3 for OT guidance, and NERC CIP where the client operates bulk electric system assets. If they also carry IT compliance obligations, the OT findings should map into that program rather than sitting in a document nobody reconciles.

What insurance should an OT vendor carry?

Ask for the certificate before kickoff, not after an incident. Professional liability and general liability at limits that make sense next to a production line, and read the exclusions. Standard errors and omissions policies often carve out damage to a client's property and business interruption, which is most of what goes wrong in a plant.

Then ask whether it holds when they subcontract. If they're passing your OT work to a third party, the certificate you were shown doesn't cover whoever plugs in. Resell that under your own logo through a white labeled pentesting arrangement and their gap is your gap.

How to run this evaluation

Get the vendor on a call with your client's controls engineer in the room. Say nothing for the first ten minutes.

Your engineer will know inside two questions whether the person on the other end has ever been in a plant, and they'll tell you plainly afterwards. That call is worth more than any capability matrix.

If you want a scoped OT engagement you can put your own logo on, get a pentest quote and we'll walk the scope with your engineer before anything gets priced.