SCADAPENTEST
Rules of engagement

OT · ICS · SCADA

Testing a plant is not testing a network

A control network runs a physical process. The scan that maps an office in ten minutes has swung a robot arm, hung a wafer fab and stopped a gas pipeline. This site sets out what can honestly be tested on a live OT environment, what cannot, and what has to wait for a lab or a shutdown.

Work out your approach See the method ledger
  • Primary sources only
  • NIS2 · IEC 62443 · NIST SP 800-82r3
  • No vendor products sold

AI-101 · Definition

What OT security testing is, and what it is not

Operational technology controls a physical process. That single fact reorders every priority an IT tester works from.

OT security testing is the assessment of the systems that measure and control a physical process: SCADA masters and remote terminal units, distributed control systems, programmable logic controllers, human machine interfaces, historians, engineering workstations and the networks between them. The object under test is not data. It is a pump, a breaker, a furnace, a valve, a train.

NIST puts the priority order plainly for operational technology: “Human safety is paramount, followed by protection of the process.” The same document adds the line every rule of engagement should quote: “Any security measure that impairs safety is unacceptable.” Confidentiality, the thing an IT test usually exists to defend, is fourth of seven foundational requirements in IEC 62443 and rarely the reason anyone is worried.

The constraints are structural, not cultural. OT outages “must be planned and scheduled days or weeks in advance”. Components live “10 to 15 years and sometimes longer”. Many devices run operating systems the vendor no longer patches, and installing third-party software can void the support contract that keeps the line running. Field-level sensors and actuators “cannot be authenticated” at all, so a spoofed reading is indistinguishable from a real one.

None of that makes OT untestable. It makes the method the decision. A good OT engagement produces more evidence than an IT-style scan ever would, because it is built from passive observation, configuration and logic review, and targeted testing at the levels that can absorb it. What it does not do is find out whether a controller crashes by crashing it on a running plant.

ZS-200 · Purdue rack

The method follows the level

The Purdue model is the reference most plants already segment by. It is also the cleanest way to say which technique belongs where. NIST recommends organising OT segmentation with it, and enforcing firewall rules that “prevent Level 4 devices from directly communicating with Level 2, 1, or 0 devices”.

  1. Purdue level L4/5: Enterprise and business network

    ERP · email · corporate directory · VPN concentrators · remote-access brokers

    Standard methods

    Ordinary IT penetration testing, with one added rule: the test must be prevented from propagating downward. This is where most real intrusions into OT begin.

  2. Purdue level L3.5: Industrial demilitarised zone

    Historian replica · patch and antivirus relays · jump hosts · vendor gateways · data diodes

    Standard methods

    The most productive band in an OT engagement. Broker hosts, one-way gateways and firewall rulesets can be tested and reviewed hard without the process noticing.

  3. Purdue level L3: Site operations

    Historian · batch and MES servers · engineering workstations · domain services for OT

    With controls

    Authenticated configuration review, credential and patch-state analysis, and read-only access to the historian. Active exploitation only with the process owner present and a rollback agreed.

  4. Purdue level L2: Supervisory control

    SCADA master · DCS operator stations · HMIs · alarm servers · engineering software

    With controls

    Review the configuration, the accounts and the remote-access paths. Active probing belongs in a booked window, and only against devices the operator has agreed to and can restart.

  5. Purdue level L1: Basic control

    PLCs · RTUs · DCS controllers · protection relays · safety instrumented systems

    Lab or outage

    Offline analysis of the project files, ladder logic and firmware. Live interrogation belongs in a shutdown window or on a replica. Safety instrumented systems stay out of scope in writing.

  6. Purdue level L0: Field instrumentation

    Sensors · transmitters · actuators · variable-speed drives · fieldbus segments

    Lab or outage

    NIST notes these devices and protocols “cannot be authenticated”, so there is nothing to test that a document review will not tell you. Any injection here is process intervention, not testing.

Levels are a language, not a law. Many real plants are flatter than the model and a few are more segmented; the first deliverable of an OT engagement is usually an accurate picture of which of these bands actually exist. Source: NIST SP 800-82r3, sections 5.2.3.1, 5.3.6 and 5.4.1.

HS-300 · Approach selector

Work out what you can safely test

Three answers about your environment, and the table returns the methods that are defensible, the ones that are not and why, what has to move to a lab or an outage, and the safety controls the engagement needs before anyone connects anything.

