OT vs IT penetration testing: key differences

When to choose OT penetration testing vs IT penetration testing

Choose OT-specific testing whenever an active test could reach a controller, safety system or process state, and use IT penetration testing for the enterprise estate. Most organizations with a corporate network beside a process network need both, run under one plan that tests the boundary between them on purpose. The boundary is where the risk concentrates: a test that starts in the office network can reach a SCADA segment if routing, shared credentials or flat VLANs allow it. NIST SP 800-82 Rev. 3 says tests on non-OT networks must not propagate into the OT network, so confirm that segmentation holds before any test begins.

Scope decisions for OT cannot be made by the security team alone. Operations owns the process and its uptime, safety engineering owns what a malfunction could cause, and the control system integrator knows which devices respond badly to scanning or malformed traffic. Ask each of them to sign off on the in-scope asset list, the permitted techniques and the outage windows before the rules of engagement are written. A single provider covering both IT and OT is sensible when that provider can show OT-specific experience, works under the same written rules of engagement, and coordinates with your operations staff. Separate teams are safer when the IT provider has no OT background, when the same people would test both sides of the boundary, or when the OT work needs a replica that the IT team cannot access.

Ask any OT testing provider how they will avoid unplanned process impact, which tests they will run against production devices and which they will run only against a replica, virtualized or simulated system, the compensating control NIST SP 800-82 Rev. 3 names for penetration testing OT. Also ask how findings are mapped to adversary techniques, since the ICS matrix on MITRE ATT&CK gives a common vocabulary for OT behavior. Request written stop conditions, a named operations contact on every test day and a clear record of which network paths were confirmed closed.

How OT penetration testing and IT penetration testing differ in goals and method

This table compares how an enterprise IT penetration test and an OT penetration test differ in goals, targets, decision makers, timing and reference frameworks. Read each row as a planning question: the OT column shows what changes when a test can affect a physical process, and the IT column shows where the familiar approach still applies.

Dimension	IT penetration testing	OT penetration testing
Primary goal	Find exploitable weaknesses in corporate systems, data and identities, and measure how far an attacker could move.	Find weaknesses that could affect process safety, availability or integrity, while keeping the process running and controllable throughout.
Typical targets	Servers, endpoints, web applications, cloud tenants, directories and corporate networks.	Controllers, SCADA servers, engineering workstations, HMIs, safety systems and the networks that connect them to corporate systems.
Scope decision makers	Security leadership and system owners, usually with IT operations agreeing to the rules of engagement.	Asset owners and operations leadership, with plant engineering and safety staff approving each active step. Confirm who holds veto power before work starts.
Where active tests run	Usually production or a staging copy, chosen for realism and data fidelity.	Preferably a replica, virtualized or simulated system. Live active tests are scheduled into planned outage windows where production must be used.
Tolerance for disruption	Some downtime or degraded service is often acceptable and can be planned with business owners.	Low. Devices may be fragile, have limited resources and be sensitive to timing, so an unexpected stall can affect physical processes.
Passive versus active methods	Active exploitation is common, with passive review used alongside it.	Passive monitoring and configuration review come first. Active scanning or exploitation is limited to what the asset owner has approved for a given device.
Reference frameworks	NIST SP 800-115 for test technique and process, with MITRE ATT&CK Enterprise for adversary behavior and detection planning.	NIST SP 800-82 Rev. 3 for OT countermeasures and test constraints, NIST SP 800-115 for process, and MITRE ATT&CK for ICS for adversary behavior specific to industrial control.
What a good result looks like	Validated attack paths, prioritized findings with remediation owners, and evidence that detections fired for the techniques used.	Validated attack paths with safety and availability impact stated, safe test methods documented, and remediation sequenced around outage windows and operator procedures.

What the gas utility outage teaches about OT test scope

The published example in NIST SP 800-82 Rev. 3 shows that a test scoped to a corporate network can still reach operational technology. In that case, a penetration test of a gas utility's corporate network strayed into a part of the network connected to SCADA, locked up the SCADA system and stopped gas being sent through pipelines for four hours. The lesson for buyers is that the boundary between IT and OT must be enforced by network controls and written rules of engagement, not assumed because the test was approved for the corporate network. The guide states that tests on non-OT networks must not propagate into the OT network, so the boundary is a requirement the provider must meet, not a preference.

