OT Security is Where IT Security Was in 2008 — And It Cannot Afford the Same Mistakes

The Operational Technology sector is replaying the IT security playbook of the 2000s, but its infrastructure cannot afford a breach-and-recover cycle.

The industry narrative is both seductive and dangerous: deploy SIEM, bolt on OT-specific rules to YARA and Sigma, train operators to recognise MITRE ATT&CK techniques, call it convergence, declare victory. This approach worked — or seemed to — for IT networks because IT assets depreciate, are fungible, and tolerate downtime measured in hours. Operational Technology does not. When a petrochemical cracker, a water treatment facility, or a transmission substation fails, the consequences are measured in human injury, environmental contamination, and cascading economic loss. The 2024 Synnovis ransomware incident disrupted NHS pathology services across London for months; the 2023 Change Healthcare compromise paralysed insurance claim processing across North America; the 2021 Oldsmar, Florida water utility breach nearly poisoned a municipal water supply. These were not data exfiltration events remedied by credit monitoring. They were production halts with third-order harms that regulation could not have prevented, only architecturally resilient infrastructure could have mitigated.

The OT security industry is now at the exact inflection point where IT security stood in 2006–2008. It recognises the threat. It has begun to build sensors. It has adopted frameworks — NIST Cybersecurity Framework, IEC 62443, NERC CIP, DORA, NIS2 — and these frameworks are not useless, but they are insufficient. They prescribe what to measure and what to report; they do not prescribe how to survive. The sector is about to discover, as IT learned painfully after Stuxnet and as financial services learned after the FCA's SM&CR regime exposed it, that you cannot detect your way to safety.

The Current OT Security Model: Sensors Without Structure

The standard OT security posture today mimics the IT stack of fifteen years ago. An organisation installs edge sensors at the boundary between IT and OT networks — products like Fortinet FortiGate, Cisco ASA, Schneider Electric EcoStruxure — and forwards telemetry to a SIEM (Splunk, LogRhythm, Exabeam, or open-source Stack) where rules attempt to spot anomalous activity. If an IDS/IPS (Suricata, Zeek, or vendor-embedded variants) detects a deviation from a learned baseline, an alert fires. An operator, increasingly overloaded, investigates. If the investigation confirms attack, the organisation notifies CISA, engages incident response, and enters a forensics cycle. This architecture was explicitly discredited in IT after the SolarWinds supply-chain compromise (December 2020), yet it persists in OT because OT assets cannot be rapidly patched, cannot be segmented easily, and in many cases cannot be monitored without introducing latency that breaks production.

The technical specificity of modern OT threats makes the generic SIEM approach structurally inadequate. The 2023 MOVEit File Transfer zero-day (CVE-2023-34362) compromised dozens of critical infrastructure operators because it chained together weakness in the IT/OT boundary — a single web-facing file transfer appliance running unpatched code. By the time an IDS signature was written and deployed to OT networks, the initial access was hours old. The 2024 Scattered Spider campaign that targeted MGM Resorts and Caesars Entertainment demonstrated that OT-adjacent systems (property management, reservation, accounting) were the initial foothold; lateral movement to OT was prevented only by manual network segmentation, not by detection. Neither organisation had pre-built resistance to the attack chain; both relied on rapid human response once the attack had achieved meaningful access.

The regulatory pressure compounds the architectural problem. The Financial Conduct Authority's 2023 guidance on cyber resilience (FCA PS23/3) and the proposed DORA (Digital Operational Resilience Act, now in effect across the EU) explicitly require demonstrating resistance to operational disruption, not merely the ability to report it after the fact. The SEC's 4-day cybersecurity incident disclosure rule (effective 2023) forces public companies to disclose material breaches within 96 hours, which means OT operators must now assume they are being watched and must be prepared to validate their breach-response timeline. APRA CPS 234 (Australia) and the NYDFS Part 500 (New York) similarly require board-level incident response plans and auditable recovery architectures. The regulatory regime has shifted the question from "Can you detect intrusion?" to "Can you continue operating through it?" The answer, today, is almost never.

The Structural Failure: Detection Is Post-Breach Diagnosis