Interactive mode is not available. You can read the full reference content below. No answers are assessed and no result is calculated.

  • Always safe on a live process: passive traffic capture at a SPAN port or tap; architecture, data-flow and firewall-ruleset review; offline review of controller projects, ladder logic and device configuration; and normal penetration testing of the enterprise network and the internet-facing edge, provided it is prevented from propagating downward.
  • Safe with controls: authenticated review of the engineering workstation with an image taken first; testing of the historian and the IT/OT demilitarised zone using read-only credentials; and a receive-only wireless and radio telemetry survey.
  • Not on a live process: active scanning of the control network; active interrogation of PLCs, RTUs and field devices; exploitation and post-exploitation inside the control network; protocol fuzzing; and anything at all that touches the safety instrumented system.
  • Lab, replica or shutdown window: fuzzing and robustness testing, firmware extraction and exploit development, and any proof that a controller can be crashed or reprogrammed. NIST names a “replicated, virtualized, or simulated system” as the compensating control for penetration testing operational technology.
  • Controls every OT engagement needs: a named process authority who can stop the test instantly; a written abort phrase on a live voice channel; an explicit exclusion list; a rollback and restart plan agreed with the vendor; time-stamped logging that can be compared against the process historian; and testers who understand the process, not only the protocol.
Discuss scope with OffSeq

HS-301 · Site input

Environment
What the test position can reach

Select every path that exists, even the ones nobody uses any more. Choose none to see the baseline.

Disruption the process can absorb

Approach7 permitted · 0 controlled · 5 blocked

VD-01

Observation and review on site, everything intrusive in a lab

With no tolerance for disruption, the live environment supports passive and read-only work only. Anything that writes, probes or exploits has to be reproduced on a replica, a vendor test rig or a digital twin, and the findings carried back as engineering evidence rather than a live proof.

VD-02

Observation on site, intrusive work inside a booked window

A short supervised window lets a careful, device-by-device active check run on the supervisory band with the process owner watching and a stop word agreed. Field devices and exploitation still belong in an outage or a lab; a few minutes of degraded operation is not the same as permission to crash a controller.

VD-03

The outage is the opportunity, and it is the only one you get

A planned shutdown is the one time active testing of controllers is defensible, and it is expensive, so it has to be planned like commissioning: a fixed device list, the vendor reachable, backups taken first, and a return-to-service check before anything restarts.

Method verdicts

  • M-01 PermittedWith controlsNot on liveNot in reach

    Passive traffic capture at a SPAN port or network tap

    Adds no traffic to the network at all, which is why NIST calls it “ideal for sensitive devices found on OT networks”. Expect it to take days and to miss anything that is not talking.

  • M-02 PermittedWith controlsNot on liveNot in reach

    Architecture, data-flow and firewall-ruleset review

    Documents, rule exports and interviews touch nothing. This is where the flat network, the outbound rule nobody owns and the undocumented conduit are usually found.

  • M-03 PermittedWith controlsNot on liveNot in reach

    Offline review of controller projects, logic and device configuration

    Copies of the project files, ladder logic and device configuration are read away from the plant. Hard-coded credentials, disabled interlocks and stale logic show up here and nowhere else.

  • M-04 PermittedWith controlsNot on liveNot in reach

    Testing the internet-facing edge and remote-access path

    No remote path was declared. If one exists that nobody remembers, discovering it is itself a finding worth the engagement.

  • M-05 PermittedWith controlsNot on liveNot in reach

    Authenticated review of the engineering workstation

    The highest-value host in most plants: it holds the projects, the credentials and often a route to every controller. Review it authenticated, with an image taken first.

  • M-06 PermittedWith controlsNot on liveNot in reach

    Testing the historian and the IT/OT demilitarised zone

    Broker hosts, replication accounts and the rules around them can be tested properly. Use read-only credentials and write nothing to the historian.

  • M-07 PermittedWith controlsNot on liveNot in reach

    Wireless and radio telemetry survey

    Not selected. Worth confirming, because point-to-point radio and cellular routers at remote sites are frequently absent from the network diagram.

  • M-08 PermittedWith controlsNot on liveNot in reach

    Active scanning of the enterprise network

    Normal above the DMZ. NIST is explicit that where testing runs on non-OT networks, “extra care is taken to ensure that tests do not propagate into the OT network”.

  • M-09 PermittedWith controlsNot on liveNot in reach

    Active scanning of the control network

    Not on a running process. A ping sweep is enough: NIST records one that swung a robot arm and one that hung a fabrication system and destroyed 50,000 dollars of wafers.

  • M-10 PermittedWith controlsNot on liveNot in reach

    Active interrogation of PLCs, RTUs and field devices

    No. These devices have limited resources and hard timing constraints, and a malformed or merely unexpected request can hang them or change the process state.

  • M-11 PermittedWith controlsNot on liveNot in reach

    Exploitation and post-exploitation inside the control network

    No. Proving an exploit works on a live controller means accepting whatever the exploit does to the process, which is not a risk a tester can consent to on the operator’s behalf.

  • M-12 PermittedWith controlsNot on liveNot in reach

    Any testing that touches the safety instrumented system

    Out of scope in writing, every time. TRITON showed that the capacity “to disable, inhibit, or modify the ability of a process to fail safely” has physical consequences; a test must not create that condition itself.

  • M-13 PermittedWith controlsNot on liveNot in reach

    Protocol fuzzing and robustness testing

    Lab only, on the same firmware version. Fuzzing exists to drive a device into states its designers never specified, which is the one outcome a running process cannot absorb.

  • M-14 PermittedWith controlsNot on liveNot in reach

    Replica, vendor test rig or digital twin

    Required here, not optional. NIST names “a replicated, virtualized, or simulated system” as the compensating control for penetration testing OT, and with no tolerance for disruption it is the only place intrusive work can happen.

