Manufacturing Cybersecurity: Securing OT and ICS Systems from IT Threats

A ransomware infection that locks a finance workstation is an inconvenience. A ransomware infection that reaches a programmable logic controller running a stamping press is a safety incident waiting to happen. That distinction is the entire reason operational technology (OT) and industrial control system (ICS) security cannot simply borrow the IT security playbook and apply it to the plant floor. The assets are different, the failure modes are different, and the tolerance for downtime is different, because in manufacturing, downtime is not just a cost center problem, it is a physical safety problem.

Over the last decade, manufacturers have connected machines that were designed in an era when the only network they expected to see was a serial cable to a local operator panel. Now those same machines sit on networks that touch ERP systems, remote vendor access, and in some cases the public internet. This article walks through why OT security requires its own strategy: the reality of legacy programmable logic controllers (PLCs) that were never built for patching, the risks introduced by IT/OT network convergence, the Purdue Model as a segmentation framework, and what incident response looks like when a production line, not just a database, is on the line.

Table of Contents

• Why OT Security Is a Different Discipline Than IT Security
• The Legacy PLC Problem: Systems That Were Never Meant to Be Patched
• IT/OT Convergence: How Connectivity Created a New Attack Surface
• The Purdue Model: A Practical Framework for Network Segmentation
• Building Defense in Depth Across the Plant Floor
• Incident Response When Downtime Has Physical Safety Implications
• Governance, Compliance, and the Human Factor
• Where Manufacturers Should Start

Key Takeaways

• Many industrial PLCs and HMIs in active production today run firmware and operating systems that are 10 to 20 years old and were never designed to receive security patches without a full requalification cycle.
• IT/OT convergence, typically driven by remote monitoring, predictive maintenance, and vendor support access, is commonly the single biggest driver of new OT attack surface in manufacturing environments.
• The Purdue Model, organized into levels 0 through 5, remains the most widely referenced framework for segmenting OT and IT networks and is the basis for most modern zone-and-conduit security architectures.
• OT incident response plans must define safety-first shutdown procedures separately from IT containment procedures, because isolating a compromised system on a production line can itself trigger a hazardous condition if done incorrectly.

Why OT Security Is a Different Discipline Than IT Security

IT security is built around a well-understood priority order: confidentiality first, then integrity, then availability. OT security typically inverts that order entirely. On a production line, availability and safety come first, because an unplanned stoppage can strand work in progress, damage equipment, or in the worst case put an operator at risk if a machine halts mid-cycle in an unsafe state. Confidentiality of, say, a PLC's ladder logic is a distant third concern compared to keeping a press, a conveyor, or a chemical reactor running within its designed parameters.

This is why security controls that are routine in IT, such as automatically pushing patches overnight or running active vulnerability scans against live systems, are frequently inappropriate in OT. An active scan that would be background noise on a corporate network can crash a fragile PLC or a decades-old human-machine interface (HMI). Manufacturers that try to apply IT tooling to OT without adapting the approach commonly discover this the hard way, usually during a scheduled maintenance window that turns into an unplanned one.

The Legacy PLC Problem: Systems That Were Never Meant to Be Patched

Walk the floor of almost any established manufacturing facility and you will find controllers that predate the security conversation entirely. In our experience, it is common to find PLCs, drives, and HMIs still in service that were installed 15 or more years ago, running proprietary or embedded operating systems that vendors stopped supporting years ago. These devices were engineered for deterministic, real-time control, not for resisting network-based attacks.

Patching a PLC is not like patching a laptop. A firmware update on a controller tied to a safety-instrumented system typically requires revalidation of the entire control logic, a scheduled production stoppage, and sign-off from process engineering, quality, and often a regulatory body. That process can take weeks to plan and cost far more in lost production time than the vulnerability itself would cost if left unpatched and instead mitigated through compensating controls. This is precisely why compensating controls, network segmentation, monitoring, and strict access control, matter more in OT than the patch-everything mindset that dominates IT.

IT/OT Convergence: How Connectivity Created a New Attack Surface

Ten years ago, most industrial networks were air-gapped by design, isolated from the corporate network and the internet almost entirely. That isolation has eroded steadily as manufacturers pursued the benefits of connected operations: remote diagnostics from equipment vendors, predictive maintenance analytics that need machine data flowing to the cloud, and centralized production dashboards that pull data from every line into a single ERP or MES view.

Each of those connections is a legitimate business capability, and each one is also a new path from the IT network into the OT environment. A compromised vendor VPN credential, a poorly firewalled historian server that bridges both networks, or an engineering laptop that touches both the corporate domain and the plant network during a single visit are all common vectors we see in practice. The convergence itself is not the mistake; the mistake is convergence without a segmentation architecture designed to contain what happens when, not if, the IT side is compromised.

The Purdue Model: A Practical Framework for Network Segmentation

The Purdue Enterprise Reference Architecture, commonly shortened to the Purdue Model, remains the reference framework most OT security programs build from. It organizes the industrial environment into levels: Level 0 covers the physical process itself, sensors and actuators; Level 1 covers basic control, the PLCs and controllers; Level 2 covers supervisory control, HMIs and SCADA; Level 3 covers site operations, historians and MES; and Levels 4 and 5 cover business logistics and the enterprise IT network.