The fatal flaw in the detection-and-response model, whether applied to IT in 2008 or to OT in 2025, is that it assumes breach is inevitable and optimises for speed of response rather than elimination of exploitability. A SIEM-centric architecture says: "We will allow the attacker to enter, traverse the network, exfiltrate data or encrypt it, because we have invested in the sensors to catch them doing it." This posture was already compromised in IT networks when breaches became measured in months of dwell time (the Mandiant average was 356 days as of 2023); it is catastrophic in OT, where dwell time of even hours can result in irreversible physical damage.

Consider the architectural failure modes exposed by the Synnovis incident (July 2024). The NHS pathology provider was running Windows domain-joined servers, standard backup practices (immutable snapshots held in the same network), and a network perimeter with traditional firewall and VPN rules. An attacker gained initial access through a credentials-stuffing attack against a web-facing identity management portal. From there, the attacker conducted lateral movement via SMB and WMI (Windows Management Instrumentation), located and encrypted the backup infrastructure, and forced the organisation into a complete rebuild. The company was, by legacy standards, defended: it had IDS/IPS, it had EDR (endpoint detection and response), it had a SIEM. Yet all of that telemetry was forensically useful only after the fact. The architecture permitted the attack because it was designed to permit normal lateral movement and trusted the network fabric to be honest.

OT systems are more brittle. When you add industrial control systems — PLCs (programmable logic controllers), RTUs (remote terminal units), HMIs (human-machine interfaces) — the problem amplifies. These devices were designed for availability and determinism, not for zero-trust architecture. A PLC running a hardened microkernel (Beckhoff TwinCAT, Siemens STEP 7) cannot tolerate the latency overhead of per-packet inspection and cryptographic validation. An RTU communicating over Modbus TCP or Profibus DP does not have the computational budget to implement mutual authentication on every message exchange. So the industry has, reasonably, isolated these devices on air-gapped networks or on tightly segmented VLANs. But air-gapped networks have never been truly air-gapped — there is always a jump host, a remote access tunnel for vendors, a maintenance laptop with a USB drive. And VLAN segmentation, as every incident response team has discovered, is a soft boundary that depends entirely on switch configuration discipline and static ACLs that are rarely audited.

The Oldsmar water utility breach (February 2021) made this explicit. An attacker exploited a legacy HMI (Human Machine Interface) running Windows XP that was exposed to the internet via TeamViewer. He or she entered the network, accessed the SCADA system, and manually adjusted chemical dosing parameters — a capability that required no privilege escalation, no malware, no dwell time. The response was to patch TeamViewer, enable MFA, and install intrusion detection on the IT/OT boundary. But the real failure was architectural: the HMI was directly accessible from the internet, the SCADA protocol (in this case, Kepware) was running unencrypted on the same network, and there was no substrate-level resilience to manual parameter manipulation.

The PULSE Doctrine: Zero-Knowledge Substrate

The reframing required by modern OT security is not about adding more sensors, it is about eliminating the conditions under which sensors would be needed. This is the principle of zero-knowledge substrate: you cannot steal what is not there.

In practical terms, this means designing OT infrastructure so that no single point of compromise — whether it is a stolen credential, a kernel vulnerability, or a supply-chain-compromised firmware update — grants access to the production control plane. This requires architectural separation that is not merely network-based (VLANs, firewalls) but cryptographic and computational.

One implementation pattern is explicit control-plane / data-plane / observability-plane separation. The data plane — the physical devices and their local state (PLC memory, sensor values, actuator positions) — is designed to be inherently safe. A PLC running a deterministic control algorithm does not check its own permissions; it executes its program. But access to alter that program, or to inject live parameters into it, is guarded by a separate control plane that is not running on the PLC itself. This control plane might be a physically isolated device, a hardware security module (HSM), or a cryptographic validator that enforces policy at the boundary. The observability plane — the sensors, logs, and metrics — is explicitly divorced from the control and data planes, so that compromise of the telemetry layer does not compromise the ability to operate safely.

This architecture makes lateral movement unproductive. An attacker who gains shell access to an HMI cannot use that access to reprogramme a PLC, because the reprogramming interface is not mediated through that HMI; it is mediated through a separate, air-gapped, HSM-backed channel that requires cryptographic proof of authorisation. An attacker who steals a service account credential cannot use it to alter SCADA parameters, because the SCADA interface does not validate identity; it validates cryptographic proof of intent signed by an out-of-band device.