Move to a lab or an outage

  • Protocol fuzzing and robustness testing, on the same firmware and configuration as the plant.
  • Firmware extraction, binary analysis and exploit development against controller images.
  • Anything involving the safety instrumented system, including reading its configuration over the network.
  • Active scanning of the control network, reproduced against a replica so the technique is proven before it is ever proposed on site.
  • Interrogation of PLCs, RTUs and field devices, on identical hardware where it exists.
  • Exploitation and lateral movement inside the control network, demonstrated end to end on the replica.

Safety controls the engagement needs

  • A named process authority with the standing to stop the test instantly, reachable for every minute of it, and not the person running the test.
  • A written abort phrase and a live voice channel. Email is not a stop control. Everyone on both sides knows the phrase and what happens after it.
  • An explicit exclusion list of devices, addresses and protocols that are out of scope, agreed in writing before the first packet.
  • A rollback and restart plan agreed with the system vendor, including who has the backups and how long a restore actually takes.
  • Time-stamped test logging that can be laid alongside the process historian, so any process upset can be attributed or ruled out within minutes.
  • Testers with OT experience. NIST removed the independent-tester requirement from its high baseline precisely because the skill set is scarce; knowledge of the process beats another certification.
  • A full image and project backup of the engineering workstation taken before it is touched, verified restorable.
  • Read-only historian credentials, with an explicit agreement that nothing is written to the historian or its replication path.
  • The safety instrumented system is excluded in writing, and reviewed separately through the functional-safety lifecycle instead of over the network.
Discuss scope with OffSeq

This is a planning aid built from published guidance, not an assessment of your site and not a permit. The final decision on every method belongs to the people who own the process and the safety case.

FT-400 · Method ledger

What each method actually buys you

