With physical systems no longer isolated from the digital infrastructure, organisations must adopt new ways of ensuring cybersecurity.
We have witnessed a profound evolution in security over the past few decades, transitioning from the ‘inherently safe’ era of the mainframe to today’s ‘persistently vulnerable’ landscape. Moving from isolated mainframes to distributed client/server models, and then to the web and cloud, we have now arrived in the AI era—where autonomy is the mantra driving business.
Traditionally, OT (operational technology) systems have been air-gapped or isolated. Unlike the digital-only nature of IT, logic executed in an OT environment has a direct, immediate effect on the physical world. Consequently, performance and reliability requirements are significantly more stringent. Because these operations can impact human safety, public health, environmental integrity, and the broader national or global economy, OT must be viewed through a specialised lens of ‘mission criticality’ that prioritises physical safety and uptime over traditional data-centric IT protocols.
As quantum technology matures and IT/OT convergence becomes seamless, we face critical questions: How will the security landscape pivot? What impact will this have on our critical public infrastructure? And how must our mitigation strategies and regulatory frameworks evolve to keep pace? Monitoring how these emerging trends shape our long-term strategies and collective efforts is the next vital ‘watch-out’ area.
Challenges today
Industrial security is undergoing a seismic shift. Attackers have moved beyond the immediate ‘kill switch’—they are now siphoning operational telemetry to build digital twins and training AI models on exfiltrated data to orchestrate future, high-precision attacks.
Also, there is a widespread belief that data is safe if it is isolated within private networks or completely air gapped. On paper, it sounds reassuring. In reality, it creates a false sense of security. Because isolation is not immunity. Even in air-gapped environments, vulnerabilities exist—and they are often introduced through the very mechanisms designed to operate and maintain these systems:
- Human factor risk: Social engineering, credential compromise, or insider threats can bypass even the strongest physical isolation.
- Data movement channels: USB drives, external media, and temporary connections for reporting or analytics become silent attack vectors.
- Supply chain exposure: Compromised software updates or vendor tools can introduce threats into otherwise isolated systems.
- Maintenance backdoors: Temporary network bridges created for troubleshooting or patching often outlive their intended purpose.
- Configuration drift: Over time, exceptions accumulate, and ‘temporary access’ quietly becomes permanent exposure.
The shift from deterministic to probabilistic AI models is creating a significant calculability gap. In traditional systems, outcomes are ‘calculable’ because they follow fixed, binary rules—press a button, and you receive the same outcome every time. AI, however, operates within a spectrum of probabilities. While it may not produce the exact same outcome twice, it must be governed to operate within strictly defined ‘allowable ranges’ of safety and performance. This loss of mathematical certainty creates a gap where risk becomes harder to predict. To mitigate this, we must adopt a multi-model validation strategy and integrate Human-in-the-Loop (HITL) oversight, ensuring that human judgment remains the final anchor when AI approaches the boundaries of those allowable ranges.
Overall, the gap between IT and OT has narrowed significantly. Any compromise in one domain can now move laterally to impact the other, creating a bidirectional risk to the entire enterprise.
Mitigation strategies
Historically, our focus was on preventing physical intrusion through site security. This evolved into securing the network perimeter and, eventually, shifted towards identity as the primary barrier. In today’s AI-driven landscape, Zero Trust has become the essential mantra we all rely on to navigate these complexities.
Today, the attack surface has expanded significantly with the integration of IoT and OT into traditional IT environments. This shift has escalated the potential impact from mere data theft or ransomware to threats against human life, particularly when critical infrastructure—such as power grids, medical equipment, transportation systems, and public utilities—is compromised.
To address this, we need a paradigm shift in awareness. Vigilance can no longer be the responsibility of a few specialists; it must scale to the population level. While awareness/training is essential, we face a persistent hurdle: complacency. Security is often treated as a checkbox for regulation or compliance rather than a core priority. Unfortunately, many organisations only act when they are forced to, rather than adopting a truly proactive, institutionalised security-first mindset.
Given the inherent limitations of legacy protocols like Modbus, security must default to zero trust—continuously verifying every interaction and operating under the assumption of breach. To prevent the unauthorised siphoning of telemetry, every connected asset must be issued a unique digital identity through Public Key Infrastructure (PKI). By assigning each device a cryptographic certificate, we ensure that every communication is authenticated. This makes it possible to verify that a command—such as one sent to a Programmable Logic Controller (PLC)—originates from a verified, authorised source rather than a compromised endpoint or an adversarial ‘digital twin’ attempting to exfiltrate data.
Having explored the challenges and potential mitigation approaches, the next step is to anchor them within a structured framework. The Purdue Model and D5 strategy together provide a practical blueprint for implementing layered, resilient security.
The architectural blueprint
The Purdue Model organises industrial control systems into hierarchical layers, enabling a structured approach to system design, operation, and security. By segmenting the environment into distinct levels, it helps isolate risks, enforce controlled communication between layers, and improve manageability through modular architecture.
Level 0: This is the ‘Ground Truth’ of the ICS (industrial control system) environment. It consists of the physical devices—sensors and actuators—that directly interact with the production environment. While sensors (like thermocouples or pressure transducers) read physical conditions, actuators (like valves, motors, or heaters) perform the physical work based on commands from above.
Level 1: At this level, controllers like PLCs take inputs from sensors and make real-time decisions to control industrial processes. Based on programmed logic, they send commands to actuators—for example, adjusting valves to regulate flow or triggering cooling systems when temperature exceeds a threshold. Communication usually happens over industrial protocols such as Modbus, enabling reliable interaction between field devices and controllers.
Level 2: Supervisory control (SCADA & HMI): This layer transitions from individual machine logic to broad process oversight. SCADA (Supervisory Control and Data Acquisition) systems aggregate data from multiple PLCs to provide a birds-eye view of an entire assembly line or shop floor. While PLCs handle the millisecond-by-millisecond logic, SCADA allows operators to perform high-level monitoring, setpoint adjustments, and system-wide calibrations.
In large-scale plants, this layer is often distributed. Local SCADA nodes may manage specific areas (like chemical processing vs packaging), often dictated by different equipment vendors. These local nodes then feed a master SCADA in a central control room for plant-wide orchestration.
Parallel to this, HMIs (Human-Machine Interfaces) serve as the localised, ‘hardened’ access points. Unlike a central SCADA, an HMI is typically dedicated to a single machine, providing operators with immediate, touch-screen control in rugged environments where a standard computer would fail.
Level 3: This level is responsible for managing and optimising plant operations. It includes systems such as SCADA servers (real-time monitoring and supervisory control), Historians (time-series data storage and trend analysis), and Manufacturing Execution Systems (MES), which manage production workflows, track work orders, enforce quality processes, and monitor performance metrics such as throughput and efficiency on the shop floor. These systems aggregate and contextualise data from Level 1 and Level 2, supporting functions such as production monitoring, process optimisation, and operational decision-making within the plant environment.
The IDMZ (industrial demilitarised zone) acts as a buffer zone between OT (Level 3) and enterprise IT (Level 4). It hosts intermediary systems such as data historians (replicas). Data from the plant network is replicated or forwarded into the IDMZ, where it can be securely accessed by enterprise systems like ERP for reporting and analytics. Communication across this boundary is strictly controlled, often using firewalls, and in some cases unidirectional gateways to enforce one-way data flow.
Level 4: This primary IT domain hosts corporate systems like ERP, CRM, and business intelligence (BI) tools. Level 4 consumes filtered operational data from Level 3 through the IDMZ to synchronise factory output with business demand.
Raw plant data gets aggregated and processed into high-level KPIs, such as OEE (overall equipment effectiveness), cost per unit, supply chain readiness, and inventory turns. Communication flows bi-directionally: Level 4 pushes ‘what to build’ (e.g., production orders) down to the factory, while lower levels report ‘how it was built’ (actual production results).
Level 4 sends not just ‘what to build’ (production orders) but also optimisations—like demand forecasts, recipe tweaks, or scheduling adjustments—down to Level 3. In return, Level 3 reports ‘how it was built’ (actual KPIs and production data) upward through the IDMZ.
Level 5: This level represents connectivity to external systems beyond the enterprise, such as cloud platforms, third-party services, and external partner networks. While not part of the original Purdue Model, it is commonly included in modern architectures to account for increasing integration with Internet-based services. Data exchange at this level typically occurs through APIs, cloud integrations, or secure data transfer mechanisms.
Communication between Level 4 (enterprise IT) and Level 5 is governed by standard IT security controls such as firewalls, API gateways, and secure access mechanisms. These controls ensure that external connectivity does not introduce undue risk to enterprise or operational environments.
While the Purdue Model provides the architectural blueprint for our network, a static map is not enough to stop a modern adversary. To protect this hierarchy, we must layer our security controls through a defense-in-depth (D5) strategy, ensuring that if one layer of the Purdue Model is compromised, four more stand in the way of the physical process.
Defense-in-depth is a layered security strategy where multiple controls are applied across different levels of a system to isolate risks, limit the impact of threats, and provide redundancy in protection.
Deter: The primary goal is to discourage a potential adversary by making the ‘cost’ of an attack—in terms of time, effort, and risk of exposure—exceed the perceived value of the target. We achieve this by projecting a robust security posture. When we publicly or internally demonstrate our strict adherence to the Purdue Model, our use of encrypted communication, and our 24/7 monitoring, we signal to attackers that our environment is a ‘hard target’. This psychological barrier is designed to turn a volunteered attempt into a perceived failed mission before the first packet is ever sent.
Detect: The objective of this phase is to continuously monitor the environment to identify unauthorised communications, anomalous behavior, and potential security events. This is achieved through network and host-level monitoring, log analysis, and alerting mechanisms that can flag deviations from established baselines. A well-maintained asset inventory and device base lining (including firmware versions, configurations, and known vulnerabilities) support effective detection by enabling the identification of abnormal patterns and suspicious activity.
Deny: Beyond simply blocking unauthorised users, this phase ensures that only verified, cryptographically ‘known’ entities can communicate. This is achieved by implementing a Public Key Infrastructure (PKI). By requiring every device—from a Level 4 server to a Level 1 PLC—to present a unique security token (digital certificate), we move beyond simple passwords. This validation of public and private key pairs ensures that a device is truly what it claims to be, effectively denying access to any ‘spoofed’ or rogue hardware that attempts to join the plant network.
Delay: By applying the Purdue Model and enforcing strong network segmentation across layers, this step aims to slow down the lateral movement of threats within the environment. Using zones, conduits, firewalls, and access controls, communication between layers is tightly regulated, ensuring that any potential compromise is contained and prevented from rapidly propagating across the network.
Defend: This is the final safety net. It operates under the principle of ‘assume breach’, ensuring that even if an attacker bypasses the first four D’s, we have a robust resilience plan to neutralise the threat. This involves immediate incident response (IR) triggered by automated playbooks that isolate affected segments—such as a single production cell—to prevent lateral movement. Furthermore, ‘gold standard’ backups of PLC logic and SCADA configurations are maintained, supported by validated runbooks that allow us to restore operations to a known-secure state with minimal downtime.
Overall, a layered Purdue architecture combined with a defense-in-depth (D5) strategy helps significantly reduce risk exposure by enforcing segmentation, controlled communication, and multiple layers of security. By further leveraging AI-driven analytics for threat detection and anomaly identification, organisations can adopt a more proactive approach in identifying potential issues early.
However, to ensure that these controls are consistently implemented, validated, and aligned with industry best practices, it is essential to anchor this approach within established standards and compliance frameworks. These frameworks provide the necessary guidelines, benchmarks, and governance mechanisms to sustain a secure and resilient operational environment.
Standards and compliance
While ISO/IEC 27001 remains the gold standard for Information Security Management Systems (ISMS) and is essential for establishing baseline customer trust, it is primarily IT-centric. For organisations operating in the global market, we must navigate a ‘compliance mosaic’ where regional standards—such as IRAP (Australia), OSPAR (Singapore), and KISA-ISMS (Korea)—act as mandatory gateways for local government and financial sector bids.
In the specialised domains of OT and IoT, general IT standards alone are insufficient due to legacy protocols, safety-critical operations, and long asset lifecycles. We address this by combining NIST SP 800-82 Revision 3, which provides prescriptive guidance on ICS network segmentation, remote access control, continuous monitoring, and incident response, with ISA/IEC 62443.
While NIST provides guidance and best practices for implementing cybersecurity controls, ISA/IEC 62443 establishes a comprehensive, OT-specific framework of security requirements across asset owners, system integrators, and product suppliers. It addresses key aspects such as secure system design, zone-and-conduit segmentation, component-level hardening, and lifecycle risk management.
By aligning with both frameworks, organisations can operationalise critical controls such as network segmentation, least-privilege access, secure remote connectivity, and supplier risk management. This ensures that the OT security posture is not only technically robust, but also enforceable, auditable, and resilient in real-world industrial environments.
To achieve true industrial resilience, we must simultaneously pull three critical levers: continuous awareness, shared accountability that transcends the security silo, and unwavering alignment with global industry guardrails.
The widespread adoption of AI presents a significant opportunity to shift from reactive defence to a proactive security posture—anticipating and addressing threats before they materialise. However, this transition is as much cultural as it is technological. Many organisations remain confined to a reactive, response-driven cycle. True resilience requires institutionalising a security-first mindset, where risk management is embedded into the operating model and reinforced at every decision point across the enterprise.
This cultural ownership must manifest through technical rigour. Closing architectural gaps via a disciplined implementation of the Purdue Enterprise Reference Architecture (PERA) is an immediate priority. When bolstered by the regulatory depth of IEC 62443 and NIST 800-82, this layered defence provides the structural integrity required to secure our critical IT/OT touchpoints.
By ensuring a Human-in-the-Loop approach to critical decision-making and engineering systems with quantum-resilient security principles, we establish a security posture that is not only robust today but sustainable as a long-term strategic advantage.
