What is operational technology (OT) security?

Key takeaways

• OT covers everything that runs the plant: PLCs, HMIs, SCADA systems, DCS, safety instrumented systems, and the engineering workstations that program them.
• OT systems have different design priorities than IT: availability and safety dominate over confidentiality and integrity.
• The standard IT security playbook (patch fast, deploy EDR everywhere, force MFA) does not apply directly. Compensating controls and architecture choices do most of the work.
• For mid-market manufacturers, the dominant OT risk is not nation-state ICS targeting; it is ransomware reaching OT through the IT side, vendor remote access being abused, and physical access defeating logical controls.
• ARG audits OT alongside IT and physical in a single engagement; the surfaces are connected, and pretending they are separate is what produces the highest-impact findings.

What is operational technology, and how is it different from IT?

Operational technology (OT) is the category of hardware and software that monitors and controls physical processes. In a manufacturing facility, OT includes:

• Programmable logic controllers (PLCs) that execute control logic for individual machines or production lines.
• Human-machine interfaces (HMIs) that operators use to monitor and adjust the process.
• Supervisory control and data acquisition (SCADA) systems that aggregate visibility and control across the plant. See What is SCADA security?.
• Distributed control systems (DCS) for continuous-process operations.
• Safety instrumented systems (SIS) that trigger interlocks and shutdowns when process variables exceed safe limits.
• Engineering workstations that program PLCs and HMIs.
• Historian databases that record process data for analysis.
• Building automation and physical access control where it intersects with production.

The key contrast with IT:

Dimension	Typical IT priority	Typical OT priority
Availability	Important	Paramount
Safety	Implicit	Explicit primary goal
Confidentiality	Often high	Often secondary
Integrity	High	High, with safety implications
Patching cadence	Weeks	Years (validated systems)
Hardware lifecycle	3-5 years	10-25 years
User base	Office workers	Operators, engineers, maintenance
Network protocols	TCP/IP and standard apps	Modbus, DNP3, EtherNet/IP, OPC, proprietary
Failure consequences	Data loss, service interruption	Physical harm, environmental damage, equipment loss, production loss

The differences mean the IT security playbook needs translation, not direct application. A control that breaks production is a non-starter on the OT side regardless of how well it works in IT.

The unique risk profile of OT environments

OT environments combine several properties that produce a distinctive risk profile:

1. Long-lived equipment with limited update paths. A PLC programmed in 2010 may still run in 2026, with firmware that does not receive security updates from the vendor. The defender does not get to choose modern hardware everywhere.
2. Real-time and deterministic constraints. Many OT systems require deterministic response times. Adding security controls (network inspection, agent software, encryption overhead) can break the timing the process depends on.
3. Safety-system entanglement. Some controls and architectural choices interact with safety-instrumented systems. Changes need engineering review, not just security review.
4. Vendor remote access dependency. Many OT installations include vendor-managed remote access for diagnostics, updates, and emergency support. The vendor's security practice is part of the organization's OT security posture.
5. Physical accessibility. Engineering workstations, network closets, and HMIs sit on the plant floor where physical access is part of normal operation. See What is physical penetration testing?.
6. Specialized protocols and proprietary technology. Standard IT security tools often do not understand OT protocols (Modbus, DNP3, OPC) well enough to provide meaningful visibility or control.
7. Limited tolerance for false positives. A false-positive incident response on the IT side is an inconvenience; on the OT side it can shut down a production line.

The combination forces defenders toward different controls than the IT default: segmentation rather than agents, passive monitoring rather than active scanning, vendor management rather than tenant-wide policy, physical controls as a real layer rather than an afterthought.

Why OT security in manufacturing requires different controls than enterprise IT

The right OT security posture at a mid-market manufacturer reflects four practical realities.

Reality 1: The OT environment will not be modernized on an IT timeline. A meaningful percentage of installed equipment will remain in service for another decade. Security programs that assume hardware refresh as the path forward fail; programs that design around long-lived equipment succeed.

Reality 2: Vendor remote access is operationally necessary. Eliminating vendor remote access is not a viable answer in most environments. Managing it (named accounts, MFA, time-bounded access, session logging, vendor-side security verification) is. Banning it usually fails in practice and erodes the organization's relationship with critical vendors.

Reality 3: Defense in depth has to start with segmentation and physical controls. Network segmentation between IT, OT, and safety zones is the foundation. Physical access controls on engineering workstations, network closets, and control rooms come second. Active controls (monitoring, detection, response) come third, after the foundations are in place.

