From frameworks to drawings: the OT design layer that actually defends

Two posts ago we mapped the structural layer. One post ago we picked the lead framework. This is the post where the work stops being words on a page and starts being lines on a drawing.

The reference architecture is where most Australian OT programmes either come together or quietly fall apart. The functional hierarchy gives you a vocabulary. The framework gives you a control catalogue. The design is what an engineer has to build, an operations team has to run, and an auditor has to recognise. If the drawing is wrong, every artefact above it is fiction.

This post is the design layer. Zones. Conduits. The Industrial DMZ. Control placement against Purdue. A defensible reference architecture that holds up when something actually goes wrong.

Zones and conduits, in plain language

IEC 62443 thinks about an OT environment as a set of zones connected by conduits.

A zone is a logical or physical grouping of assets that share a common set of security requirements. Every asset in a zone needs the same level of protection from the same kinds of threat, because compromising any one of them compromises the whole group. The corollary is also true. If two assets have meaningfully different security requirements, they belong in different zones.

A conduit is the channel through which zones communicate. It is the only path traffic should be able to take between zones. A conduit has its own security requirements, usually stricter than either zone it joins, because it is the choke point where policy gets enforced. Filtering, inspection, authentication, and rate-limiting all live in the conduit.

The reason this model works for OT is that it forces a decision an IT network design rarely needs to make explicit. What is allowed to talk to what, and by what mechanism. In an IT estate, the default answer is “most things talk to most things, controlled at the endpoint”. In an OT estate, that default is unsafe. The design has to enumerate the conversations. Zone-and-conduit gives you the language for the enumeration.

How zones land on the functional hierarchy

Part 1 mapped Purdue against ISA-95. Zone definition lands on top of that map.

A defensible reference architecture for an Australian OT operator usually has five or six recognisable zone families. The names vary. The shape doesn’t.

Level 4 sits in the enterprise IT zone. ERP, business email, the corporate identity provider, the company file server. Standard enterprise IT security. Not part of the OT zone model except as the external counterparty on the upstream side of the Industrial DMZ.

Level 3.5 is the Industrial DMZ. This is a zone in its own right, not just a firewall pair. It hosts the brokers and proxies that mediate every conversation between the enterprise and the plant: the patch-staging server, the antivirus repository, the historian replica, the remote-access jump host, the engineering workstation gateway. Nothing crosses from Level 4 into Level 3 without terminating in the IDMZ first.

Level 3 is the manufacturing operations zone. The site-level historian, the MES, the engineering workstations, the OT-side directory services and time sources. Sometimes split into two zones for operators with separate batch and discrete environments.

Level 2 is the supervisory zone, or zones. HMI servers, SCADA front-ends, alarm servers. Often broken into two or more zones along process or geographic lines so that compromise of one supervisory cluster does not propagate to the next.

Level 1 is the control zone. PLCs, RTUs, safety controllers. Almost always split into multiple zones, by process line or by safety integrity level, because the blast radius of a Level 1 compromise is bounded by zone boundaries.

Level 0 is the field zone. Sensors, actuators, instrumentation. In some architectures Level 0 sits inside its Level 1 zone. In others it is treated as a peer zone with its own conduit to the Level 1 controller.

Six zone families, then, in the common case. Enterprise IT (out of OT scope). Industrial DMZ. Manufacturing operations. Supervisory. Control. Field. Each one with a security level target defined against the four IEC 62443 SLs. Each one connected to its neighbours by exactly one conduit, with a defined ruleset.

The Industrial DMZ is the load-bearing element

If a reference architecture has only one thing right, it should be the IDMZ.

The IDMZ exists because two facts are simultaneously true. Plant systems need data and updates from the enterprise. Plant systems must not be reachable from the enterprise. The way to satisfy both is to break every conversation in half. The enterprise side terminates against an IDMZ broker. The plant side polls or pulls from that broker. No session ever crosses the boundary intact.

A typical IDMZ has four or five broker categories.