For a buyer, the practical question is how the boundary is proven before any traffic is sent. Ask the provider which segments are in scope, which are explicitly excluded, and which controls keep the test host from reaching SCADA, historian or engineering networks. Ask who checks those controls, when, and what happens if a tester finds a path into an excluded zone. Confirm also how the rules of engagement name the stop conditions, who on the utility's side can halt the work, and how that person is reached during the test window. NIST SP 800-115 provides a rules of engagement template in Appendix B that can serve as a starting point, but the OT-specific conditions still need to be written into it.

Treat the example as an illustrative warning rather than a full account of the incident. The source does not describe the tools used, the segmentation design, or the exact sequence of events, so do not build your scope on assumptions about them. Before you sign, request the network diagram the provider will test against, confirm that the test plan names every connection between corporate and OT zones, and check that the outage risk has been reviewed with the operations team. If the provider cannot show how the boundary is verified, that gap is the finding to resolve first.

What each approach finds and what it misses

IT and OT penetration tests look for different weaknesses and fail in different places. The cards below set out what each typically finds, what it leaves unexamined, and what to confirm in the written scope before work starts.

IT testing: identity, web and network paths

An IT penetration test usually finds weak credentials, excessive privilege, exposed web applications and lateral movement across internal networks. It often reaches domain administrator through misconfigured directory objects. What it typically misses is process behavior: how a controller responds to a malformed packet or a scan burst, and whether a safety interlock still holds. Confirm in the written scope whether any OT segment is excluded, and who decides what happens if a tester reaches one.

OT testing: remote access and engineering workstations

An OT assessment often finds exposed vendor remote access, shared engineering workstations, flat networks between corporate and control zones, and legacy protocols that accept commands without authentication. These findings usually matter more than a single software flaw. Ask the provider how it will validate each finding without sending traffic that could disturb a controller, and whether it will test in a replica or during a planned outage.

OT testing: where enterprise attack paths stop

When scope ends at the OT boundary, the test cannot show how an attacker in the business network would reach the control environment through identity systems, shared file stores or remote support tools. Those paths often decide real exposure. Confirm whether the written scope includes the enterprise path into OT, the accounts that cross the boundary, and the evidence the provider will produce for each path it validates.

OT testing: segmentation and unsafe protocols

Segmentation tests check whether firewalls, data diodes and zone rules block the traffic they are meant to block, and whether unsafe protocols are reachable from zones where they should not be. These checks are often done by configuration review and passive observation first, then by limited active checks. Ask which checks run actively, against which assets, and who on the asset owner side approves each one.

Finding too little without active testing

A review limited to documents, passive traffic capture and vulnerability databases can produce a clean report that still leaves exploitable paths unproven. Teams often conclude that a system is safe because no active test was run, which is a gap in evidence rather than proof of security. NIST SP 800-82 Rev. 3 treats active testing as a risk to weigh, not a reason to skip it. Ask the provider which findings remain unverified and how the team will validate them safely.

How an OT penetration testing engagement is sequenced

The sequence keeps active testing away from fragile controllers until rules, boundaries, a test environment and a stop condition are agreed and checked. Each step produces a record the operations and safety owners can sign off before the next one starts.

