How We Pen Test OT Without Breaking Production

The traditional red-team playbook does not work in OT. Aggressive scanning, off-the-shelf exploitation frameworks, credential spraying against unknown devices — all of these will, with reasonable probability, crash a PLC or trip a safety system. In a production environment, that is not a finding. That is a lawsuit.

OT penetration testing has to be done differently. This post describes how we do it, and how you should evaluate any provider offering OT testing in your environment.

The three-layer methodology

Layer 1: Passive reconnaissance (always)

Before any active packet is sent, we passively analyze the OT network for days to weeks. We listen, we map, we fingerprint. We identify devices by protocol behavior, by vendor-specific signatures, by the cadence of their communications. We catalog conduits and segmentation.

By the end of passive recon, we typically know more about the network than the integrator who installed it. We know every device, its protocol, its peers, and its behavior. We know what a "normal" day looks like. We know which devices look fragile and which look robust.

Layer 2: Controlled active testing (in scoped zones)

Active testing proceeds carefully, in specific zones, with explicit operator supervision. In OT, "active" does not mean "aggressive." It means carefully scoped interactions — a single SYN, a single read request, a single targeted probe — each evaluated against the known behavior of the target device.

We never use generic exploitation frameworks in production OT. When we test exploitability of a specific finding, we do it on a representative test device — either one the customer has provisioned, or one we source from vendor spare inventory — never on a production PLC driving actual process.

Layer 3: Staged Level-3 exercises

For customers who want to understand their attack surface at the Purdue Level 3 boundary — the industrial DMZ between operations and enterprise — we run carefully staged exercises. These typically include:

• Simulated phishing to harvest corporate credentials
• Attempted lateral movement from harvested credentials into Level 3 systems
• Attempted pivot from Level 3 into Level 2 or Level 1 — stopped at the first successful boundary crossing, not pursued to impact

The goal of a Level-3 exercise is not to break things. It is to demonstrate whether the segmentation model actually holds under realistic adversary behavior. We stop as soon as we have the answer.

What a bad OT pentest looks like

Signs a provider is not prepared for OT work:

• Their methodology is the same as their IT pentest methodology, with "OT" in the title
• They want to run Nessus or similar against production PLCs
• They want to run Metasploit modules against unknown devices
• Their consultants' certifications do not include any OT-specific credentials (GICSP, GRID, IEC 62443 CSP, or equivalent)
• Their scope does not include a passive reconnaissance phase
• They cannot articulate which vendors' devices are known-fragile and why

What a good OT pentest produces

A good OT pentest produces:

• A precise asset inventory — often the first accurate one the facility has
• A detailed segmentation map with documented gaps
• A prioritized list of findings with remediation paths that respect operational constraints
• Specific artifacts — captured credentials, reached devices — that demonstrate the risk without exploiting it
• A shared understanding with plant operations about what is and is not defensible

What it does not produce: a crashed PLC, a tripped safety system, or a production outage.

Scoping the engagement

A typical OT penetration test at a mid-size manufacturer or data center runs 4–8 weeks. The first 2 weeks are passive. The next 2–4 are controlled active. The final 1–2 are reporting and debrief. We price on scope, not on "days of effort" — the effort varies substantially based on what we find.

If you are evaluating OT penetration testing providers, or you have a specific concern about your OT attack surface, we should talk.