The value of the model is not the diagram, it is the discipline of defining zones and conduits between them. Traffic between levels should pass through a small number of well-controlled conduits, typically an industrial demilitarized zone (IDMZ) sitting between Level 3 and Level 4, rather than flowing freely across a flat network. A properly implemented IDMZ means a compromised laptop on the corporate network cannot reach a PLC directly; it has to traverse a controlled broker point that can be monitored, restricted, and cut off without shutting down the entire plant. Manufacturers that skip this segmentation commonly find that a single compromised IT endpoint has unrestricted line of sight to controllers on the floor.

Building Defense in Depth Across the Plant Floor

Segmentation is the foundation, but it is not the whole strategy. A mature OT security program typically layers several additional controls on top of the Purdue-based architecture. Asset inventory comes first, since you cannot protect what you do not know exists, and it is common for facilities to discover previously undocumented devices, rogue wireless access points, or forgotten remote access tools once a proper OT asset discovery is performed.

From there, effective programs add passive network monitoring tuned for industrial protocols such as Modbus, DNP3, and EtherNet/IP, since these protocols rarely carry authentication and anomalies are often the only signal available. Strict access control for engineering workstations, jump servers for any remote vendor access, and removable media controls round out the technical layer. None of this requires ripping out legacy equipment; it requires wrapping that equipment in controls it was never designed to have natively.

Incident Response When Downtime Has Physical Safety Implications

The single biggest difference between IT and OT incident response is what happens the moment you decide to contain a threat. In IT, isolating a compromised server is usually low risk: you disconnect it, and normal business continues elsewhere. In OT, isolating a compromised controller mid-cycle can leave a machine in an unsafe intermediate state, a robotic arm stopped mid-motion, a valve left partially open, a press stalled under load.

This is why OT incident response plans need a safety-first shutdown sequence defined and rehearsed in advance, jointly by security, operations, and safety engineering, not improvised during an active incident. Decisions about whether to isolate immediately, allow a controlled shutdown sequence to complete first, or fail over to a manual control mode should be pre-agreed and documented for each production line, not decided under pressure by whoever is on call. Tabletop exercises that specifically include plant operations and EHS (environment, health, and safety) stakeholders, not just the security team, are commonly what separates organizations that recover cleanly from those that turn a cyber incident into a safety incident.

Governance, Compliance, and the Human Factor

Frameworks like IEC 62443 and NIST SP 800-82 give manufacturers a structured way to assess maturity and prioritize investment, and increasingly customers and insurers are asking for evidence of alignment with one or both. But governance on paper does not protect a plant if the people running it were never trained on why a seemingly convenient shortcut, a shared password on an HMI, an unmanaged USB drive used to transfer a program update, undermines the whole architecture. Plant operators and controls engineers are not security professionals by training, and a program that does not invest in practical, role-specific awareness for that workforce will underperform regardless of how well the network is segmented.

Where Manufacturers Should Start

Organizations earlier in this journey do not need to solve everything at once. A practical sequence is typically: build an accurate OT asset inventory, establish network visibility to understand current traffic patterns and existing exposure, implement an IDMZ to break flat connectivity between IT and OT, and only then move into deeper monitoring and response capability. Trying to buy advanced detection tooling before basic segmentation exists is a common and costly ordering mistake.

Securing OT and ICS environments is a long-term program, not a single project, and it requires close collaboration between IT security, controls engineering, and operations leadership from day one. If your organization is assessing where your plant floor stands today, or building the roadmap to close the gap between IT and OT security maturity, the team at Halkwinds can help you scope an assessment and a phased plan suited to your production environment.

Frequently Asked Questions

Why can't manufacturers just patch PLCs the way IT patches servers?

Patching a PLC typically requires revalidating the control logic and often a full production stoppage, since changes to firmware can affect timing and safety behavior. Most facilities treat patching as a scheduled, carefully tested event rather than an automatic process, and rely on compensating controls like segmentation in between.

What is IT/OT convergence and why is it risky?

IT/OT convergence refers to industrial equipment being connected to corporate networks or the internet for reasons like remote monitoring and predictive maintenance. It is risky because it creates new pathways for an IT-side compromise to reach control systems that were never designed to resist network attacks.

What is the Purdue Model in simple terms?

The Purdue Model is a reference architecture that organizes industrial environments into levels, from physical process equipment up through supervisory and enterprise systems, and defines controlled conduits between them so a breach in one zone cannot freely spread into another.

How is OT incident response different from IT incident response?

OT incident response must account for physical safety, since isolating a compromised system mid-process can leave equipment in a hazardous state. Response plans typically require pre-agreed, rehearsed shutdown sequences developed jointly with operations and safety teams, not just the security team.

Where should a manufacturer start if they have never assessed OT security before?

Start with an accurate inventory of OT assets and current network connectivity, since most gaps are found there first. From that baseline, segmentation improvements like an industrial DMZ typically deliver the most risk reduction before investing in advanced monitoring tools.