Agree written rules of engagement with operations and safety owners
The provider drafts rules of engagement covering scope, permitted techniques, timing, named contacts and who may halt a test, based on the template NIST SP 800-115 provides in Appendix B. The client's operations, process safety and plant engineering owners must approve it in writing, including which systems are off limits for active work. Done means a signed document that names an on-site authority who can stop testing at any time.
Map boundaries and inventory assets passively
Before any packet is sent to a controller, the provider reviews network diagrams, firewall rules and conduit placement, then observes traffic passively to identify assets, protocols and the links between corporate and OT networks. The client supplies current architecture documents, asset lists and access to a span or tap point. Done means a validated asset inventory and a boundary map that shows where IT-side tests could reach OT, since NIST SP 800-82 Rev. 3 warns that tests on non-OT networks must not propagate into the OT network.
Confirm or build a replica and check its fidelity
Where active testing is needed, the provider proposes a replicated, virtualized or simulated system, which NIST SP 800-82 Rev. 3 lists as a compensating control for penetration testing OT. The client confirms which controllers, firmware versions, logic and network paths the replica reproduces and which it does not. Done means a written fidelity gap list, so the team knows which findings on the replica must be re-checked on production in a planned window.
Schedule active work into planned outage windows
Active scans can cause device instability or interfere with process state, so NIST SP 800-82 Rev. 3 recommends scheduling them during planned OT outages whenever possible. The client decides which windows are acceptable, and the provider aligns test steps to them, noting that production OT may need to be taken offline for some tests. Done means an approved calendar of test activities tied to specific assets and outage conditions.
Run tests with a defined stop condition
Before each active step, the provider states the observable signs that would end it, such as loss of communication, unexpected controller state changes, or alarms that suggest process interference, and the on-site authority confirms the halt method. The tester runs only the approved techniques, logs every action with a timestamp, and pauses when a stop condition is met. Done means a complete activity log and a record of any halts, with the reason and the device affected.
Validate detections against the techniques used
After active testing, the provider maps the techniques it actually used to the MITRE ATT&CK for ICS matrix, which has 12 tactics from Initial Access to Impact, and the client checks whether monitoring generated alerts for them. The client supplies access to OT monitoring and historian logs for the test windows. Done means a per-technique table showing which activities were detected, which were missed and which need a monitoring rule or a process change.
Report findings with remediation that preserves safety
The report ranks findings by safety and process impact as well as technical severity, and each recommended fix is checked against the performance, reliability and safety requirements that NIST SP 800-82 Rev. 3 asks countermeasures to maintain. The client's engineering and safety reviewers approve remediation paths before changes are scheduled. Done means a report reviewed with operations and safety owners, with each finding linked to an owner, a validated fix plan and a retest in a planned window.

Which test model fits which OT environment

A production process network with live controllers is the most sensitive target. NIST SP 800-82 Rev. 3 notes that OT systems are highly sensitive to timing constraints and have limited resources, and that active scans may cause device instability or interfere with process state, which can affect safety and integrity. The sensible sequence starts with passive work: listening to traffic, building an asset inventory and reviewing configurations and network diagrams. Active work is reserved for windows that the plant has planned and approved, and NIST advises scheduling active scans during planned OT outages whenever possible.

Passive first: Ask for passive monitoring and document review before any packet is sent to a controller.
Planned outage windows: Ask who owns the outage decision, how the window is agreed, and what the rollback plan is if a device stops responding.
Operator presence: Ask that process engineers and operators be on site or on call for every active step.
Stop conditions: Ask for written criteria that halt testing, such as unexpected controller behavior or alarm changes.
Boundary checks: Ask how the provider confirms that tests from corporate networks do not reach the OT segment.

Before signing, confirm in writing which hosts and protocols are in scope for active work, and who on the plant side can stop the test.

What you receive from an OT test compared with an IT test

This table compares the deliverables an IT penetration test usually produces with those an OT test needs, because safety, process impact and outage planning add records that an enterprise report does not carry. Read each row as a question to put in the written scope, since exact formats must be confirmed before work starts. The main takeaway is that OT deliverables record what was not tested and why, as much as what was.

Deliverable	Typical IT penetration test	OT penetration test
Rules of engagement and scope record	Targets, testing windows, permitted techniques and emergency contacts, usually agreed once with the client	Adds named process owners, prohibited techniques on controllers, stop conditions tied to process state, and which networks are out of bounds for pivoting
Asset inventory	Hosts, services and applications found during discovery, often from active scanning	Passively derived or vendor-confirmed list of controllers, firmware versions and communication paths, with notes on which devices were not touched
Findings with process and safety impact	Severity based on confidentiality, integrity and availability of data and systems	Each finding also states the possible effect on process, safety and availability, and the plant owner who must accept the risk
Evidence of what was tested and when	Timestamps, source addresses, tool logs and screenshots of exploitation	The same, plus the operating state of the process at each step and confirmation of the outage window or replica used
Replica test results and fidelity limits	Usually not applicable, since tests run against the production or staging environment	Results from a replicated, virtualized or simulated system, with a written statement of what the replica does not reproduce, such as timing or vendor-specific behavior
Outage-window run sheet	Not usually produced	Ordered steps, expected system responses, rollback actions, and who on site can halt the test; confirm the planned outage window with the asset owner
Retest plan	Retest of reported findings, scheduled by the client	Retest scheduled around the next planned outage, with any fix validated in a replica before the production change
Mapping to ATT&CK	Often mapped to enterprise ATT&CK tactics and techniques where agreed	Mapped to the ATT&CK for ICS matrix, which has 12 tactics, or to enterprise ATT&CK where the agreed scope covers IT paths into OT

