OT Network Security for Australian Manufacturing Sites

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.

This post supports our OT network security service alongside the broader systems integration work that connects plant data to business systems. It covers the architecture and engineering controls that apply to any plant; the companion post on OT cybersecurity for food manufacturers covers what changes when the plant makes food, including FSANZ record integrity and recall exposure.

Why OT security is its own discipline

The instinct on a brownfield site is to hand the OT network to the IT team and apply the corporate policy. That rarely works. 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 approach:

• Availability is the priority. A controller rebooted for a patch can halt a line. Controls that interrupt communications, even briefly, are often unacceptable in a running process.
• Asset lifespans are long. OT hardware and software commonly run for 15 to 25 years, so systems commissioned before modern security practice are still in daily service.
• Patch cycles are constrained. Vendor certification, production schedules and end-of-life equipment limit routine patching, so known vulnerabilities can persist for years on OT endpoints.

IT security principles still apply. Least privilege, segmentation, monitoring and strong authentication all carry over, but they have to be implemented with controls that suit the environment, which is what the OT security standards describe.

The standards that govern OT security

Three reference frameworks carry most of the weight in an OT security design, and they fit together rather than compete.

ISA/IEC 62443, developed by the ISA99 committee and the IEC, is the international series for the security of industrial automation and control systems. It defines the zones-and-conduits model and the SL 1 to SL 4 security levels, sets requirements across asset owners, integrators and product suppliers, and is the primary standard most Australian sites should design to. The series is published through the IEC and described by ISA.

NIST SP 800-82 Rev 3, the Guide to Operational Technology (OT) Security, is the most detailed free reference: risk management, network architecture, patching constraints and a large catalogue of controls tailored to OT.

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 shown below; IEC 62443 then draws zone boundaries onto those levels. The fourth reference, the ACSC Essential Eight, is the Australian baseline and is covered in its own section.

The Purdue model and where the boundaries sit

Placing assets correctly in the levels shown above is what makes a segmentation design tractable, and the single most important boundary on most sites is between Level 3 and Level 4, enforced through the Level 3.5 demilitarised zone. Data flows from OT up to the demilitarised zone, and from there up to IT, but no session originates in IT and terminates on a controller. That is what lets reporting and integration happen without giving the corporate network a direct path to the plant.

Defence in depth and the IEC 62443 zone-and-conduit model

A single boundary 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: segmentation between zones, host hardening where the asset can take it, strong authentication on every administrative and remote path, monitoring, and a tested backup 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 gets a target security level:

• SL 1 protects against casual or coincidental misuse.
• SL 2 protects against intentional misuse using simple means and low resources.
• SL 3 protects against intentional misuse using sophisticated means and moderate resources.
• SL 4 protects against a sophisticated, well-resourced and motivated attacker.

Every conduit in or out of a zone, including remote access and reporting, is identified and given controls that meet the zone's target. A flow that nobody can name is a flow that should not exist. This discipline turns segmentation from a vague intention into an auditable design.

A worked segmentation example

The following values are illustrative, for a fictional mid-sized plant, 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 might look like this:

The conduits between those zones are then defined explicitly:

• Areas to Site supervisory. The SCADA gateway polls the area PLCs through a firewall rule that permits only the SCADA host and only the required ports.
• Site supervisory to OT/IT DMZ. The historian replicates to a copy in the demilitarised zone, and the MQTT broker there receives published data from the gateway. Sessions originate in OT and terminate in the demilitarised zone, never the reverse.
• OT/IT DMZ to Enterprise IT. The ERP reads from the historian replica and the cloud dashboard subscribes to the broker, both pulling from the demilitarised zone. No enterprise system addresses an OT asset directly.
• Remote access. Vendor and engineering sessions terminate at the remote-access broker in the demilitarised zone, behind multi-factor authentication, and are brokered onward to a specific asset for the duration of an authorised session only.

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 to functional safety and SIL assessment, a separate but adjacent discipline.

Secure remote access

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 set up for a commissioning visit and never removed, and shared engineering credentials nobody can attribute to a person.

A defensible pattern follows a short set of rules:

• All remote access routes through a managed broker or jump host in the OT/IT demilitarised zone, never directly to a controller or SCADA server.
• Multi-factor authentication is mandatory on every remote and administrative session.
• Sessions are individually authorised, time-limited, attributable to a named person, and logged.
• Vendor access is granted per session and revoked when the task is complete, not left standing.
• The remote-access path is reviewed on a schedule and removed when the need ends.

The same broker serves internal engineers and external vendors, which keeps inbound access 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 is delivered safely when it is designed rather than bolted on.

Patch management under OT constraints

Patching in OT cannot follow the IT model of patch quickly and broadly. Many devices accept only vendor-certified updates, so an operating-system patch may never be approved for the control application running on it. Production schedules rarely offer the downtime an update and revalidation cycle needs. And some assets are end-of-life, with no patches issued at all.

The realistic response is risk-based:

1. Maintain an accurate asset inventory, including firmware versions and known vulnerabilities.
2. Prioritise by exposure and consequence. A vulnerable asset reachable from a less-trusted zone matters more than one buried in a well-segmented area.
3. Test before applying, on a test rig or non-production environment.
4. Apply in planned windows, alongside other maintenance work, with a rollback position.
5. Use compensating controls where patching is impossible. For an unpatchable device, tighten the segmentation around it, restrict its conduits, and monitor its traffic.

NIST SP 800-82 sets out this approach in detail and is the reference to cite when explaining why patch-everything is the wrong target for OT. Segmentation is often the only realistic protection for legacy equipment, which intersects with legacy PLC migration: replacing an unsupportable controller can be a better answer than defending it indefinitely.

The Australian context: ACSC and the Essential Eight

For Australian manufacturers, the Australian Cyber Security Centre (ACSC) is the primary national source of guidance, and the Essential Eight is the baseline most organisations are measured against: 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, so applying it to OT needs judgement. Several strategies map directly:

• Restrict administrative privileges and multi-factor authentication apply cleanly to engineering workstations, remote access and SCADA administration.
• Application control suits Windows-based HMIs and engineering stations that run a stable, known set of programs.
• Regular backups apply to PLC programs, SCADA projects and configuration, exactly the artefacts needed to recover a plant after an incident.

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 the baseline for the IT-like assets, 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, to be read alongside the Essential Eight rather than as a substitute. For food and beverage sites, the regulatory consequences that change the priority order are covered in the food manufacturing companion post.

Common mistakes and pitfalls

Most serious OT security gaps are architectural rather than a missing tool. The recurring ones are worth naming so they can be designed out:

• Assumed segmentation. OT and IT are believed to be separated, but a flat switch, a dual-homed historian or an undocumented cable bridges them. Verify at the switch and firewall level rather than trusting the network diagram.
• No asset inventory. Without it, neither patching nor segmentation can be prioritised, and unknown devices are the ones that get compromised.
• Standing remote access. Vendor VPNs and engineering connections left open after the work is done are the most common entry path in real incidents.
• Security agents on unsuitable devices. An IT endpoint agent on a controller or a real-time HMI can add latency or instability to a control function. Match the control to the asset.
• Safety and security in one zone. Safety functions need their own zone at a higher target level so their assessed independence is preserved.
• Skipping backups of OT artefacts. A current, tested backup of every PLC program and SCADA project is what turns an incident into a recovery rather than a rebuild.

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.

Bringing it together

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 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.

References

• ISA/IEC 62443 series, security for industrial automation and control systems (zones, conduits, security levels): https://www.isa.org/standards-and-publications/isa-standards/isa-iec-62443-series-of-standards
• IEC, International Electrotechnical Commission, publisher of the IEC 62443 series: https://www.iec.ch
• NIST SP 800-82 Rev 3, Guide to Operational Technology (OT) Security: https://csrc.nist.gov/pubs/sp/800/82/r3/final
• ACSC, Australian Cyber Security Centre guidance: https://www.cyber.gov.au
• ACSC Essential Eight, baseline mitigation strategies: https://www.cyber.gov.au/resources-business-and-government/essential-cyber-security/essential-eight