A historian replica or data diode endpoint, so business reporting tools can read OT data without reaching into Level 3.

A patch and antivirus staging server, so Microsoft updates and signature files land in the IDMZ first and are pulled inward on a schedule. The plant-side download path never reaches Microsoft Update directly.

A remote access jump host with strong authentication, session recording, and just-in-time privilege elevation. This is where vendor support sessions terminate. The vendor authenticates into the IDMZ. The engineer working from inside Level 3 connects out to the same host. They share a session on the host. Neither end ever has a direct path to the other.

An engineering workstation gateway, where laptops being brought into the plant for commissioning or maintenance get scanned, baselined, and granted a time-bound session into Level 3.

A reverse proxy or web application gateway for any browser-based supervisory tooling that needs to be reachable from a controlled enterprise endpoint.

Each of those brokers is a zone in its own right, or a member of a single IDMZ zone with internal segmentation. The conduits between them and Level 3 are stricter than the conduits to Level 4. Most operators we work with apply IEC 62443 SL 3 to the IDMZ as a whole and SL 2 to the Level 3 zone immediately inside it.

What the IDMZ is not is a firewall pair labelled “DMZ” on a network diagram with the historian sitting in it talking directly to both sides. That topology is common, it looks defensible, and it offers almost no protection beyond what the firewalls themselves give you. Genuine IDMZ design forces the session break.

Control placement against the foundational requirements

IEC 62443-3-3 defines seven foundational requirements. Identification and authentication control. Use control. System integrity. Data confidentiality. Restricted data flow. Timely response to events. Resource availability.

A defensible design places concrete controls against each FR at each zone level. The shape of the matrix is consistent. The detail varies by environment.

Identification and authentication at the IDMZ is the strongest point in the design. MFA on every interactive session. Service accounts inventoried and rotated. The directory used to authenticate IDMZ sessions is separate from the enterprise directory by design, with a tightly controlled trust relationship. Inside Level 3, authentication is usually local or against the OT-side directory, with MFA on engineering workstations but not on PLC engineering ports (which authenticate against the engineering software, not the PLC itself).

Use control means what an authenticated identity is allowed to do. At the IDMZ jump host, this is enforced by session policy and role membership. At Level 3, it is enforced by application-layer permissions in the engineering software and the historian. At Level 1, it is often enforced by physical key switches on the PLC itself: run, programme, remote.

System integrity is where most operators have the most work to do. The Level 1 and Level 2 estate is full of devices that do not support code signing, do not report integrity violations, and do not produce useful audit logs. Compensating controls live in the conduit and in the operations process. Conduit-level inspection. Configuration baselines pulled and compared on a schedule. Change windows under explicit approval.

Restricted data flow is the conduit ruleset. This is where the design earns or loses its credibility. Every conduit needs an enumerated, justified ruleset, owned by a named person, reviewed on a schedule. The ruleset states which protocols are allowed, in which direction, between which specific endpoints, for which purpose. A conduit with a “permit any any from Level 3 to Level 2” rule is not a conduit. It is the absence of one.

Timely response to events combines logging, monitoring, and incident response procedure. The OT side of the design should produce its own event stream into an OT-aware monitoring stack. Forwarding raw OT logs into an enterprise SIEM without OT context is a common pattern that produces volume without insight.

Resource availability covers the operational concern that often dominates OT design: the controls must not threaten the process. Network segmentation must not break determinism. Inspection devices must fail open or fail closed in the way the safety case requires, not in whatever the default is. This is the foundational requirement that gets cited when operations resists a control. Most of the time, “it will affect availability” is a real concern that good design accommodates rather than ignores.

A defensible reference architecture, end to end

Pull it all together and the picture looks like this.

Enterprise IT sits at Level 4 with conventional enterprise controls. A single audited conduit connects Level 4 to the Industrial DMZ. Outbound from Level 4 it carries operational reporting traffic. Inbound it carries nothing that does not terminate against an IDMZ broker.

