OT and SCADA systems are engineered for availability and safety first, not for aggressive scanning or frequent change. A standard penetration test method can unintentionally cause production downtime, process instability, nuisance trips, or unsafe physical states. An IT penetration testing engagement scope against a corporate network has different consequences when things go wrong than the same aggressive scanning against a PLC network controlling a water treatment plant, an electricity substation, or a manufacturing production line.
For AU critical infrastructure operators, this is not a theoretical concern. According to ICS-CERT advisories, documented OT incidents have occurred when security teams used IT-focused tools that overwhelmed industrial device network stacks or triggered unexpected behaviour in embedded systems. The testing methodology for OT environments must be scoped differently, approved differently, and executed with stop conditions that any team member can trigger if the testing causes unexpected operational effects.
IT vs OT: Why the Primary Risk Is Different
In IT penetration testing, the primary risk being tested is confidentiality and data integrity: can an attacker read, modify, or exfiltrate data? The consequence of a successful test-triggered incident is typically a service disruption that can be recovered by rebooting a server or rolling back a configuration.
In operational technology environments, the primary risks are not data loss. They are production downtime, equipment damage, and human safety. A misconfigured PLC can produce a hazardous physical state. A disrupted SCADA network can interrupt a process that cannot be safely paused mid-cycle. These consequences cannot be recovered by rebooting. For energy, water, manufacturing, and transport operators in Australia, the testing scope is defined by those physical consequences, not by the data classification of the network being tested.
The IT/OT Boundary: Where Most Attacks Enter
The Purdue Reference Model describes the five functional levels of an ICS environment, from field devices at Level 0 through plant supervisory systems at Level 3 up to the enterprise IT/OT boundary at Levels 3.5 to 4. The IT/OT convergence boundary has become the most active attack surface as facilities adopt remote monitoring, cloud-connected historians, and vendor-managed platforms.
As IT and OT systems converge, connectivity grows alongside risk. Most OT systems were designed decades ago with no security in mind. Connecting them to modern IT infrastructure and the internet has exposed that gap.
The IT/OT boundary is where a compromised enterprise laptop, a vendor VPN connection with over-broad access, or a cloud historian with misconfigured authentication creates a path into the OT network. Testing the IT/OT boundary does not require active exploitation of PLCs or SCADA servers. It requires validating whether the segmentation controls between enterprise IT and OT Level 3 actually work as documented.
Passive-First Testing Architecture
Passive reconnaissance usually comes first in an OT engagement. Next comes an architecture and segmentation review checked against a recognised model such as the zones and conduits approach in the ISA/IEC 62443 series of industrial cybersecurity standards. Active exploitation, where it happens at all, tends to be reserved for staging environments or specific, pre-approved low-risk targets rather than live production equipment.
For how this systematic testing approach connects to the evidence framework that AU critical infrastructure risk management programmes require, the guide to penetration testing checklist for Australian businesses covers the scoping and rules-of-engagement requirements that apply to any critical testing engagement, including the stop conditions and exclusion documentation that SOCI Act operators should implement.
Your Last Pentest Is Already Out of Date
Every week you ship without continuous testing is a week a vulnerability goes unseen. See what Capture The Bug finds in your first engagement.
IoT vs OT vs IIoT: The Three Layers AU Operators Test
IoT refers to connected devices broadly: building management systems, HVAC controls, badge readers, IP cameras, smart meters, and any networked device that was not traditionally considered part of the IT environment. As of March 4, 2026, mandatory IoT security standards took effect for smart devices supplied to AU critical infrastructure operators under the Cyber Security Act 2024. This makes IoT device security assessment a new mandatory obligation for AU critical infrastructure operators, not a discretionary security practice.
OT refers specifically to the systems that control physical processes: SCADA, Distributed Control Systems (DCS), and Programmable Logic Controllers (PLCs) used in energy, water, manufacturing, and transport. IIoT (Industrial IoT) overlaps with OT when sensors, actuators, and data collection devices are integrated into industrial control systems.
Connected Devices
Focuses on firmware security, authentication hardening, default credential exposure, and secure update mechanisms across building management, smart meters, and sensors.
Physical Control
Focuses on network segmentation, remote access pathways, industrial protocol security (Modbus, DNP3, EtherNet/IP), and configuration hardening of PLCs and SCADA servers.
Convergence Zone
Focuses on DMZ segmentation controls, historian security, vendor jump hosts, and external access paths between enterprise IT and Level 3 operations.
SOCI Act and CIRMP Obligations for Australian Operators
The SOCI Act requires Australian critical infrastructure operators to implement cyber risk management programs and report significant cyber incidents within strict timeframes. The Enhanced CIRMP Rules registered in June 2026 replace principles-based expectations with more prescriptive requirements for how cyber risk is identified, assessed, and managed.
Security testing of OT and IoT environments is expected as CIRMP evidence. The testing report must document scope, methodology, stop conditions, findings at the IT/OT boundary, and remediation actions. This evidence supports the quarterly cyber-risk updates that SOCI Act-regulated directors must receive.
For how OT penetration testing findings connect to the broader compliance evidence programme and what regulators check, the guide to what happens after a penetration test covers the remediation and retest evidence that the CIRMP programme requires to confirm findings are closed.
Book a scoping consultation with Capture The Bug to design an OT penetration testing programme that satisfies your SOCI Act CIRMP obligations without disrupting production operations.
Plan Your Annual Pentesting Strategy the Right Way
Learn how modern SaaS companies structure pentesting across the year to reduce risk, stay compliant, and avoid last-minute panic before audits.
Frequently Asked Questions
Can you penetration test a SCADA system without disrupting production?
With the right methodology, yes. The key is a passive-first approach: begin with documentation review, architecture assessment, passive network discovery, and segmentation validation before any active testing touches OT systems. Active exploitation, where it occurs at all, should be reserved for staging environments or pre-approved low-risk targets rather than live production equipment. Agreed stop conditions should be in place before testing begins, and operations staff should be available during the engagement to pause testing if unexpected effects occur. Traditional IT penetration testing tools and methods should never be applied to live OT environments without OT-specific scoping and approval.
What is the difference between IT and OT penetration testing?
IT penetration testing prioritises confidentiality and data integrity. The consequence of a test-triggered incident is typically a recoverable service disruption. OT penetration testing must prioritise availability and physical safety. The primary risks in OT are production downtime, equipment damage, and human safety. These consequences cannot be recovered by rebooting. In OT environments, aggressive scanning and standard exploitation techniques can cause PLCs to behave unpredictably, disrupt process control loops, or create hazardous physical states. The methodology, tooling, and approval process for OT testing is fundamentally different from IT testing.
What does the SOCI Act require for penetration testing of critical infrastructure in Australia?
The SOCI Act requires critical infrastructure operators to implement a Critical Infrastructure Risk Management Program (CIRMP) covering cyber, physical, supply chain, and personnel risks. Security testing of OT and IoT environments is expected as part of the CIRMP evidence. The Enhanced CIRMP Rules (June 2026) replace principles-based expectations with more prescriptive cyber risk identification and assessment requirements. Testing evidence must document scope, methodology, stop conditions, findings, and remediation. Directors must approve the CIRMP and receive quarterly cyber-risk updates that include testing evidence.
What is the Purdue model and why does it matter for OT security testing?
The Purdue Reference Model describes the five functional levels of an ICS environment, from field devices at Level 0 through plant supervisory systems at Level 3 up to the enterprise IT/OT boundary at Level 3.5 to 4. The IT/OT convergence boundary is the most active attack surface as facilities adopt remote monitoring and cloud-connected historians. OT penetration testing typically focuses on the IT/OT boundary, validating whether segmentation controls between enterprise IT and OT networks actually work, rather than actively exploiting PLC or SCADA equipment.
How is IoT penetration testing different from OT penetration testing?
IoT penetration testing focuses on connected devices: building management systems, smart meters, HVAC controls, IP cameras, and networked devices that were not traditionally part of IT. Testing covers firmware security, authentication hardening, default credential exposure, and update mechanisms. OT penetration testing focuses on the systems controlling physical processes: SCADA, DCS, and PLC networks. As of March 2026, mandatory IoT security standards took effect for smart devices supplied to AU critical infrastructure operators under the Cyber Security Act 2024, making IoT device security assessment a new mandatory obligation for Australian critical infrastructure operators.