Reality 4: Detection has to be OT-aware. Generic IT detection tools see OT traffic as anomalies. OT-aware tools (Claroty, Dragos, Nozomi, etc.) understand the protocols and can distinguish normal operation from attack. For mid-market manufacturers, the right answer is often a managed service rather than an in-house deployment; the operational complexity exceeds the team's capacity.

The four realities together produce a security program that looks materially different from a standard IT program. The compliance frameworks (NIST CSF 2.0, CMMC 2.0) accommodate this through their structure, but the implementation requires OT-specific judgment.

Examples of OT incidents and their operational consequences

Major OT incidents have produced lessons that apply directly to mid-market manufacturers:

• Stuxnet (2010). Targeted attack against Iranian uranium enrichment centrifuges. Modified PLC code to damage equipment while reporting normal operation to monitoring systems. Lesson: PLC integrity matters; engineering workstation compromise is a direct OT attack path.
• Ukraine power grid attacks (2015, 2016). Attackers used IT-side compromises (spear phishing, credential theft) to reach OT systems and trigger outages. Lesson: the IT-to-OT path is the most common real-world OT attack chain; defending OT requires defending the IT pivot.
• TRITON / TRISIS (2017). Targeted attack against safety instrumented systems at a petrochemical facility. Demonstrated that attackers will target safety systems specifically to enable physical damage. Lesson: SIS are not exempt from cyber risk.
• Colonial Pipeline (2021). Ransomware on the IT side caused a precautionary OT-side shutdown. The OT systems themselves were not compromised, but operational interdependence forced the shutdown. Lesson: IT-side incidents can produce OT-side consequences even without direct OT compromise.
• JBS Foods (2021). Ransomware shut down meat processing operations across multiple facilities. Lesson: mid-size to large food manufacturers are valuable targets; production stoppages produce both ransom pressure and supply-chain externalities.
• Recurring industrial-ransomware events (2023-2026). A steady stream of manufacturers, water utilities, and food processors compromised through commodity ransomware that reaches OT-adjacent IT. Lesson: most actual OT impact comes from non-targeted attacks that succeed because the IT side was vulnerable.

The pattern across these events: the dominant attack chain is IT-to-OT, not direct OT exploitation. The mid-market manufacturer's biggest practical OT exposure is the IT side of the house. See What is the IT/OT convergence problem?.

How to start an OT security program without disrupting production

A practical sequence for a mid-market manufacturer starting from minimal OT-specific security:

1. Build an OT asset inventory. Document every PLC, HMI, SCADA component, engineering workstation, historian, and safety-system asset. Include vendor, firmware version, location, and function. Most facilities discover assets they did not know they had in this step.
2. Map the IT-OT boundary. Where does IT network touch OT network. What firewall rules exist. What protocols cross. Where are the engineering workstations connected. This map is the foundation for everything that follows.
3. Identify vendor remote access paths. Every vendor that connects in, how they connect, what they access, how their access is logged. Many facilities discover unmanaged vendor access in this step.
4. Document the safety boundary. Which assets are part of safety instrumented systems. Which assets feed safety logic. Where are the air-gap or unidirectional barriers between control and safety.
5. Implement segmentation between IT and OT. A firewall with explicit allowlist rules. The firewall sits between the IT network and the OT network; traffic in either direction is explicitly permitted by rule, not by default-allow.
6. Lock down engineering workstations. Patch, harden, restrict, and monitor the workstations that program PLCs. They are the most direct OT attack path from the IT side.
7. Implement passive OT monitoring. A passive tap on the OT network feeds an OT-aware detection platform. Visibility is the goal; the tool does not need to actively scan OT assets to deliver value.
8. Plan for incident response. Incident response playbooks need OT-specific scenarios: production stoppage, safety-system trigger, vendor remote access compromise.
9. Audit the physical surface. Engineering rooms, control rooms, and network closets are part of OT security. See What is a physical security audit?.
10. Schedule the next layer. Each step gives the organization more capacity for the next. Most mid-market manufacturers need 18 to 36 months to mature through this sequence.

Best practices for OT segmentation, monitoring, and patching