Every OT method trades coverage against process risk. The honest way to present that trade is a spec sheet, not a promise.

  • M-01

    Passive traffic capture

    What it finds

    Every device that is talking, the protocols in use, plain-text credentials, unexpected conduits between zones, and often firmware versions and part numbers.

    Risk to the process

    None. A tap or SPAN port adds no traffic. The honest limits: it cannot see silent devices, it cannot read encrypted traffic, and it often needs days.

    When it can run

    Any time, on a running process.

  • M-02

    Architecture and ruleset review

    What it finds

    Flat segments, permissive outbound rules, dual-homed hosts, forgotten vendor tunnels, and the gap between the network diagram and the network.

    Risk to the process

    None. Reads exports and drawings, then verifies a sample by physical inspection rather than by scanning.

    When it can run

    Any time. Usually the first thing scheduled.

  • M-03

    Project, logic and configuration review

    What it finds

    Hard-coded and shared credentials, bypassed interlocks, unsafe defaults, unused services left enabled on PLCs and HMIs, and logic that no longer matches the drawing.

    Risk to the process

    None on site. Work happens on copies, away from the plant, on an air-gapped analysis machine.

    When it can run

    Any time, once someone is nominated to produce the exports.

  • M-04

    Edge and remote-access testing

    What it finds

    Exposed management interfaces, unpatched VPN and firewall appliances, weak or absent multi-factor authentication, and vendor tunnels that bypass the DMZ.

    Risk to the process

    Low, and contained above the process. The rule is that no test traffic crosses into the control network, verified by the tester and the firewall logs.

    When it can run

    Any time. This is where real intrusions start.

  • M-05

    Engineering workstation review

    What it finds

    Local admin sprawl, unpatched engineering software, saved controller credentials, USB history, and whether the host also sits on the office domain.

    Risk to the process

    Low with an image taken first. The host is often single-purpose and irreplaceable, so treat a rebuild as a real possibility.

    When it can run

    Any time, with the process owner informed and a verified backup in hand.

  • M-06

    Historian and DMZ testing

    What it finds

    Replication accounts with more rights than they need, broker hosts reachable from both sides, and data paths that quietly run the wrong way.

    Risk to the process

    Low, read-only. Writes to a historian corrupt the record the plant uses to explain its own behaviour, so they are excluded by agreement.

    When it can run

    Any time, with read-only credentials issued for the test.

  • M-07

    Wireless and telemetry survey

    What it finds

    Unmanaged access points, legacy encryption, point-to-point links absent from the diagram, and cellular routers at remote sites with default management.

    Risk to the process

    None while receiving. Transmitting is a different activity: losing a telemetry link can itself trigger a fail-safe action at an unattended outstation.

    When it can run

    Receive-only any time. Transmit testing in a screened environment.

  • M-09

    Active scanning of the control network

    What it finds

    Silent devices, open ports and service versions that passive capture cannot reach, and an inventory that is complete rather than merely observed.

    Risk to the process

    Real and documented. Device instability, changed process state, and in NIST’s own case files a moving robot arm and a hung fabrication system.

    When it can run

    A booked window at the earliest, an outage by preference, and only after the tooling has been proven offline.

  • M-10

    Field-device interrogation

    What it finds

    Controller firmware versions, protocol behaviour, authentication weaknesses, and whether a device accepts commands it should refuse.

    Risk to the process

    High. Limited resources and hard timing constraints mean an unexpected request can hang a controller. Recovery takes longer than any window.

    When it can run

    A planned shutdown, or a replica.

  • M-13

    Fuzzing and exploit development

    What it finds

    Undiscovered vulnerabilities in controller firmware and protocol stacks, and hard proof of what an attacker could achieve.

    Risk to the process

    Deliberately destabilising. That is the technique, not a side effect.

    When it can run

    Laboratory only, on matching hardware and firmware. Findings go to the vendor through coordinated disclosure.

Sources for the risk column: NIST SP 800-82r3, control CA-8 and appendices C.3.4, E.2.2 and E.2.3. The coverage column is generalised from OT assessment practice and is deliberately stated as capability, not as a guarantee of findings.

PTW-500 · Permit to work

The engagement, run like a permit

A plant already has a language for dangerous work performed by outsiders: the permit to work. An OT security test should borrow it wholesale, because the failure modes are the same.

PTW-510 · Before the first packet8

Controls that must exist before testing starts

  1. A named process authority

    One person with the standing to stop everything, reachable throughout, and not the person running the test.

  2. An abort phrase on a live channel

    A spoken stop word on an open voice channel, known to both sides, with an agreed action after it is used.

  3. An exclusion list in writing

    Devices, addresses, protocols and functions that are out of scope, agreed before the engagement rather than argued during it.

  4. Backups verified restorable

    Controller projects, engineering workstation images and device configuration, restored once to prove the backup is real.

  5. A rollback plan owned by the vendor

    Who restores what, in what order, and how long it takes with the vendor on a normal support response.

  6. Logging aligned to the historian

    Every test action time-stamped so a process upset can be attributed or ruled out in minutes rather than in a post-incident review.

  7. A defined window and audience

    Start and stop times published to the shift on duty, not only to the project team that commissioned the test.

  8. Testers who know the process

    People who can read a P&ID and a ladder diagram. NIST accepts that an independent OT tester may simply not be available, and prefers competence to independence.

