The Rising Stakes of Operational Technology Security  

Operational Technology (OT) systems quietly underpin our day to day lives, running energy grids, manufacturing lines, military systems and transportation networks. But these systems have become increasingly connected to IT infrastructure and cloud platforms and their exposure to cyber threats has grown, making breaches more and more commonplace. The consequences of such breaches are severe, given the critical nature of OT environments. And yet, securing these systems is uniquely challenging; traditional testing carries significant risk, as OT environments are highly sensitive and downtime is often unacceptable.  In every sense, the stakes for securing Operational Technology have never been higher.  

Historically, OT environments were air-gapped and built for reliability, not security. Devices like PLCs and SCADA controllers operated in closed networks with proprietary protocols and minimal updates/modifications after deployment. However, the adoption of digital technologies, the need for remote access, and the integration of cloud services have broken down the traditional boundaries that once kept OT systems isolated from IT networks and the wider internet. Today, OT systems face the same threat landscape as IT but with arguably greater consequences. A misconfigured firewall in IT might lead to data loss. In OT, it could halt production or cause a safety incident.  

Unlike IT systems, OT environments prioritise uptime and physical safety. Patching is rarer, downtime is costly, and many devices weren’t designed with security in mind. Protocols like Modbus and DNP3 originally lacked authentication and encryption, making them vulnerable to spoofing and replay attacks. Traditional security tools often fail to parse OT traffic or detect lateral movement across industrial networks. This complexity makes penetration testing in OT environments both delicate and essential, not just to find vulnerabilities, but to understand how an exploit could impact physical systems and business operations without compromising their day-to-day running.  

Stuxnet, discovered in 2010, remains the most iconic example of a targeted OT attack. Widely believed to be a joint cyber operation by the United States and Israel targeting Iran's nuclear program, it specifically exploited vulnerabilities in Siemens Step7 software used in industrial control systems (ICS) at the Natanz uranium enrichment facility. The malware spread via USB drives and infected Windows systems, then altered the programmable logic controllers (PLCs), destroying around 1,000 centrifuges by fluctuating their speeds while masking the changes from operators. Stuxnet highlighted the risks of air-gapped networks and marked a milestone in state-sponsored cyber warfare against critical infrastructure, redefining the threat model for industrial control systems and initiating a wave of ICS-focused malware.  

Since the Stuxnet attack, the ICS threat landscape has evolved rapidly. Nation-state actors have demonstrated their intent and capability through campaigns like Industroyer (used in the 2016 Ukraine grid attack, causing widespread blackouts) and TRITON (which in 2017, was the first known use of malware specifically designed to target industrial safety systems).  

Ransomware groups have also increasingly leveraged the critical nature of OT, as highlighted by the 2017 WannaCry outbreak – an OT adjacent attack (exploiting the EternalBlue vulnerability in Microsoft Windows OS) which affected healthcare, logistics and manufacturing sectors, many of which had OT systems running unpatched, legacy software.  

In 2021, Colonial Pipeline suffered a ransomware attack attributed to the group ‘Darkside’ causing widespread fuel shortages, prompting the then US President to declare a state of emergency. More recently, in September 2025, a ransomware campaign targeted Collins Aerospace, disrupting check-in and boarding systems at airports including Heathrow, Brussels and Berlin. The cascading impact demonstrated how third-party vulnerabilities can paralyse critical infrastructure. 

In response, regulatory bodies like CISA and NCSC have issued directives that mandate OT risk assessments, segmentation and detection capabilities. But building a mature OT security program requires more than firewalls, rudimentary segmentation and EDR. It demands operational resilience, through segmented networks with strict access controls, adopting a zero-trust approach to every user/device/request, deploying protocol-aware detection tools, and aligning detection logic to frameworks like MITRE ATT&CK for ICS.  

Documentation and governance play a critical role. Each detection rule should include a clear goal, technical context, known blind spots, and response actions. Using structured formats like YAML and syncing to centralised knowledge bases ensures that detection logic is transparent, auditable, and maintainable.  

Regular penetration testing is also vital in maintaining a robust security posture, identifying exploitable vulnerabilities, misconfigurations, and attack chains before adversaries can strike. Preventing down-time and ensuring the careful handling of sensitive systems during testing must be prioritised, so it is essential for testers to have specialist experience. Often this will entail testing in UAT phases, or two-phase testing where vulnerabilities are identified in a test/dev environment and then applied in a speculative or controlled manner to the live environment. Thus, any live testing is conducted with the relevant level of caution and preparation to ensure there are no inadvertent effects from the engagement. 

Ultimately, OT provides a direct vehicle to translate virtual entities into reality changing, physically tangible effects. As attackers evolve and OT environments become ‘easier’ targets than their IT counterparts, organisations must shift from reactive defence to proactive assurance. That means recognising the implications of a breach, improving segmentation, authentication and detection processes, and simulating attacks authentically but safely.   

Next
Next

Another Kind of Technical Debt