PLCs, HMIs and SCADA servers were built for availability and determinism, not for exposure to untrusted networks. Patch cycles, failure modes and lifespans differ enough from IT that the security approach has to be designed for OT rather than borrowed from the corporate network.
IEC 62443 organises a plant into zones with a defined target security level and conduits that carry controlled traffic between them. A clean OT/IT boundary with a demilitarised zone removes most of the reachable attack surface without disrupting production.
Direct internet exposure to controllers and standing vendor connections are the recurring weak points. Managed access through a broker with multi-factor authentication, plus a patch approach that respects OT constraints, closes the gaps that matter.
OT network security for Australian manufacturers has moved from a niche concern to a board-level one as plant floor systems connect to corporate networks, cloud reporting and remote support. The exposure is concrete. A poorly segmented operational technology network can be reached from a compromised corporate laptop, and the controllers, HMIs and SCADA servers on that network were rarely designed to defend themselves. Metromotion Controls is a control systems integrator based in Mount Waverley that designs and commissions OT networks for manufacturers across Melbourne, Victoria and Australia, and this guide sets out the framework, the standards and a worked segmentation example in the practitioner voice we use on site.
This post supports our OT network security service, where segmentation design, secure remote access and zone-and-conduit architecture sit alongside the broader systems integration work that connects plant data to business systems.
The instinct on a brownfield site is to hand the OT network to the IT team and apply the existing corporate policy. That rarely works, because OT and IT optimise for different outcomes. IT prioritises confidentiality and treats scheduled patching and reboots as routine. OT prioritises availability and deterministic behaviour, where an unplanned reboot or a security agent that adds latency to a control message can stop production or push a process into an unsafe state.
Three structural differences drive the whole approach:
The point is not that IT security principles are wrong for OT. Least privilege, segmentation, monitoring and strong authentication all apply. They have to be implemented with controls that suit the environment, which is exactly what the OT security standards describe. The industrial control system (ICS) security body of practice exists because the plant floor needs its own model.
Three reference frameworks carry most of the weight in an OT security design, and they fit together rather than compete.
ISA/IEC 62443 is the international series for the security of industrial automation and control systems, developed by the ISA99 committee and the IEC. It defines the zones-and-conduits model and the SL 1 to SL 4 security levels, and it sets requirements across asset owners, integrators and product suppliers. The series is published through the IEC and through ISA as the ISA/IEC 62443 series. It is the primary standard most Australian sites should design to.
NIST SP 800-82, the Guide to Operational Technology (OT) Security published by the US National Institute of Standards and Technology, is the most detailed free reference available. Revision 3 broadened its scope from industrial control systems to operational technology generally and aligns with the NIST Cybersecurity Framework. It covers risk management, network architecture, patching constraints and a large catalogue of controls tailored to OT, and it is freely downloadable, which makes it a practical companion to the paid IEC series.
The Purdue model and ISA-95 give the architectural map. The Purdue Enterprise Reference Architecture underpins the ISA-95 enterprise-control integration standard and organises a plant into the levels described below. IEC 62443 then draws zone boundaries onto those levels.
| Standard | What it provides | Status |
|---|---|---|
| ISA/IEC 62443 | Zones, conduits, security levels SL 1 to SL 4, role requirements | International standard, primary OT security reference |
| NIST SP 800-82 Rev 3 | Detailed OT control catalogue, risk-based guidance | Freely available US government guidance |
| Purdue / ISA-95 | Layered reference architecture for the plant network | Reference model, basis for zone design |
| ACSC Essential Eight | Baseline mitigation strategies for IT-like assets | Australian baseline, see Australian context below |
Placing assets correctly in the Purdue levels is what makes a segmentation design tractable. The levels run from the field up to the enterprise:
The single most important boundary on most sites is between Level 3 and Level 4, enforced through the Level 3.5 demilitarised zone. The principle is that data flows from OT up to the demilitarised zone, and from the demilitarised zone up to IT, but no session originates in IT and terminates on a controller. The demilitarised zone is the buffer that lets reporting and integration happen without giving the corporate network a direct path to the plant.
A single boundary, however well built, is not enough on its own. Defence in depth layers independent controls so that the failure or bypass of one does not expose the whole system. On an OT network that means segmentation between zones, host hardening on the assets that can take it, strong authentication on every administrative and remote path, monitoring for anomalous traffic, and a tested backup and recovery position for controller programs and SCADA projects.
IEC 62443 gives this structure. A zone is a grouping of assets that share a security requirement, such as the controllers and HMIs of one production area. A conduit is a controlled communication path between zones, such as the link from the SCADA gateway up through the demilitarised zone to MES. Each zone is assigned a target security level from SL 1 to SL 4:
The practical effect is that every zone gets a defined target, and every conduit in or out of it, including remote access and reporting, is identified and given controls that meet that target. A flow that nobody can name is a flow that should not exist. This is the discipline that turns segmentation from a vague intention into an auditable design.
The following figures are illustrative engineering values for a fictional mid-sized food and beverage plant, used to show how the model is applied. They are not measurements from any Metromotion Controls project or named client. Consider a site with two process areas, a packaging hall, a central historian, and a requirement to push production data to a corporate ERP and a cloud dashboard.
A typical zone-and-conduit design for that plant might look like this:
| Zone | Purdue level | Contents | Target SL |
|---|---|---|---|
| Process Area A | 1 to 2 | Area A PLCs, HMIs, drives | SL 2 |
| Process Area B | 1 to 2 | Area B PLCs, HMIs, drives | SL 2 |
| Safety zone | 1 | Safety controllers and safety I/O | SL 3 |
| Packaging | 1 to 2 | Packaging PLCs, line HMIs | SL 2 |
| Site supervisory | 3 | SCADA gateway, historian, engineering workstation | SL 3 |
| OT/IT DMZ | 3.5 | Reverse proxy, MQTT broker, historian replica, remote-access broker | SL 3 |
| Enterprise IT | 4 to 5 | ERP, business systems, internet | Out of OT scope |
The conduits between those zones are then defined explicitly. For example:
The safety zone deserves its own boundary at a higher target level. Safety instrumented functions are assessed independently, and keeping them in their own zone preserves that independence. This connects directly to the broader topic of functional safety and SIL assessment, which is a separate but adjacent discipline.
Remote access is where the largest number of real sites fail, because it is the control most often added under time pressure and least often reviewed afterwards. The recurring failure modes are a controller or SCADA server exposed directly to the internet, a vendor VPN that was set up for a commissioning visit and never removed, and shared engineering credentials that nobody can attribute to a person.
A defensible remote-access pattern follows a short set of rules:
This is the conduit thinking of IEC 62443 applied to the one path that connects the outside world to the plant. The same broker can serve both internal engineers and external vendors, which keeps the number of inbound paths to one well-controlled point rather than several improvised ones. Remote support is a normal part of an automation upgrade and ongoing support relationship, and it can be delivered safely when it is designed rather than bolted on.
Patching in OT cannot follow the IT model of patch quickly and broadly, for three reasons. Many devices accept only vendor-certified updates, so a patch issued for the underlying operating system may never be approved for the control application running on it. Production schedules rarely offer the downtime that an update and revalidation cycle needs. And some assets are end-of-life, with no patches being issued at all.
The realistic response is risk-based rather than comprehensive:
NIST SP 800-82 sets out this risk-based approach in detail and is the reference to cite when explaining to a board why patch-everything is the wrong target for OT. Compensating controls through segmentation are often the only realistic protection for legacy equipment, which is one reason segmentation carries so much of the load. This intersects with legacy PLC migration, since replacing an unsupportable controller can sometimes be the better answer than defending it indefinitely.
For Australian manufacturers, the Australian Cyber Security Centre (ACSC) at cyber.gov.au is the primary national source of guidance, and the Essential Eight is the baseline most organisations are measured against. The Essential Eight is a set of eight mitigation strategies: application control, patch applications, configure Microsoft Office macro settings, user application hardening, restrict administrative privileges, patch operating systems, multi-factor authentication, and regular backups.
The Essential Eight was written primarily for Windows-based IT environments, so applying it to OT needs judgement. Several strategies map directly onto the plant:
The two patching strategies are where literal application breaks down, because forced operating-system and application patching can break a validated control system. For those, the OT patch approach above takes over. The sound model is to treat the Essential Eight as a baseline for the IT-like assets in the plant, then layer the OT-specific controls from IEC 62443 and NIST SP 800-82 on top for the control system itself. The ACSC also publishes guidance aimed specifically at operational technology environments, which should be read alongside the Essential Eight rather than as a substitute for it. Australian sites in regulated supply chains, such as food and beverage, should also keep their security position consistent with their broader compliance obligations.
Most serious OT security gaps are architectural rather than a missing tool. The recurring ones are worth naming so they can be designed out:
A methodical first pass on a brownfield site starts narrow. Build the asset inventory, then verify that OT and IT are genuinely separated at the switch and firewall level. Those two steps expose the most significant gaps without major capital, and they set up the segmentation and remote-access work that follows. This early scoping is part of how we approach an automation upgrade where security is in scope.
OT network security for Australian manufacturers is achievable without disrupting operations when the work is sequenced sensibly. Map the plant to the Purdue levels, draw IEC 62443 zones with target security levels onto that map, define every conduit explicitly, route all remote access through a controlled broker with multi-factor authentication, and run patching on a risk basis with compensating controls where patching is not possible. The ACSC Essential Eight gives the baseline for the IT-like assets, and NIST SP 800-82 supplies the detailed OT control catalogue. The result is a network that supports modern connectivity and reporting while keeping the control system reachable only through paths that are named, justified and monitored. If you can share your site layout, PLC mix and current network arrangement, Metromotion Controls can work through a segmentation and remote-access design that fits the plant.
The standards and figures referenced above are general industry and regulator sources, cited so the technical claims can be checked against the originals. The worked example uses illustrative engineering values and is not a Metromotion Controls measurement.
Tommy Kim writes for Metromotion Controls, a Melbourne control systems integrator delivering PLC, SCADA, controls integration and commissioning for food, beverage, dairy and FMCG manufacturers across Australia.
OT and IT optimise for different things. IT prioritises confidentiality and accepts that a server can be patched and rebooted on a schedule. OT prioritises availability and determinism, where an unplanned reboot or a security agent that delays a control message can stop production or create a process upset. Many OT devices run legacy operating systems that cannot take an endpoint agent, cannot be patched without vendor certification, and were commissioned on networks that were assumed to be isolated. Lifting an IT policy onto that estate either breaks the plant or gets exceptions written until it is meaningless. The workable approach takes the same principles, such as least privilege, segmentation and monitoring, and applies them with controls that suit OT, which is the model IEC 62443 and NIST SP 800-82 describe.
ISA/IEC 62443 is the international series of standards for the security of industrial automation and control systems, developed jointly by the ISA99 committee and the IEC. Its central idea is to group assets that share a security requirement into a zone, then treat every communication path between zones as a conduit that has explicit controls applied to it. Each zone is assigned a target security level from SL 1 to SL 4, where SL 1 guards against casual or coincidental misuse and SL 4 against a skilled, well-resourced and motivated attacker. The value of the model is that it forces every flow in and out of the control system to be named and justified, rather than left as an implicit trust that nobody documented. That makes the design auditable and gives a clear basis for deciding which controls each conduit needs.
The Purdue model, which underpins the ISA-95 enterprise-control integration standard, is a reference architecture that organises a plant into levels: field devices at Level 0, controllers at Level 1, supervisory HMI and SCADA at Level 2, site operations and the historian at Level 3, a demilitarised zone at Level 3.5, and enterprise IT at Levels 4 and 5. It describes how the layers stack and where data should and should not flow. IEC 62443 then divides that layered architecture into the zones and conduits that carry the security requirements. The two are complementary: Purdue gives the map of the plant, and IEC 62443 puts the security boundaries onto it. Most segmentation designs use the Purdue levels to decide where the zone boundaries sit.
No controller, HMI or SCADA server should be reachable directly from the internet, and no vendor connection should be left standing when it is not in use. Remote access should terminate at a managed broker or jump host in the OT/IT demilitarised zone, protected by multi-factor authentication, with each session authorised, time-limited and logged. Vendor access in particular should be granted per session and revoked when the task is done, rather than relying on a permanent VPN that nobody reviews. The path itself should be reviewed periodically and removed when the need ends. This pattern keeps remote engineering and vendor support possible without leaving an open door into the control network, and it aligns with the conduit thinking in IEC 62443 and the guidance in NIST SP 800-82.
Patching is constrained in OT for three reasons. Many devices can only be patched with vendor-certified updates, so a patch released for the underlying operating system may not be approved for the control application running on it. Production schedules rarely allow the downtime an update and validation cycle needs. And some assets are simply end-of-life, with no patches being issued at all. The realistic response is risk-based rather than patch-everything. Maintain an accurate asset inventory, prioritise patches by exposure and consequence, test in a non-production environment first, and apply them in planned maintenance windows. Where a device cannot be patched, compensating controls take over: tighter segmentation so the vulnerable asset is harder to reach, restricted conduits, and monitoring for unusual traffic. NIST SP 800-82 sets out this risk-based approach in detail.
The Essential Eight, published by the Australian Cyber Security Centre, is a baseline of eight mitigation strategies aimed primarily at Windows-based IT environments. Several map directly onto OT, such as restricting administrative privileges, multi-factor authentication on remote and administrative access, application control on engineering workstations and HMIs that run Windows, and regular backups of PLC programs, SCADA projects and configuration. Others, particularly aggressive operating-system and application patching, have to be adapted to OT constraints rather than applied literally, because forced patching can break a validated control system. The sound approach treats the Essential Eight as a baseline for the IT-like assets in the plant, then layers the OT-specific controls from IEC 62443 and NIST SP 800-82 on top for the control system itself. The ACSC also publishes specific guidance for operational technology environments that should be read alongside the Essential Eight.
OT network design, industrial Ethernet, secure remote access and SCADA server connectivity.
OEE, downtime, historian and production reporting systems built from reliable plant signals.
Engineering support for production faults, diagnostics, minor works and long-term controls reliability.
Packaging line control, PackML-aligned states, changeovers, inspection and OEE data capture.
A practical view of where Ignition is the right SCADA platform for Australian manufacturers and where it is not.
OT cybersecurity for Australian food and beverage manufacturers: ISA/IEC 62443, NIST SP 800-82, the ACSC Essential Eight in an OT context, FSANZ record integrity, recall exposure, ransomware impact and segmentation.
Key point
Food sites have accumulated connectivity they did not plan for
Published 9 May 2026
Most Australian manufacturing sites have more data than they can act on. This guide explains where plant data silos form, how a unified namespace, MQTT Sparkplug B and OPC UA break them down, and what a single source of truth aligned to ISA-95 actually looks like.
Key point
Data volume is not the problem, context is
Published 9 May 2026
A practical engineering guide to planning an automation upgrade on a live Australian plant: obsolescence and lifecycle assessment, risk ranking, phased versus big-bang cutover, brownfield constraints, spares, and standards continuity.
Key point
Lifecycle assessment sets the timing, not the failure
Published 9 May 2026
Map out scope, delivery approach and what to have ready before the first conversation. Answer a few questions and Metromotion Controls returns a tailored scoping brief on screen.