PTW-520 · Deliverables

What the report owes the plant

  • An asset and conduit inventory as observed, not as documented, with the differences called out.
  • Findings expressed as consequence to the process: what an attacker could make the plant do, not a CVSS score.
  • A zone and conduit view that a 62443-3-2 risk assessment can be built on directly.
  • Remediation ranked by what can be done without an outage, then what needs the next turnaround.
  • Evidence that is reproducible without repeating the test: captures, configuration extracts, rule exports.
  • A statement of method and coverage: what was run, where, and under whose authority.

And the part most OT reports omit

An explicit list of what could not be tested safely, and what it would take to test it. “We found nothing” and “we could not look” are different sentences, and only one of them is a result. A report that silently merges them gives the board a false assurance that the next outage will expose.

ALM-600 · Event log

The record, with sources

Two kinds of entry sit in one chronology on purpose: tests that broke a plant, and attacks that did. Every line links the primary document it came from.

  1. NIST case file Test caused

    A ping sweep swings a robot arm

    While a ping sweep ran on a live SCADA network controlling nine-foot robotic arms, “one arm became active and swung around 180 degrees”. The controller had been in standby before the sweep started. A second sweep, run purely for inventory, hung a system controlling integrated-circuit production and destroyed 50,000 dollars of wafers.

    NIST SP 800-82r3, App. C.3.4
  2. NIST case file Test caused

    A penetration test stops a gas pipeline for four hours

    A natural gas utility hired an IT security consultancy to test its corporate network. The consultancy “carelessly ventured into a part of the network that was directly connected to the SCADA system. The penetration test locked up the SCADA system, and the utility was not able to send gas through its pipelines for four hours.”

    NIST SP 800-82r3, App. C.3.4
  3. Dec 2015 Attack

    Ukraine: breakers opened by remote control

    Three regional electricity distribution companies suffered outages affecting approximately 225,000 customers. All three were infected with BlackEnergy, delivered by spear phishing, but CISA states it does not know whether the malware played a role: the outages came from remote operation of the breakers over legitimate remote-access tooling.

    CISA IR-ALERT-H-16-056-01
  4. 2017 Attack

    TRITON: malware written for a safety controller

    HatMan, also called TRITON and TRISIS, modified in-memory firmware on Triconex Tricon safety controllers to allow arbitrary code execution. CISA notes it surpassed Stuxnet and Industroyer with “the ability to directly interact with, remotely control, and compromise a safety system”, and that removing a process’s ability to fail safely “could result in physical consequences”.

    CISA MAR-17-352-01 (Update B)
  5. May 2021 Attack

    Colonial Pipeline: IT ransomware, OT shut down by choice

    DarkSide ransomware was deployed “against the pipeline company’s information technology (IT) network”, and the company “proactively disconnected certain OT systems to ensure the systems’ safety”. The control network was never touched and the product still stopped moving. CISA’s advice: map the IT and OT interdependencies, and regularly test the manual controls.

    CISA AA21-131A
  6. Apr 2022 Attack

    Tooling built to scan, compromise and control PLCs

    DOE, CISA, NSA and the FBI described custom tools able to “scan for, compromise, and control” Schneider Electric MODICON and OMRON Sysmac PLCs and OPC UA servers, including brute-forcing over UDP port 1740 and sending custom Modbus commands. Not a research demo: capability built for a device class, not a victim.

    CISA AA22-103A
  7. May 2023 Attack

    Denmark: 22 energy operators in a few days

    SektorCERT recorded “the most extensive cyber-related attack we have experienced in Denmark to date”: 22 companies operating parts of the Danish energy infrastructure compromised in a coordinated campaign through internet-facing Zyxel firewalls (CVE-2023-28771, later CVE-2023-33009 and CVE-2023-33010). Attackers reached industrial control systems and several companies had to go into island mode operation.

    SektorCERT, The attack against Danish critical infrastructure
  8. Dec 2023 Attack

    Default passwords on internet-facing PLCs

    IRGC-affiliated actors defaced Unitronics Vision series PLCs and HMIs across water and wastewater, energy, food and beverage manufacturing, transport and healthcare, simply “by authenticating to internet-connected devices with communications set to the default TCP port 20256” using the default password or no password at all.

    CISA AA23-335A
  9. Feb 2024 Attack

    Five years inside, waiting

    CISA and international partners assessed that PRC state-sponsored actors are “seeking to pre-position themselves on IT networks for disruptive or destructive cyberattacks against U.S. critical infrastructure”, primarily in communications, energy, transport and water and wastewater, using living-off-the-land techniques, with footholds held for at least five years.

    CISA AA24-038A
  10. May 2024 Attack

    Water pumps driven past their set points

    CISA and nine partner agencies reported pro-Russia hacktivists reaching HMIs over exposed VNC on port 5900 with default credentials, then “maxed out set points, altered other settings, turned off alarm mechanisms, and changed administrative passwords to lock out the WWS operators”. Some sites saw minor tank overflows; most reverted to manual control. The agencies also note these actors exaggerate their impact.

    CISA, Defending OT Operations Against Ongoing Pro-Russia Hacktivist Activity

