OT/ICS Security vs IT Security: The Core Differences

CIA becomes SIA: the priority inversion

IT security is built around the CIA triad: confidentiality first, integrity second, availability third. A breached database is treated as more urgent than a slow server. OT security inverts that stack entirely. In an industrial environment the working order is Safety, then Integrity, then Availability, with confidentiality trailing far behind.

This is not a stylistic preference. A stopped production line, a tripped safety interlock, or a mis-signalled valve has physical and human consequences that a leaked configuration file never will. Every architectural decision downstream of this inversion changes. It is why an IT-shaped vulnerability scan can crash a PLC, why aggressive isolation of a compromised host can be more dangerous than the compromise itself, and why an OT security control that cannot explain its safety impact should not be deployed at all.

• IT priority order: Confidentiality, Integrity, Availability
• OT priority order: Safety, Integrity, Availability
• In OT, an action that protects data can endanger people or equipment
• Security controls in OT are evaluated against process risk, not just cyber risk

Asset longevity and the impossibility of patching

IT infrastructure typically refreshes every three to five years. OT assets routinely run for fifteen, twenty, or thirty years without replacement. A control system commissioned in the 1990s may still be governing a critical process today, running an operating system with no vendor support and firmware that predates modern authentication standards.

In IT, patching is the default response to a known vulnerability. In OT, patching a PLC or RTU often requires a full plant shutdown, vendor validation, safety recertification, and a maintenance window that may not arrive for months. Vulnerabilities in OT frequently remain unpatched for the operational life of the asset, and that is not a failure of the security programme, it is the operating reality.

OT security compensates through layered, compensating controls rather than remediation speed: network segmentation, protocol-aware filtering, strict access control, and continuous behavioural monitoring that can detect misuse of a vulnerable asset even when the vulnerability itself cannot be closed.

Deterministic networks and why active scanning breaks things

IT networks are built to absorb noise. Retransmits, unexpected packets, and probing traffic are tolerated because endpoints have spare capacity and software stacks designed for resilience. OT networks are deterministic by design. Devices expect a narrow, predictable set of message types at predictable intervals, and many embedded controllers have no spare CPU cycles or memory to process anything outside that pattern.

Active vulnerability scanning, the routine IT practice of sending crafted or malformed packets to see how a device responds, is one of the most common causes of unplanned OT downtime when IT-style tools are pointed at a plant network. A scan that is harmless against a server can freeze a PLC, corrupt a control loop, or trigger a false safety trip.

Passive discovery and protocol parsing

Because active probing is unsafe, OT-native security depends on passive discovery: listening to the network traffic that already exists, without injecting anything new. Done well, this reveals asset inventory, communication patterns, firmware versions, and behavioural baselines without touching a single device directly.

Passive discovery is only as good as the protocol intelligence behind it. OT networks carry Modbus, DNP3, OPC UA, Siemens S7, EtherNet/IP, IEC 61850, and a long tail of vendor-proprietary variants, most of which were designed decades ago for closed, trusted networks with authentication as an afterthought or entirely absent. Understanding a raw packet capture is not enough; the platform must parse function codes, object models, and device semantics to know that a specific message sequence represents a firmware download, a setpoint change, or a breaker command rather than routine polling.

• Modbus: function-code level parsing to distinguish reads from writes to coils and registers
• DNP3: object and variation parsing for utility and substation traffic
• OPC UA: session and node-level visibility across IT/OT data exchange points
• Siemens S7: recognition of engineering-station commands versus routine polling
• EtherNet/IP and CIP: object-level parsing across manufacturing cell traffic
• IEC 61850 (GOOSE, MMS): substation automation traffic parsed for protection-relay context

The Purdue model versus cloud-era flattening

The Purdue Enterprise Reference Architecture has shaped OT network design for a generation, organising the plant into discrete levels from field devices at Level 0 up through supervisory control, site operations, and eventually the enterprise IT network. Its value was clear separation: traffic and trust did not cross levels casually.

That model is under real pressure. Cloud-connected historians, remote vendor access for predictive maintenance, IIoT sensors reporting directly to SaaS platforms, and unified dashboards for plant leadership have all punched holes through the levels the Purdue model assumed were closed. The architecture still describes how a plant should be segmented; it no longer describes how most plants actually communicate.

Security architecture has to deal with the plant as it is, not as the diagram says it should be. That means mapping every path that crosses a Purdue boundary, whether sanctioned or shadow, and applying monitoring and policy at each one rather than assuming the boundary still holds.

IT/OT convergence risk

Convergence is happening whether or not a security programme has approved it. Shared Active Directory domains, common remote access tooling, IT-managed switches carrying OT VLANs, and vendors who patch both networks from the same jump host are now common. Each of these is a legitimate business efficiency and a legitimate lateral movement path from a compromised IT endpoint into a safety-critical process.