What drives cost and duration in OT and IT testing

OT testing costs more in time and coordination than in tooling, because the work depends on test benches, outage windows and people who know the process. The cards below cover each component that moves the price and schedule, who is paid for it, and what to request in a written quote.

Replica or test bench build

A replica, virtualized or simulated copy of the control environment is the compensating control NIST SP 800-82 Rev. 3 names for testing OT that cannot be exposed to live exploits. The build is largely one-time work, but each rebuild after a firmware change, a process update or a new controller adds recurring effort. Ask the provider whether the quote covers building the bench, maintaining it between tests, or only using a bench the client already owns, and who verifies that the replica matches production.

Outage window coordination

Active testing on OT is scheduled into planned outages whenever possible, according to NIST SP 800-82 Rev. 3, so the calendar often sets the duration more than the test itself. Coordination means agreeing windows with plant operations, holding rollback plans and paying for idle time if a window slips. Ask who books and holds the windows, how many windows the quote assumes, and what happens to the fee if a window is cancelled.

Operations staff time

Plant operators, control engineers and shift leads must attend planning sessions, watch active tests and confirm process state before and after each step. This time is usually the client's internal cost, but it is often missing from the budget. Ask the provider to list the operations roles it expects to need, the hours it assumes for each, and whether it will pause testing when those staff are unavailable.

Safety and operations review

Before any active step, the scope, rules of engagement and safe-state checks must be reviewed with people who understand the safety case for each process. This review is recurring for each engagement and can stop a planned test entirely. Ask who signs off on the test plan, what safety criteria stop a test, and whether the provider's quote includes time for these reviews or assumes they are already complete.

Passive monitoring time

Passive observation of OT network traffic is low risk to systems, but it takes elapsed time to build a useful picture of assets, communication paths and protocols. It can run alongside planned outages or in advance of them. Ask whether the quote bills passive monitoring by calendar period or by analyst hours, who installs and removes sensors, and how long the capture runs before the active phase begins.

Industrial protocol and controller skills

Engineers who test OT need working knowledge of industrial protocols and controllers, and they need to know which requests can upset a device. This skill is scarce, so it is typically the largest rate driver in an OT quote. Ask for the named staff's experience with the specific controllers and protocols in your environment, whether they hold ICS-specific training, and whether the provider will use ATT&CK for ICS to plan the tests.

Reporting and retest

OT reports need process-safe remediation advice and a retest after fixes, which can wait for the next outage window and so extend the calendar. Retest scope is often left out of the first quote. Ask whether the price includes one retest or several, how fixes are validated on a replica before production, and what the provider does when a retest must wait for a window.

Questions buyers ask about OT penetration testing

Can an IT penetration tester test our OT network?

Only with specific preparation, and often not in the way an IT test is run. NIST SP 800-82 Rev. 3, published in September 2023, says penetration testing must be used with care on OT networks because these systems are highly sensitive to timing constraints and have limited resources. A tester who is strong on enterprise networks still needs OT-specific planning: knowledge of process safety, vendor controllers, and the rule that testing on non-OT networks must not propagate into the OT network. Ask the provider how it scopes OT work, which tests it will avoid on live controllers, and who on its team has run tests on industrial systems before.

What drives the cost and duration of an OT penetration test?

The written scope sets the cost and duration. The main drivers are the number of sites and network zones, the number and types of devices in scope, whether testing happens on a replica or in production, how many planned outage windows are needed, and whether the work is passive, active or both. Each added zone or outage window adds coordination effort from the client's operations staff as well as the provider's time. Ask any provider to break its quote into planning, testing, outage support and reporting, and to state which assumptions the price depends on.