Deliberately absent: Stuxnet figures, the 2016 Kyiv outage and the Oldsmar water incident. Each is either unverifiable from a primary text or later disputed, and an incident list is only as good as the documents behind it.

REG-700 · Regulation

What the law and the standards actually ask

Three instruments touch industrial security in the EU, and none of them says “penetration test” about OT. Knowing what they do say is what keeps a programme proportionate.

NIS2 sectors with heavy OT, by annex

  • Electricity, gas, oil, hydrogen, district heating
  • Drinking water
  • Waste water
  • Rail, air, road and maritime transport
  • Manufacturing (NACE divisions 26 to 30)
  • Chemicals
  • Food production and processing
  • Waste management

REG-710 · NIS2

Directive (EU) 2022/2555

NIS2 never mentions penetration testing in its risk-management article. What Article 21(2)(f) requires is “policies and procedures to assess the effectiveness of cybersecurity risk-management measures”. Assessment is mandatory; the method is yours to justify.

  • Measures must follow an all-hazards approach protecting the systems “and the physical environment of those systems”.
  • Article 20(1): management bodies approve the measures, oversee implementation and can be held liable for infringements.
  • Article 21(2)(d) pulls the integrator and the vendor into scope through supply-chain security.
  • Annex I lists energy, transport, drinking water and waste water; Annex II adds manufacturing, chemicals, food and waste.
Read the NIS2 guide

REG-720 · IEC 62443

ISA/IEC 62443, by role

The series is organised into General, Policies and Procedures, System and Component groups, and the part that applies to you depends on whether you own the plant, integrate it or build the products in it.

  • Asset owner: 62443-2-1 security programme requirements, with 62443-2-5 implementation guidance.
  • Service provider or integrator: 62443-2-4, plus the 3-x system requirements.
  • Product supplier: 62443-4-1 secure development lifecycle and 62443-4-2 component requirements.
  • 62443-3-2 partitions the system into zones and conduits and sets a target security level (SL-T) for each; 62443-3-3 defines the system requirements behind those levels.
  • The seven foundational requirements put resource availability and restricted data flow alongside confidentiality, not beneath it.
Read the 62443 guide

REG-730 · CRA

Regulation (EU) 2024/2847

The Cyber Resilience Act regulates the products, not the plant. It matters to an operator mostly as procurement leverage, and its dates are close enough to write into contracts now.

  • Applies from 11 December 2027; the Article 14 reporting duty for actively exploited vulnerabilities applies from 11 September 2026.
  • Recital 60 recognises that products “intended for use in industrial settings, such as industrial control systems, are often in use for significantly longer periods”, so support periods should be longer than five years.
  • PLCs, RTUs and HMIs are ordinary products with digital elements, not Annex III or Annex IV products. Do not let a supplier imply a higher class than the regulation gives them.
  • Article 2(2) excludes medical devices, in vitro diagnostics and vehicle type-approval products, so there is no overlap with medical device regulation here.

Every clause above was read in the published text: Directive (EU) 2022/2555, Regulation (EU) 2024/2847, and the IEC and ISA catalogue entries for the 62443 parts. Nothing here is legal advice on whether your entity is in scope.

DOC-800 · Library

Guides

Long-form, primary-sourced and written for people who will have to defend the plan to a process engineer.

FAQ-900 · Questions

Questions operators actually ask