The IDMZ is its own zone or family of zones. Brokers for data replication, patching, antivirus, remote access, and any reverse-proxied supervisory tooling. SL 3 controls across the zone. MFA on every interactive session. Session recording on remote access. Time-bound, role-mapped authorisation on every broker.

A second audited conduit connects the IDMZ inward to the manufacturing operations zone at Level 3. The Level 3 zone houses the production historian, MES, OT-side directory and time, and engineering workstations. SL 2 controls. The conduit ruleset is enumerated and reviewed quarterly.

Below Level 3, supervisory zones at Level 2 are split along process or geographic lines. Each supervisory zone has its own conduit to its Level 1 control zone. Control zones below Level 1 are split by process line and, where applicable, by safety integrity level. Level 0 field devices sit inside their Level 1 zone unless the architecture calls for an explicit field zone with its own conduit.

Monitoring is layered. OT-aware detection at the conduit boundaries. Configuration baselining inside the control zones. A unified OT event stream feeding an OT-aware analysis layer. Selected, contextualised alerts forwarded to the enterprise SOC for organisational response.

Operations sit on top of all of it. The drawing is not the programme. The drawing is what the programme operates against. Change control owns the conduit rulesets. Vulnerability management owns the patch-staging cadence. Identity governance owns the IDMZ accounts. Incident response owns the event-stream review and the playbooks. Each of those operational disciplines has a clear interface against the design.

Taking it into deployment

The reference architecture is the start of the design conversation, not the end. Every operator has constraints the generic picture does not capture. Legacy supervisory clusters that cannot be split without an outage window. Vendor remote-access requirements that were never designed for an IDMZ jump host. Sites where physical-layer segmentation is not feasible and the work has to be done in software.

Three things make the difference between a defensible reference architecture on a slide deck and a defensible reference architecture in operation.

Treat the drawing as a versioned artefact. Number every zone. Number every conduit. Maintain a ruleset register. Tie every change to the register, not to a one-off firewall configuration commit. Auditors recognise this. So do successor engineers six years from now.

Build the operating model alongside the design. A zone is owned by a named team. A conduit ruleset is reviewed on a defined cadence. An IDMZ broker has a runbook. The architecture lives as long as someone is responsible for keeping it true.

Test the boundaries. A conduit ruleset that has never been validated against an attempted policy violation is a hypothesis. Periodic boundary tests, run in coordination with operations, are how the hypothesis becomes evidence. The test results feed back into the design, the ruleset, and the framework attestations above.

That is the bridge from design to operation. The drawing earns its place by surviving contact with reality.

Where the three layers meet

This was a three-post series for a reason. The structural layer, the framework layer, and the design layer are three different questions.

The structural layer asks what the environment actually does. ISA-95 functional hierarchy. Every asset placed against a function it performs. Without this, the rest is hand-waving.

The framework layer asks who needs evidence of what. CIRMP for the regulator. NIST CSF 2.0 for the board. IEC 62443 for the operations team. ISO 27019 where an ISO 27001 footprint already exists. Each one earns its place by what it produces for a specific audience.

The design layer turns both of the layers above into something that can be built and operated. Zones. Conduits. The IDMZ as the load-bearing element. Controls placed against the seven foundational requirements at each level. A reference architecture that survives contact with vendors, auditors, and incidents.

Three layers. Each one depending on the one below. Each one earning its keep with a specific audience. An Australian OT programme that has all three running coherently is a programme that defends what it is supposed to defend, reports what it is supposed to report, and recovers from what it is supposed to recover from.

That is the work.

Talk to our OT consulting team

Whether you are pre-CIRMP and starting from scratch, mid-programme and trying to make three frameworks operate as one, or living with a reference architecture that no longer matches the plant it was drawn for, our consulting team works the whole stack. Functional hierarchy, framework selection, design, deployment, and the operating model that keeps it true. Start a conversation with us if any of that lands.

—