1. Segmentation by Purdue level, with documented exceptions. Network architecture aligned to the Purdue Model provides a defensible structure. Exceptions exist (and are normal); they are documented and time-bounded.
2. Unidirectional gateways for the most sensitive boundaries. Data flows from OT to IT for historian and reporting; traffic does not flow back. Unidirectional gateways enforce this in hardware where the risk justifies the cost.
3. Vendor remote access through a managed bastion. All vendor connections route through a controlled jump server with MFA, session recording, and time-bounded access. The bastion is the single inspection point.
4. Passive monitoring with OT-aware tooling. Active scanning of OT systems is operationally risky. Passive tap-and-analyze tooling provides visibility without operational disturbance.
5. Patch on a schedule the vendor and the safety system support. Aggressive patching breaks production; ignoring patches accumulates risk. The right cadence is documented, scheduled around production windows, validated with the equipment vendor, and tested in a representative environment before deployment.
6. Backup with offline copies. Configurations, programs, and historian data backed up to offline media. Ransomware that encrypts online backups should not encrypt offline ones.
7. Engineering-workstation specific controls. Application allowlisting, removable-media controls, restricted network access, EDR where the vendor supports it. The engineering workstation is the most attractive lateral target.
8. Documented engagement with regulators and insurers. Cyber insurance underwriters and (for regulated industries) regulators increasingly expect OT-specific evidence. The program produces it as a byproduct rather than as a separate project.

OT security FAQs

Is OT security the same as ICS security?

Largely overlapping but not identical. Industrial control systems (ICS) are one major category of OT. OT also includes building automation, physical access control panels, environmental monitoring, and other operational equipment that is not strictly process control. ICS security is a subset of OT security. See What is an industrial control system (ICS)?.

Can OT systems be patched the way IT systems are?

Usually not. OT systems often have long uptime requirements, vendor-controlled firmware, safety-system interlocks, and dependencies on specific software versions for validated operation. Patching cycles measured in years (not weeks) are common. Compensating controls (segmentation, monitoring, restricted access) often matter more than the patch itself.

What is the cost of an OT cyber incident?

Production downtime is usually the dominant cost. For a mid-market manufacturer, even a day of stopped production can run into six figures in lost revenue, scrapped product, and recovery labor. Multi-day events can run into seven figures. Add insurance, regulatory, and reputational impact, and OT incidents are routinely the most expensive cyber events a manufacturer faces.

Where does IT security end and OT security begin?

There is no clean line. The traditional boundary at the IT-OT firewall has eroded as engineering workstations, vendor-remote-access tools, and historian databases sit in both worlds. The right framing is not boundary maintenance but blast-radius control: how much damage to the OT side can be caused by a compromise on the IT side, and how would the organization know.

How ARG audits OT security on manufacturing sites

ARG audits OT alongside IT and physical in a single engagement. The surfaces are entangled; pretending they are separate is what produces the largest blind spots in mid-market manufacturer security programs.

The on-site audit is conducted by David Ashby, drawing on a manufacturing background at Quality Electrical Systems. The operator's experience with control panels, UL 508A standards, and plant operations means the audit reads as an operations review with security implications, not a security review imposed on operations. The vocabulary is shared with the engineering team; the findings are credible because they are grounded in the actual production reality.

The audit covers:

• Asset and architecture review. PLC, HMI, SCADA, DCS, safety-system inventory. Network topology between IT and OT zones. Vendor remote-access paths.
• Segmentation effectiveness. Firewall rules between IT and OT; documentation of exceptions; observed traffic patterns where passive monitoring is available.
• Engineering workstation hardening. Workstation configuration, application controls, removable-media policy, network access posture.
• Vendor management. Vendor remote-access governance, named accounts, MFA posture, session-recording status.
• Physical access to OT. Control room and engineering room access; network closet access; HMI placement and badge requirements. See What is a physical security audit?.
• Incident response readiness for OT scenarios. Playbooks for production stoppage, vendor compromise, safety-system trigger.

Where appropriate and within the engagement's rules, ARG exercises specific attack paths during on-site weeks: pretexted entry to OT-adjacent areas, badge cloning against zones bordering OT, and (digitally) IT-to-OT pivot demonstrations through the engineering workstation surface. Live OT control logic is never directly tested.

Findings consolidate into the engagement report alongside IT and physical findings. The prioritized remediation backlog includes OT-specific items that map to NIST CSF 2.0, CMMC, and insurance-renewal evidence requirements.

Apply as a founding client or see how the engagement works for the full delivery cycle.