By David Chernitzky, Co-Founder and CEO, Armour Cybersecurity | Serving organizations across Canada, the US, and beyond | Last updated August 20, 2026
Quick answer: Operational Technology (OT) and Industrial Control Systems (ICS) run physical operations: manufacturing processes, utility infrastructure, water treatment, energy generation, and transportation systems. Securing these environments requires a fundamentally different approach from IT network security because the consequences of getting it wrong are different. An IT security incident results in data loss, operational disruption, and reputational damage. An OT security incident can result in those same consequences plus physical equipment damage, environmental harm, safety incidents, and public service disruption. The methodology for assessing and securing OT networks must account for these consequences: non-intrusive assessment techniques, zone-and-conduit segmentation following ISA/IEC 62443, and controls designed around operational availability as a non-negotiable requirement.
Key Takeaways
- The primary security concern in OT environments is availability, not confidentiality. IT security prioritizes confidentiality: protecting data from unauthorized disclosure. OT security prioritizes availability: ensuring that industrial processes continue to operate without disruption. Security controls that would be appropriate in an IT environment, such as active vulnerability scanning that sends probes to every network device, can cause OT devices to malfunction or fail in ways that disrupt physical operations. OT security assessment requires non-intrusive techniques that identify risks without creating new ones.
- ISA/IEC 62443 is the authoritative standard for industrial cybersecurity. It defines security requirements for industrial automation and control systems, including zone-and-conduit network segmentation, security levels for different zones based on the consequences of a security failure, and requirements for operators, integrators, and product suppliers. Organizations operating OT or ICS environments that need to demonstrate security compliance should assess against ISA/IEC 62443 rather than IT-focused frameworks that do not account for the specific requirements of industrial environments.
- The IT/OT convergence that enables remote monitoring and enterprise data integration creates security pathways that were not present in historically isolated OT environments. Every pathway between the IT network and the OT environment is a potential attack path. The Colonial Pipeline attack in 2021, which led to a six-day precautionary shutdown of a major US fuel pipeline, began with a compromised VPN account on the IT side that had no multi-factor authentication, and the operational shutdown followed from insufficient IT/OT separation and visibility.
- Legacy OT systems with decades-long operational lifespans run operating systems and protocols that cannot be patched or updated without manufacturer support, which may not be available for equipment that predates current cybersecurity standards. Security controls for these systems must be applied at the network layer, through segmentation and monitoring, rather than at the endpoint layer through agent-based controls.
- Vendor remote access is the most common source of uncontrolled IT/OT connectivity. Equipment manufacturers and maintenance vendors require remote access to OT systems for support and troubleshooting. Without proper controls, vendor access creates persistent pathways from the internet into OT environments that are difficult to inventory and even harder to secure consistently.
How OT Environments Differ From IT Environments
Availability over confidentiality
IT security operates on the CIA triad: Confidentiality, Integrity, and Availability, with confidentiality often receiving the most attention because data breaches are the most visible and quantifiable IT security consequence. OT security inverts this priority. An industrial process that is disrupted causes immediate, tangible harm: production stops, products are lost, equipment may be damaged, and in critical infrastructure environments, public services may be interrupted. A manufacturing plant that shuts down costs money for every hour of downtime. A water treatment facility that loses control of its chemical dosing systems creates a public health risk. An energy utility that loses generation capacity affects millions of customers.
This priority inversion has concrete implications for how security controls are designed and applied. An IT security control that prioritizes blocking suspicious activity over maintaining service availability is appropriate for a corporate network where a few minutes of service disruption is acceptable. The same control applied to a PLC managing a production line or a SCADA system controlling a pipeline is not acceptable if it creates any risk of operational disruption. OT security controls must be designed with operational availability as a non-negotiable constraint, not as a factor to be balanced against security.
Legacy systems with extended operational lifespans
IT infrastructure typically follows a replacement cycle of three to five years. OT equipment, particularly PLCs, RTUs, and industrial control systems, commonly operates for fifteen to twenty years or longer. Equipment deployed before current cybersecurity concerns existed runs operating systems and firmware that were designed for operational reliability and real-time performance, not security. Windows XP, Windows CE, and proprietary real-time operating systems are common in OT environments because the equipment running them cannot be updated without the original manufacturer providing a certified firmware update, and many manufacturers no longer support equipment of that age.
Patching these systems is often not possible: no patch exists for the vulnerability, or applying the available patch requires taking the system offline during the patch process, which is not operationally acceptable during normal production. Network-layer controls, specifically segmentation that limits what can reach these systems and monitoring that detects when they are accessed in unexpected ways, are the primary security controls available for legacy OT systems that cannot be patched or updated.
Proprietary protocols and real-time communication requirements
OT networks run industrial protocols, including Modbus, DNP3, PROFINET, and EtherNet/IP, that were designed for deterministic real-time communication in industrial environments, not for security. The older protocols in this group frequently lack authentication, encryption, or integrity checking. A Modbus message that commands a PLC to change a setpoint cannot be verified as originating from a legitimate source; any device that can reach the PLC on the Modbus port can send commands. This is not a vulnerability in the traditional sense; it is a design characteristic of a protocol that predates cybersecurity concerns by decades. Newer protocols such as OPC UA were designed with security in mind and support authentication and encryption, but they coexist with the legacy protocols rather than replacing them, so most OT networks still carry a mix that includes unauthenticated industrial traffic.
Network-layer security for OT environments must account for these protocol characteristics. Protocol-aware monitoring tools that understand the legitimate command patterns for industrial protocols can detect anomalous commands even when the protocol itself provides no authentication mechanism. Segmentation that limits which devices can reach PLC communication ports reduces the attack surface for protocol-based attacks without requiring changes to the PLCs or the protocols they run.
The IT/OT Convergence Challenge
Historically, OT environments were isolated from corporate IT networks by design. The operational risk of connecting industrial control systems to a network that also carried general business traffic was well understood by industrial engineers, and air gaps or tightly controlled connections were standard practice. The business value of remote monitoring, integration of process data with enterprise systems, and vendor remote support has driven progressive connectivity between IT and OT environments over the past two decades.
This convergence has created security pathways that neither the IT security team nor the OT operations team fully understands or controls. The IT security team does not have the OT expertise to understand what the industrial systems connected to the network actually do or what would happen if they were disrupted. The OT operations team does not have the IT security expertise to evaluate the security implications of the network connections that have been created. The result is a set of IT/OT boundary connections that were designed for operational convenience, not for security, and that have never been subject to a structured security review. Surfacing those undocumented connections is exactly what a network architecture review does, and enforcing a boundary around them is what a network segmentation review is built for.
The zone-and-conduit model defined in ISA/IEC 62443 provides the framework for securing this boundary: an industrial demilitarized zone at Level 3.5 between the IT network and the OT operations layer, with data flowing from OT to IT through controlled interfaces like historians, no direct connectivity between IT systems and OT control systems, and vendor remote access channeled through a dedicated jump host in the DMZ with session logging and time-limited access. Armour Cybersecurity applies this model to every network protection engagement that includes OT or ICS environments, using non-intrusive assessment techniques throughout.
Frequently Asked Questions
What is ISA/IEC 62443 and who needs to comply with it?
ISA/IEC 62443 is a series of international standards developed by the International Society of Automation (ISA) and adopted by the International Electrotechnical Commission (IEC) that defines requirements for securing industrial automation and control systems. The standard series covers security management systems for asset owners, security requirements for integrators implementing IACS solutions, and security capabilities for product suppliers building industrial control system components. It defines the zone-and-conduit model for network segmentation in industrial environments and establishes security levels (SL 1 through SL 4) that specify the security capability required for a zone based on the consequences of a security failure in that zone. Organizations that operate OT or ICS environments and are subject to regulatory requirements for industrial cybersecurity, particularly in critical infrastructure sectors, are expected to assess against ISA/IEC 62443. Even organizations not subject to regulatory requirements benefit from using the standard as the framework for OT security assessment and design.
What is NERC CIP and which organizations does it apply to?
NERC CIP (North American Electric Reliability Corporation Critical Infrastructure Protection) is a set of mandatory reliability standards for the bulk electric system in North America. It applies to owners and operators of bulk electric system assets, including generators, transmission facilities, and control centers, that meet the criteria defined in the NERC CIP standards for inclusion. The standards define requirements for electronic security perimeters, physical security, system security management, personnel and training, incident reporting and response planning, and recovery plans for bulk electric cyber systems. Organizations subject to NERC CIP are subject to mandatory audits and face significant financial penalties for non-compliance. A network protection engagement that includes NERC CIP compliance assessment applies the specific NERC CIP standards to the network architecture and produces compliance mapping against the applicable requirements.
Why is active vulnerability scanning dangerous in OT environments?
Active vulnerability scanning sends network probes to target systems to identify which services are running and whether those services have known vulnerabilities. In IT environments, this is a standard and safe assessment technique because IT systems are designed to receive and respond to arbitrary network traffic. OT devices, particularly older PLCs, RTUs, and field devices, are designed for specific communication patterns with their configured engineering tools and control systems. When they receive arbitrary network probes from a vulnerability scanner, some devices respond to unexpected traffic by crashing, entering an error state, or interrupting their control loop. A PLC that crashes during an active production run causes an immediate process shutdown. An RTU that enters an error state in a utility environment may interrupt monitoring or control of infrastructure. This is why OT security assessment uses non-intrusive techniques: manual configuration review, passive traffic observation using network taps, and protocol-aware tools specifically vetted and validated for use in industrial environments.
What should an OT/ICS incident response plan cover that a standard IT IR plan does not?
An OT incident response plan must address several elements that a standard IT IR plan does not. The plan must define the operational threshold for taking OT systems offline: unlike IT systems, which can typically be taken offline for investigation without operational consequence, OT systems often cannot be shut down without causing physical process disruption. The decision authority for taking OT systems offline must be explicitly defined and must include operations leadership, not just security. The plan must address the availability of OT-specific forensic tools that can investigate industrial systems without disrupting their operation. It must define the interface between the IT security team, which will manage the response for the IT side of any attack, and the OT operations team, which manages the operational continuity of the industrial environment. And it must address the regulatory notification requirements that apply in critical infrastructure sectors, which often have shorter notification timelines and higher specificity requirements than the privacy breach notifications more familiar to IT security teams.
The Bottom Line
OT and ICS environments cannot be secured with IT security methodology, because the stakes and the constraints are different. In IT, confidentiality leads and a few minutes of downtime is tolerable. In OT, availability is non-negotiable, the equipment can be twenty years old and unpatchable, the protocols were never built for security, and a control-loop disruption can mean physical damage, environmental harm, or a public-safety incident. That is why active vulnerability scanning, a routine IT technique, is dangerous in an OT environment, and why assessment has to be non-intrusive. The connective tissue of the problem is IT/OT convergence: every pathway added for remote monitoring, data integration, or vendor support is a potential attack path, and Colonial Pipeline showed how an IT-side compromise alone can force an operational shutdown when the boundary and the visibility are not there. The answer is an ISA/IEC 62443 zone-and-conduit design with a properly enforced Level 3.5 IT/OT boundary, network-layer controls for the systems that cannot be patched, and an incident response plan built around operational continuity. Armour Cybersecurity delivers all of it as part of its network protection engagement, using non-intrusive methods that will not disrupt operations.
About the author
David Chernitzky is Co-Founder and CEO of Armour Cybersecurity, a Toronto-based cybersecurity firm founded by military intelligence veterans and advised by senior leaders from PwC, KPMG, Deloitte, EY, and Mandiant. Armour serves more than 260 organizations across 52-plus industries, including finance, healthcare, technology, energy, legal, and government, with a 97 percent client retention rate.