Can you penetration test a SCADA system without stopping production?
Yes, but not with the techniques an IT test uses. Passive traffic capture, architecture and firewall-ruleset review, offline analysis of controller projects and logic, authenticated review of the engineering workstation, and full testing of the internet-facing edge and the IT/OT demilitarised zone all run while the process runs. What cannot run on a live plant is active scanning of the control network, interrogation of PLCs and field devices, exploitation inside the control network, and fuzzing. Those belong in a lab, a replica or a planned shutdown.
Why is active scanning so dangerous on an OT network?
Because control devices are built for a deterministic job with minimal resources, not for arbitrary traffic. NIST SP 800-82r3 tells OT owners to exercise extreme caution with active scanning because scans may cause device instability or interfere with the device process state, potentially impacting safety and integrity. Its own case files record a ping sweep that made a robotic arm swing 180 degrees and another that hung a fabrication system and destroyed 50,000 dollars of wafers.
Does NIS2 require penetration testing of OT?
No. NIS2 Article 21(2) never uses the phrase. It requires policies and procedures to assess the effectiveness of cybersecurity risk-management measures, which makes assessment mandatory but leaves the method to the entity. For most OT estates a proportionate answer is a periodic architecture and configuration assessment plus targeted technical testing where it is safe, rather than an annual live pentest of the control network.
Which part of IEC 62443 applies to me?
It depends on your role. Asset owners work to 62443-2-1 for the security programme, with 62443-2-5 as implementation guidance. Service providers and integrators work to 62443-2-4 and to the 3-x system requirements. Product suppliers work to 62443-4-1 for the development lifecycle and 62443-4-2 for component requirements. 62443-3-2 is the one most operators need first: it partitions the system into zones and conduits and sets a target security level for each.
What is the Purdue model and does it still matter?
It is a layered reference for industrial architecture that came out of the Purdue Enterprise Reference Architecture and became the common language for OT segmentation. It matters for testing because the level an asset sits at determines which technique is defensible against it: enterprise levels take ordinary IT testing, the demilitarised zone is where most productive technical work happens, supervisory systems tolerate authenticated review, and basic control and field instrumentation belong in a lab or an outage. Modern estates with cloud and industrial IoT do not fit it perfectly, which is why NIST offers it as one option alongside ISA-95 levels and the three-tier IIoT architecture.
What can be done if the process can never stop?
A great deal. Roughly two thirds of the findings in a typical OT assessment come from work that never touches a controller: an accurate asset and conduit inventory from passive capture, the difference between the network diagram and the network, credential and account weaknesses on engineering and supervisory hosts, exposed remote access, and logic or configuration flaws found in exported project files. What is lost is the ability to prove exploitability on the real device, and the honest substitute is a replica or a vendor test rig.
Is a safety instrumented system ever in scope?
Not for network testing. The SIS is the layer that puts the plant in a safe state when everything else has failed, and a test that disturbs it removes the protection it exists to provide. TRITON demonstrated that the capacity to disable or inhibit a safe failure has physical consequences. The right treatment is a documented exclusion in the rules of engagement plus a separate review that integrates the cybersecurity lifecycle with the functional-safety lifecycle.
How often should an OT environment be tested?
There is no EU-wide interval for OT. A defensible pattern is continuous passive monitoring, an architecture and configuration assessment on a fixed cycle, edge and remote-access testing whenever the perimeter changes, and deeper active work aligned to the plant turnaround schedule rather than to a calendar year. Tying the intrusive part of the programme to outages that already exist is usually cheaper and always safer than inventing new ones.
Does the Cyber Resilience Act apply to our PLCs?
It applies to the manufacturers of them, from 11 December 2027, with the Article 14 reporting duty for actively exploited vulnerabilities from 11 September 2026. Controllers and HMIs are ordinary products with digital elements rather than Annex III or Annex IV classes, so they are self-assessed. The useful part for an operator is recital 60, which says products intended for industrial settings are often in use far longer than five years and should carry correspondingly longer support periods. That is a procurement clause waiting to be written.
Our OT is managed by the equipment vendor. What changes?
Two things. First, the vendor becomes part of the scope: NIS2 Article 21(2)(d) makes supply-chain security a required measure, and the remote support tunnel is usually the shortest path into the plant. Second, testing has to be agreed with the vendor in advance, because support can be lost if third-party software is installed without their acknowledgement, and because they may be the only party who can restore a controller. Get the notice, the exclusions and the restore responsibilities into writing before the engagement starts.