OT Network Architecture
for Pharma
The Purdue Model in Practice

Why the Purdue Model Matters on a Pharma Project

Most automation engineers have seen the Purdue Model on a slide deck. Fewer have had to document it in a Hardware Design Specification, verify it during IQ, and defend the zone boundaries to a cybersecurity auditor during an EU GMP Annex 11 inspection. On a pharma project the model stops being academic and becomes a contractual deliverable — it drives your HDS Section 7, your IQ network verification checklist, and your URS cybersecurity requirements.

The reason regulators care about network architecture is data integrity. Annex 11 requires that computerised systems are protected from unauthorised access and that audit trails are tamper-proof. A flat network where a corporate laptop can reach the historian database directly is not compliant — not because of a rule that says "use the Purdue Model," but because the risk of unauthorised modification is demonstrably uncontrolled. The Purdue Model is the industry-accepted solution to that risk.

The Five Zones — What Each Contains

The Purdue Model organises automation hardware into numbered levels. On a pharma project these levels map directly to the components you are specifying, supplying, and validating. The HDS must describe every zone, every component that lives in each zone, and the mechanism that enforces the boundary between zones.

Level 0 is your field layer — sensors and actuators. No compute, no configuration, not in scope for cybersecurity segregation beyond physical access control. Level 1 is the PLC — it executes all control logic, interlock functions, and alarm generation autonomously, regardless of what the higher layers are doing. The critical design principle for pharma is that the PLC must continue to protect product and personnel even if the SCADA server fails. If your system can only enforce a temperature interlock because the SCADA is telling it to, you have a compliance problem.

Level 2 is where your SCADA server, historian, HMI stations, and engineering workstation live. This entire zone must be on a dedicated network segment — typically a VLAN — that is not directly reachable from the corporate network. The zone boundary is enforced at the switch level by VLAN assignment, not by firewall rules. Firewall rules come at the boundary between the OT zone and the DMZ.

The DMZ — What It Actually Does

The DMZ is the most misunderstood zone in a pharma OT architecture. It is not a firewall. It is a buffer zone between the OT network and the corporate IT network, occupied by servers that need to talk to both sides — but in a controlled, one-directional, or strictly-limited way.

On a typical pharma site the DMZ contains: a data replication server that pushes read-only historian data to the ERP or LIMS system; a patch management server that distributes approved patches to OT workstations without giving the corporate network direct OT access; and if remote access is required, a jump host or VPN concentrator that logs all sessions. The key security principle is that no device in the DMZ should be able to initiate a connection into the OT control or supervision zone. Traffic flow is from OT toward IT, not from IT toward OT. Your firewall rules document this explicitly, and the IQ team verifies it.

How This Maps to the HDS

The Hardware Design Specification is where the Purdue Model becomes an engineering document rather than a diagram. HDS Section 7 (Network Infrastructure and Cybersecurity Architecture) must describe every zone, the components within each zone, the VLAN IDs or physical switch port assignments that enforce zone membership, and the firewall rule set that controls inter-zone traffic.

The firewall rules must be specific. A rule that says "firewall configured to block unauthorised access" does not satisfy IQ — the IQ verifier cannot check it. A rule that says "FW-RULE-003: TCP port 1433 (SQL Server) inbound from DMZ to OT-SUP VLAN is blocked" can be verified by inspecting the firewall configuration. Every IQ network verification step must have a corresponding specific statement in the HDS to verify against. If the HDS is vague, the IQ will be vague, and that is a finding waiting to happen.

VLAN Design for a Pharma OT Network

VLANs are the standard mechanism for segmenting the OT supervision zone from other traffic on the same physical switch infrastructure. On a small pharma project you may have a single managed switch in the server rack that carries both OT supervision traffic and management traffic — VLANs keep those logically separated without requiring separate physical switches for everything.

The critical requirement for a GMP implementation is that VLAN assignment is enforced on the switch port, not on the device. A device that can reconfigure its own VLAN membership defeats the segregation. In practice this means VLAN membership must be configured at the switch port level (access port assignment), and the switch must not allow devices to trunk and negotiate their own VLAN membership. The IQ verifier will check the switch configuration file and confirm that OT supervision ports are assigned to the OT VLAN as access ports.