The second principle is adaptive active defence — the continuous, automated adjustment of attack surface in response to adversarial drift. Rather than assuming a static "secure configuration" and detecting deviations from it, the infrastructure continuously shifts its posture. This might mean cryptographic key rotation on a schedule measured in hours rather than months; it might mean randomisation of internal routing, so that the attacker's mental map of the network topology becomes obsolete; it might mean deliberate honeypots and canaries on the data plane that are designed to appear exploitable but trigger immediate segmentation and re-keying if touched. The goal is not to prevent the first probe, but to make the second probe fail because the infrastructure has already adapted.

The third principle is domain-specific automation engineered into the substrate, not bolted on via SIEM/SOAR. Rather than writing thousands of Sigma rules to detect C&C beaconing, lateral movement, and data exfiltration, you design the infrastructure so that command and control is impossible — because all outbound connections from the OT network are mediated through a proxy that validates that the connection is from an authorised management interface, and all inbound connections are denied by default. Rather than trying to detect lateral movement via SMB or SSH, you design the infrastructure so that lateral movement is impossible — because devices do not run SMB or SSH; they run only the protocols necessary for their domain (Modbus, Profibus, OPC-UA), and those protocols are encapsulated in cryptographic tunnels that require out-of-band authorisation to traverse.

Regulatory Alignment and Architectural Resilience

The emerging regulatory regime — DORA, NIS2, APRA CPS 234 — is, implicitly, demanding zero-knowledge substrate design. The FCA's guidance on "cryptographic agility" and "resilience testing" is asking organisations to prove, not through simulation or tabletop exercise, but through continuous operational demonstration, that their infrastructure can survive cryptographic compromise (key theft, algorithm weakening) and continue to operate safely. This cannot be done with a SIEM-centric architecture. It requires infrastructure that is designed to be intrinsically resistant to the most probable attacks.

The SEC's 4-day disclosure rule is creating an additional pressure: if you must disclose within 96 hours, and your investigation has traditionally taken 14 days, you are forced to adopt a posture where response is automated and does not require forensics. This is the true regulatory signal. Organisations that have invested heavily in incident response workflows, forensics capabilities, and breach-response insurance are actually being asked to make those investments unnecessary by building resistant infrastructure instead.

The Path Forward: Architecture Over Tooling

For OT operators reading this, the implications are straightforward. The playbook of the 2000s — segment the network, install detection sensors, hire an SOC, wait for the incident, respond quickly — is now deprecated. It cannot accommodate the latency and risk profile of critical infrastructure. The new playbook requires:

Cryptographic identity for every control transaction. Not every connection, but every command or configuration change should require cryptographic proof of authorisation. This can be done with minimal latency by using local, pre-distributed keys and cryptographic validators, not by requiring online PKI lookups.

Substrate-level isolation of safe-state defaults. If a control device is compromised, it should default to a known-safe state (e.g., halting operation, closing isolation valves, reducing process parameters to safe levels) rather than continuing to execute attacker-supplied instructions.

Continuous cryptographic refresh and posture mutation. Rather than assuming a configuration is static, rotate keys, re-key segments, and deliberately shift threat surface on a schedule measured in hours. This is operationally difficult but technically necessary.

Observability that is orthogonal to control. Your logs, your metrics, your alerts should be cryptographically separated from the systems they observe. Compromise of your SIEM should not compromise your ability to operate safely.

These principles are not novel — they are derived from military and aerospace practice, where operational resilience has been non-negotiable for decades. They are also not cheap, and they are not easy. They require rearchitecting systems that were designed under different threat models. But the regulatory regime, and the increasingly sophisticated state and non-state actors targeting OT, have made incremental improvement around the margins obsolete. OT security is at the inflection point where IT security was in 2006. It has a choice: replicate the expensive, breach-and-recover cycle that IT endured, or adopt the structural approach that only the most mature and well-resourced organisations have implemented.

---

Qualified operators managing critical infrastructure or undergoing DORA/NIS2 compliance assessment should request a technical briefing under executed mutual NDA at [contact mechanism per PULSE protocol]; this article sketches principles that require domain-specific instantiation.