The 2015 and 2016 attacks on Ukrainian power distribution, and the more recent pattern of ransomware crossing from corporate IT into manufacturing OT and forcing plant shutdowns, both followed this path: initial compromise in IT, lateral movement across a convergence point, impact in OT. Convergence itself is not the problem. Unmonitored, unsegmented convergence is.

Why traditional EDR and XDR fail in OT

Endpoint detection and response assumes an agent can run on the endpoint. Most OT devices, PLCs, RTUs, protection relays, and human-machine interfaces running locked-down embedded operating systems, cannot host an agent, do not have spare compute for one, and may void vendor warranty or safety certification if a foreign process is installed.

Even where an OT-adjacent server can technically run an agent, the response actions that EDR and XDR platforms take by default, killing a process, quarantining a host, blocking a network segment, are built for IT recovery assumptions. Quarantining an engineering workstation mid-shift, or isolating a historian server that a safety system depends on for state, can create the exact outage or hazard the security tool was meant to prevent.

• Most field devices cannot run any agent at all
• Default EDR actions (kill process, isolate host) are unsafe on process-critical systems
• OT platforms must detect and reason without assuming endpoint control
• Detection logic has to understand process context, not just file and process behaviour

Safety-first response: no automatic isolation

In IT incident response, automatic containment, isolate now, investigate after, is often correct because the cost of a false positive is a temporary loss of a non-critical system. In OT, that same instinct can be the incident. Isolating a controller can drop a safety interlock. Cutting network access to a historian can blind an operator monitoring a live process. Automated response in OT has to be treated as a last resort, not a default.

Mature OT security programmes require human sign-off from operations, engineering, and safety before any containment action touches a live asset class, with pre-approved playbooks for the narrow set of scenarios where speed genuinely outweighs risk. The security platform's job is to detect fast, present clear evidence, and recommend action, not to act unilaterally on a production asset it does not have full physical context for.

Regulatory context: IEC 62443, NIST SP 800-82, and sector rules

OT security does not operate in a regulatory vacuum, and the frameworks are distinct from mainstream IT compliance. IEC 62443 defines security requirements and maturity levels across the industrial automation and control system lifecycle, from component vendors through system integrators to asset owners. NIST SP 800-82 provides US-government guidance specifically for industrial control system security, addressing the constraints, such as availability and safety priority, that generic NIST frameworks do not.

On top of these horizontal standards sit sector-specific requirements: NERC CIP for the North American bulk electric system, TSA security directives for pipelines, and increasingly detailed expectations from national regulators for water, healthcare, and manufacturing infrastructure. A security programme that is only mapped to a general IT framework will have real gaps against what an OT auditor or regulator expects to see.

• IEC 62443: lifecycle security requirements across IACS components, integrators, and operators
• NIST SP 800-82: ICS-specific guidance built around availability and safety constraints
• NERC CIP: mandatory reliability standards for the bulk electric system
• Sector directives: pipeline, water, and healthcare regulators increasingly issue OT-specific rules

Autonomous detection and passive anomaly reasoning

Given the constraints above, no static rule set. The volume of protocol variants, the slow pace of legacy patching, and the impossibility of active testing mean that OT security has to lean on continuous, passive anomaly reasoning: building a behavioural baseline of what normal process communication looks like and flagging genuine deviation, rather than waiting for a signature match against a known exploit.

This is where autonomous detection earns its keep in OT more than almost anywhere else. A model that understands typical polling cadence, typical command sequences, and typical asset relationships can flag an anomalous engineering-station write to a safety controller within seconds, long before that anomaly could be confirmed through manual log review. The reasoning has to run passively, has to be explainable to an operations team without a security background, and has to be conservative about triggering action rather than detection.

How Spharaka Signal is architected for OT/ICS

Spharaka Signal is the OT/ICS extension of the Sphere platform, built from the ground up around the constraints described in this article rather than retrofitted from an IT product. Discovery is passive by default, using deep protocol parsing across Modbus, DNP3, OPC UA, S7, EtherNet/IP, and IEC 61850 to build asset inventory and behavioural baselines without sending a single unsolicited packet to a live controller.

Detection reasoning runs continuously against that baseline, correlating OT anomalies with IT-side signals through the same AuraXP fabric that powers the rest of the Spharaka platform, so an attack path that starts in a phishing email and ends at a PLC is visible as one story, not two disconnected alerts. Response actions on OT assets are governed by AirWatch, the same governance envelope used across Spharaka, which enforces that any containment action touching a safety-relevant asset requires explicit operator or engineering sign-off before it executes. Nothing is quarantined, blocked, or restarted on a production controller without a human in the loop who understands the process, and every recommendation the platform makes states its evidence and its process impact in plain language.

The result is a platform that treats OT as a first-class environment with its own rules, not an IT network with unusual devices attached to it.