Protecting industrial networks means knowing every device on the network, dividing the network into separated zones, keeping remote access tight and being able to keep production running safely when something goes wrong. In operational technology (OT), the priority is usually not data confidentiality but keeping the physical process running safely and without interruption. That is why the methods familiar from office IT can’t simply be copied over to OT.
We first published this article in March 2026 and expanded it in October 2026. It now explains in more concrete terms how OT differs from IT, the most common risks and the basic measures recommended by international guidance.
Why is OT security different from IT security?
OT covers systems that monitor or control physical processes, such as the PLCs, SCADA systems and HMIs that run production lines, pumps, power distribution or building automation. NIST SP 800-82 Rev. 3, the US National Institute of Standards and Technology’s guide to OT security, notes that OT security objectives typically put integrity and availability first and confidentiality after them, with safety as an overarching priority.
| Aspect | Corporate IT | OT |
|---|---|---|
| Priority | Data confidentiality and integrity | Human safety, then protection of the process |
| A brief outage | Usually not a major risk | May be unacceptable |
| Rebooting | Usually acceptable | Can disrupt production; outages are scheduled days or weeks ahead |
| Component lifetime | Around 3–5 years | Often 10–15 years, sometimes longer |
| Software updates | Routine, often automated | Need testing by vendor and user, plus a planned outage |
| Support | Diverse support options | Sometimes only one vendor |
The same guide notes that an OT system can stay in service for more than 20 years, so unsupported components that can no longer be patched are common. In some cases, vendor licensing and service agreements don’t even allow third-party security software to be installed. The US Cybersecurity and Infrastructure Security Agency, CISA, stresses that security weaknesses introduced during procurement, design and deployment are likely to persist throughout an OT system’s decades-long life, and that architectures are difficult to change once operations begin. In short, design time is the cheapest moment to build security in.
Common risks in industrial networks
- Flat networks. If office PCs, servers and PLCs share one network, malware arriving in an email attachment can reach production equipment.
- Internet-exposed devices and remote access. HMIs opened to the internet for convenient maintenance, or unprotected remote connections. CISA lists internet-exposed HMIs and PLCs with no protection among the problems it regularly sees.
- Default passwords. Factory usernames and passwords that are never changed. A May 2025 fact sheet from CISA, the FBI, the EPA and the US Department of Energy lists changing default passwords immediately among its primary mitigations.
- Any-to-any firewall rules. Rules that allow traffic from anywhere to anywhere are another deployment problem CISA highlights, and they leave segmentation existing only on paper.
- Unmanaged IoT devices. Energy meters, cameras or sensor gateways added later join the network without being inventoried, and nobody tracks their updates.
Core measures: inventory and segmentation
Asset inventory
You can’t protect what you don’t know you have. The OT asset inventory guidance that CISA published with partner agencies in August 2025 defines an inventory as an organised, regularly updated list of an organisation’s systems, hardware and software, and notes that without one, organisations do not know what they have. Recording the manufacturer, model, software version, network address, location, protocols and criticality of each device is a good start; manufacturer and version details are also how you find out which known vulnerabilities affect you.
Zones and conduits
ISA/IEC 62443 is the international series of standards for securing industrial automation and control systems, built on shared responsibility between asset owners, system integrators and product suppliers. One of its core ideas is zones and conduits. According to a guide published by ISA, a zone is a grouping of assets based on risk or criteria such as criticality, operational function, physical or logical location, required access or responsible organisation. A conduit is a logical grouping of communication channels that share common security requirements and connect two or more zones. Part 3-2 of the series requires business and control system assets, as well as safety-related assets, to be separated, and recommends separating wireless devices and devices connected via external networks.
The Purdue model and the DMZ
Another common reference for layering a network is the Purdue model: field sensors and final elements sit at the bottom (Level 0), controllers just above them, and business systems at the upper levels. NIST SP 800-82 recommends firewall rules that only allow connections between adjacent levels; for example, Level 4 devices should not communicate directly with devices at Levels 2, 1 or 0. Both NIST and CISA also recommend a demilitarised zone (DMZ) between the corporate and OT networks, so that traffic between them passes through services in the DMZ rather than directly.
Remote access, patching and change management
Remote access. Vendors and integrators often need remote access for maintenance; the problem is when that access is permanent and unsupervised. CISA recommends removing OT devices from the public internet and, where remote access is needed, using a private network connection and a VPN with phishing-resistant multi-factor authentication, limited by least privilege. In practice, that means a single controlled entry point, personal accounts, access that is opened only for the maintenance window, and session logs. NIST also recommends separate credentials for corporate and OT network users.
Patching. In OT, updating is not a matter of “release, install”. NIST recommends testing patches under field conditions, on a test system where possible, before installing them, and disabling unused ports and services after testing that this won’t affect operations. For components the vendor no longer supports, it calls for additional compensating controls. Placing such devices in their own zone and monitoring their traffic are practical ways to protect equipment that can’t be patched.
Change management. According to NIST, change management in OT also covers hardware and firmware, and it needs careful assessment by control engineers working with security and IT staff. Every change to a PLC program, firewall rule or device firmware should be logged, approved and backed by a rollback plan, and the inventory should be updated alongside it.
Monitoring, backups and incident response
Monitoring and anomaly detection. NIST notes that OT traffic is typically more deterministic than IT traffic: repeatable, predictable and designed. That makes deviations from normal easier to spot. The guide treats understanding the network’s normal state as a prerequisite for monitoring and suggests starting in a passive (listen or learning) mode. Behavioural anomaly detection, SIEM and intrusion detection systems are the tools that support this work.
Backups and manual operation. CISA recommends keeping the ability to run OT systems manually and regularly testing business continuity plans, backups and standby systems. Up-to-date copies of PLC programs, HMI projects and device configurations, kept off the network, shorten the road back to production after an incident.
Incident response plan. Decide in advance who makes decisions during an incident, which systems get disconnected, and how production is safely stopped or continued manually, then rehearse it. The plan is a joint effort between IT and the production and maintenance teams.
Frequently asked questions
Where should a small plant start?
Start with an inventory: find out which devices are on the network and which of them are reachable from the internet. Then change default passwords, route remote access through a single controlled point and separate the office network from the production network. These steps match CISA’s primary mitigations, and most of them don’t require a large investment.
Aren’t antivirus and a firewall enough?
Not on their own. NIST recommends tools such as antivirus software in OT only where technically feasible, and some vendors don’t allow software to be installed without their approval. That is why OT protection relies less on installing software on devices and more on network separation, access control and monitoring.
Is it safe to connect IoT devices to the OT network?
The risk can be managed, but it shouldn’t be done without a plan. As ISA/IEC 62443 recommends, put wireless devices and devices that connect to external networks in their own zone, allow only the connections they need, and pass data through an intermediate layer. See our post on IoT remote monitoring for more detail.
Conclusion
Industrial networks aren’t protected by a single product but by a set of basic habits: knowing your inventory, dividing the network into zones, tightening remote access, managing changes, monitoring the network and testing backups regularly. ISA/IEC 62443, NIST SP 800-82 and CISA’s guidance give these steps a common framework.
We are not a cybersecurity firm, and for penetration testing or security audits we recommend working with specialists in that field. Our job is to design industrial and IoT software and architectures with these principles in mind from the start: encrypted communication from device to server, permission-based access, separated network zones and resilience to connection loss. If you are planning a new system, take a look at our software architecture and DevOps and smart city and IoT pages, or get in touch and we can look at it together.