What IQ Verifies on the Network

The IQ network verification section is where the abstract architecture becomes a physical checklist. The IQ team does not trust the HDS — they verify it. For every network component listed in HDS Section 1.3, the IQ must confirm: that the device is the correct model and firmware version, that the configuration matches the HDS, and that the security configuration is active. This means the IQ verifier needs access to the switch CLI or management interface, the firewall rule base, and potentially the VLAN assignment table.

The firewall connectivity test (FW-IQ-003) is important. It is not enough to document the firewall rules — you must demonstrate the rules work. An IQ verifier will take a corporate laptop, attempt to ping or reach the SCADA server or historian directly, and record the result. If the result is anything other than blocked, the IQ has a failure and the network architecture is non-compliant. This test requires coordination with site IT to ensure the corporate laptop has a genuine corporate IP address, not an OT subnet address.

What Goes in the URS for Network Architecture

The URS cybersecurity requirements define the boundary conditions that the HDS must satisfy. They do not specify implementation — they state what must be achieved. This is an important distinction: if the URS says "the OT network must be physically and logically segregated from the corporate IT network," the HDS can satisfy this with VLANs, dedicated switches, or fibre isolation. If the URS says "use Cisco switches with specific firmware," you have locked your design to a vendor.

The URS cybersecurity requirements that drive OT network architecture typically include: segregation of OT and IT zones, controlled access to the OT network from external networks, audit logging of all remote access sessions, a documented and approved firewall rule set, and protection of the historian database from unauthorised modification. Those requirements cascade into the HDS zone design, the firewall rules, and ultimately into the SCADA user management and audit trail configuration verified in the OQ.

How the SCADA Project Structure Connects to the Network

The network zone model is not just an infrastructure concern — it defines where the SCADA server and historian physically live and how the SCADA communicates with the PLC. When you structure a SCADA project for pharma validation, the server is in the OT supervision zone (VLAN 10), the PLC is in the OT control zone (VLAN 20), and communication between them crosses a VLAN boundary on the managed switch. The switch must have an inter-VLAN routing rule that permits OPC-UA or the relevant PLC driver protocol on a specific port — and that rule is documented in the HDS firewall/routing section and verified at IQ.

Similarly, when you define the PLC project structure for pharma validation, the choice of communication protocol between the PLC and SCADA affects the firewall rules. OPC-UA uses TCP port 4840 by default. Siemens S7 driver uses TCP port 102. These are the port numbers that appear in your HDS firewall rules and your IQ connectivity tests. Get them specific in the HDS — the IQ team needs exact port numbers, not "standard OPC-UA ports."

The Engineering Workstation — The Most Overlooked Zone Member

The engineering workstation — the machine that can download software to the PLC — is the highest-risk device in the OT network from a validation integrity perspective. If someone can download modified PLC code to a production system without formal change control, the validated state is broken. The engineering workstation must therefore be: assigned to the OT management VLAN (not the supervision VLAN), physically secured with restricted access, under software change control (only the approved engineering environment installed), and listed in the HDS with its hostname, IP address, and role.

Annex 11 does not prohibit remote engineering access to OT systems, but it requires that all remote sessions are logged and that access control is role-based. If your site allows remote PLC downloads over a VPN, that VPN session must appear in the SCADA or network audit trail, and the ability to initiate a download must be restricted to the engineering workstation role. This is a requirement that connects network architecture to your access control design.

Where to Go Next

This article covers the zone architecture and how it maps to the HDS and IQ. The adjacent topics that build on this foundation are network segmentation in more depth — specifically how to design and document the DMZ and firewall rule set for a pharma SCADA project — and cybersecurity in the broader OT context. The network segmentation article goes into firewall rule construction, DMZ design patterns, and what a cybersecurity auditor looks for. The IEC 62443 and pharma OT cybersecurity article covers the zone-and-conduit model in more depth and how to align a pharma project with the cybersecurity framework GAMP 5 2nd Edition recommends.