Network Segmentation
for Pharma SCADA
DMZ and Firewalls

Segmentation vs Isolation — The Right Goal

The goal of network segmentation on a pharma SCADA project is not to make the OT network completely unreachable from the outside world — that is isolation, and it is rarely achievable or even desirable. The goal is controlled connectivity: every communication path between the OT network and any other network is explicitly defined, approved, documented, and verified. Anything not explicitly permitted is blocked by default. That is the principle that Annex 11 §12 requires and that IEC 62443 formalises as the zone-and-conduit model.

In practice this means your pharma SCADA project needs to answer three questions with engineering documentation: What zones exist and what is in each zone? What conduits — approved communication paths — exist between zones? What is the mechanism that enforces those conduits and blocks everything else? The answers live in the HDS, and they are verified at IQ. If you cannot answer all three questions with specific, verifiable statements, your segmentation design is not complete.

DMZ Architecture — Two Firewalls, One Buffer Zone

A DMZ (demilitarised zone) is a network segment that sits between two firewalls — an outer firewall facing the corporate IT network and an inner firewall protecting the OT network. Devices in the DMZ can communicate (in a controlled way) with both sides, but a device on the corporate network cannot pass directly through the DMZ into the OT network. It must stop at the DMZ boundary.

This two-firewall architecture is the minimum standard for pharma OT systems that have any connectivity to corporate IT — which includes practically every system that reports data to LIMS, ERP, or a remote monitoring platform. A single firewall between OT and IT is not sufficient because a misconfiguration or compromise of that single device gives an attacker direct access to the OT network.

What Lives in the DMZ — and What Does Not

The DMZ is not a dumping ground for anything that needs to talk to both networks. Every device placed in the DMZ increases the attack surface and requires its own firewall rules. The devices that belong in a pharma OT DMZ are specific and their function is well-defined.

Data replication / historian mirror server. This server receives read-only process data pushed from the OT historian and makes it available to the corporate LIMS or reporting systems. The keyword is push — the OT historian initiates the outbound connection into the DMZ; the DMZ server never reaches into the OT network to pull data. This is a fundamental security principle: OT-initiated outbound connections to a DMZ buffer are acceptable; IT-initiated inbound connections to OT are not.

VPN concentrator / jump host for remote access. All remote access to the OT network must route through a jump host in the DMZ. No direct VPN tunnel from a corporate or external network into the OT zone. The jump host authenticates the remote user, logs the session start and end, and provides a controlled gateway. The remote access implementation for pharma SCADA requires this architecture to satisfy Annex 11 §12.

Patch distribution server. Operating system and antivirus patches for OT workstations are pulled from this DMZ server rather than from the internet or corporate patch management infrastructure. The OT workstations initiate the connection outbound to the DMZ patch server — they never connect to the internet or corporate network directly.

What does not belong in the DMZ: production databases, historian primary servers, SCADA application servers, engineering workstations. If a device holds GMP data or can modify control system configuration, it belongs in the OT zone, not the DMZ.

Building the Firewall Rule Set for IQ

The firewall rule set is the document that turns network architecture intent into verifiable engineering. On a pharma project, the rule set is part of the HDS — specifically HDS Section 7.3 — and every rule must be specific enough for an IQ verifier to check it against the live firewall configuration. A rule that says "permit OPC-UA traffic" is not verifiable. A rule that says "FW-RULE-007: TCP 4840 inbound from 192.168.20.10 (SCADA server) to 192.168.10.5 (PLC), permitted" is verifiable.

The table above shows the pattern. Every rule has a reference ID that appears in both the HDS and the IQ verification protocol. The IQ verifier matches each rule ID to the live firewall configuration and records the result. FW-RULE-006 and FW-RULE-002 are the critical deny rules — they are what make the segmentation meaningful. Without explicit default-deny rules, permitted rules alone are not sufficient.

The Default-Deny Principle

Every firewall managing OT network boundaries must be configured on a default-deny basis: everything is blocked unless explicitly permitted. This is not the default configuration on most firewalls — many ship with permissive defaults. On a pharma project the IQ must verify that the firewall policy base ends with an explicit deny-all rule and that this rule is documented in the HDS.

The practical implication is that when a new interface is required between systems — say the site decides to add a data connection from the historian to a new reporting platform — that connection cannot be enabled by reconfiguring the application. It requires a change control that produces a new firewall rule, an updated HDS, and an IQ reverification of the firewall configuration. This is intentional friction — it makes every new network path a deliberate, documented decision rather than an ad-hoc IT configuration change. The change control process for validated systems must explicitly address network topology changes as requiring HDS amendment and partial re-IQ.

Connection to Open vs Closed Systems

The segmentation architecture you choose directly determines your 21 CFR Part 11 open vs closed system classification. A closed system is one where access is controlled by the system owners — typically a system where all users are employees of the operating company and the network is not reachable from outside the controlled environment. An open system is one where system access is not so controlled — typically any system with external network connectivity.

If your pharma SCADA has a DMZ connection to a LIMS that is accessible from outside the facility, you may have an open system classification under 21 CFR Part 11, which carries additional requirements. The network architecture documentation needs to be clear about which systems are on which side of which boundary, because the Part 11 classification drives your access control and audit trail requirements.

What IQ Connectivity Tests Look Like

The IQ network verification is not just reviewing documentation — it involves active testing. The IQ team must demonstrate that the firewall rules work as documented. For each critical deny rule, a test must be performed: a device on the source side attempts a connection to the destination side, and the result (blocked) is recorded with the source IP, destination IP, port, and timestamp.

• Corporate laptop pings SCADA server IP — result must be: no response / destination host unreachable
• Corporate laptop attempts TCP port 4840 to PLC IP — result must be: connection refused or timed out
• DMZ replication server attempts inbound SQL connection to historian primary — result must be: blocked at inner firewall
• SCADA server attempts OPC-UA connection to PLC — result must be: connection established (permitted conduit positive test)
• Firewall rule base exported and compared to HDS Section 7.3 rule table — all rules present, no additional undocumented rules

That last check — verifying there are no undocumented rules — is important. Firewall rule bases accumulate temporary rules, test rules, and legacy permits over time. At IQ the rule base must match the HDS exactly. Any rule present in the firewall but absent from the HDS is an undocumented conduit and a potential finding.

Segmentation and the SCADA Historian — The Data Path

Understanding the data path through the segmented network is essential for getting the firewall rules right. When you configure the SCADA historian for GMP, the historian server lives in the OT supervision zone. The data it holds is the source of truth for audit trails and batch records. Any connection path that allows a corporate-side device to write to the historian database is a data integrity risk.

The correct architecture is: historian primary in the OT zone (read-write, protected); historian mirror or replication target in the DMZ (read-only replica, refreshed by push from OT); LIMS and ERP connect to the DMZ mirror only, never to the OT primary. This means the firewall rules for historian access always permit outbound push from OT to DMZ and deny inbound connections from DMZ to the OT historian. If your firewall rule set does not reflect this pattern, your historian primary is reachable from the corporate network and your data integrity controls are incomplete.