What must we provide before an OT penetration test starts?

You must provide the information and access that lets the provider avoid harm. In practice this includes current network diagrams for the OT and connected IT zones, an asset inventory, a list of safety-critical functions, and the names of the people who can stop a test. You also need agreed outage windows, a rollback plan, and contacts for each controller vendor. The rules of engagement should record what is out of bounds, such as particular PLCs or active scans. NIST SP 800-115 includes a rules of engagement template in Appendix B that is a useful starting point for this agreement.

Can our own team run OT penetration testing internally?

Your team can run it, but it needs the right people and a safe test environment. Internal staff know the process better than any outside tester, which helps with scoping and safety decisions. The gap is usually adversary-focused testing skills and independence, since the team that operates a system is also the team judging its weaknesses. NIST SP 800-53 control CA-8 has an enhancement for an independent penetration testing team, so compliance programs may expect outside testers. Confirm with your assessor whether independence is required for your program before you decide.

Do we need a replica of our OT environment for penetration testing?

A replica is not always required, but NIST SP 800-82 Rev. 3 lists a replicated, virtualized or simulated system as an example compensating control for penetration testing operational technology. It also says production OT may need to be taken offline for testing. A replica lets testers try exploits without risking a live process, but it only proves what the replica actually matches. Ask the provider how it confirms that the replica's firmware, configuration and network paths reflect production, and which tests still have to run against live equipment during a planned outage.

Which compliance frameworks require which kind of penetration testing?

Each framework sets its own requirement, so confirm the exact obligation with your assessor. PCI SSC's Penetration Testing Guidance (v1.1, September 2017) describes penetration testing as essentially a manual process and says simply running an automated tool does not satisfy the requirement. NIST SP 800-53 Rev. 5 control CA-8 has enhancements for an independent team and for red team exercises, and SP 800-53B selects CA-8 only in the high baseline. DORA Article 26 requires threat-led penetration testing at least every 3 years, but only for entities that their competent authority identifies. Frameworks for OT specifically should be checked against NIST SP 800-82 Rev. 3 and the sector regulator's guidance.

How does OT testing fit with a scheduled IT penetration test?

Run the OT work as its own planned exercise, then connect its findings to the IT test. The IT penetration test tends to target enterprise systems, while OT testing focuses on controllers, engineering workstations and the boundaries between zones. Schedule OT work around outage windows, and keep IT testing from crossing into OT networks by agreeing those boundaries in the rules of engagement. Shared findings, such as weak remote access or credential reuse between IT and OT, deserve joint review. NIST SP 800-115 notes that organizations often combine techniques to reach an in-depth assessment at an acceptable level of risk.

How DeployOpen scopes, runs and supports OT and IT security testing

DeployOpen plans, runs and documents security testing inside the client's own infrastructure, including OT and IT engagements. For industrial networks, we agree the test boundary, safety limits and outage windows in writing before any active work starts, so testing does not reach controllers that cannot tolerate it.

How we scope

Engagements are fixed-scope, with targets, rules of engagement and deliverables agreed in writing before work begins.
We define which OT zones, IT segments and bridging paths are in and out of bounds, and who approves each.
We confirm whether a replica, simulated system or planned outage window will carry any active testing.

How we build

We map the test plan to each zone, so passive discovery comes first and active steps follow only where approved.
We prepare the test environment and tooling in the client's own network, with segmentation checked before testing starts.
We record every action, timing and affected asset so the client can tie any process impact to a specific step.

How we hand over

Reports separate IT findings from OT findings, with the safety and process conditions attached to each recommendation.
We document the test boundary, evidence and retest steps so the client's own staff can repeat the work.
Remediation guidance is written for asset owners and operations staff, not only for the security team.

How we support

Ongoing support, upgrades and continuous testing are available as retainers after the initial engagement.
Retainers can cover scheduled retesting after changes to OT networks, firmware or IT segmentation.
Ask us to confirm the support scope, response expectations and outage coordination in the written agreement before signing.

OT penetration testing vs IT penetration testing