Remote Access to
Pharma SCADA —
How to Implement It Compliantly

Why Remote Access Is a GMP Topic, Not Just an IT Topic

EU GMP Annex 11 Clause 13 requires that remote access to a computerised system is controlled and that a record is kept of all remote access activities. This is not a cybersecurity recommendation — it is a GMP requirement with inspection implications. An MHRA or FDA inspector reviewing a site's computerised system controls will ask: how is remote access to your SCADA controlled, who can grant it, what records are kept, and how long are they retained. If the answers are "the IT team manages it," "anyone with the VPN credentials," "there's a log somewhere," and "not sure," that is a significant finding.

The GMP concern is data integrity. A remote session that can modify process setpoints, adjust alarm limits, download PLC code, or change user accounts — without a documented authorisation, without an audit trail, without an on-site presence requirement — is an uncontrolled access path to GMP-critical data. The validation evidence for the system assumes the validated configuration is intact. An undocumented remote modification breaks that assumption.

For system integrators building pharma SCADA systems, the remote access design is your responsibility. The SCADA and network architecture must implement the controls. The HDS documents them. The IQ verifies them. If a site inspection finds that remote access was not implemented or verified as designed, the SI's documentation is what gets scrutinised.

Network Zone Architecture — The Foundation

Compliant remote access to a pharma SCADA starts with correct network zone architecture. You cannot bolt compliant remote access onto a flat network. The zones define what remote access can reach — and what it cannot reach under any circumstances.

The critical design principle is that remote access terminates in Zone 2 (OT Supervision — SCADA Server, Historian, HMI workstations) and cannot reach Zone 1 (OT Control — PLC, safety relay, field I/O) under any circumstances. Firewall rule FW-008 is an absolute deny: no external connection can reach Zone 1. This is not configurable by the Administrator role — it is a hardware firewall rule that is verified at IQ and remains in the IQ evidence package for the life of the system.

The consequence is that PLC code download during a remote session is not possible. If a vendor engineer needs to download a code change to the PLC, they must be on-site. This is documented in FUNC-MNT-003: vendor remote access allows viewing diagnostic data and PLC status, but code download requires prior Change Control approval and an on-site Supervisor presence. This is not a restriction that makes remote support harder — it is a GMP control that prevents unauthorised code changes to a validated PLC from any remote location.

The Five Non-Negotiables for Compliant Remote Access

These five requirements must all be present. Any one missing creates a GMP gap.

• VPN with MFA — no direct inbound connections: All remote access to the OT network transits a VPN with multi-factor authentication. No direct RDP, no TeamViewer, no direct port forwarding. The VPN is the single controlled gateway — it enforces authentication before any OT resource is reachable. MFA is not optional: a username and password alone for remote access to a pharma SCADA does not meet the spirit of Annex 11 Clause 13 in a modern threat environment.
• Administrator-only session grant — per session: Remote access permission for any specific session is granted by the Administrator role, per session, for a specific purpose. There is no standing remote access permission. A vendor engineer does not have a persistent VPN credential that allows them to connect at any time. The Administrator grants access, the session runs, the access expires. The granting action is audit-trailed.
• Maximum 4-hour session duration with auto-expiry: Each remote session is time-limited to a maximum of 4 hours. When the session timer expires, the VPN connection is terminated automatically — the vendor engineer does not need to remember to disconnect. If the task requires more time, a new session must be granted. This prevents permanent or indefinitely long sessions.
• Full session log as GMP record: Every remote session generates a log entry containing: user identity (named individual, not a generic vendor account), source IP address, connection timestamp, session duration, and a summary of actions performed. This log is stored in the historian and retained for 7 years — the same retention period as all GMP records. This is not an IT system log — it is a GMP record that can be requested by an inspector.
• Audit trail entry for every remote session: In addition to the session log, every remote session start and end must generate an audit trail entry in the GMP audit trail. The audit trail entry carries the same fields as any other GMP event: user ID, timestamp, action description. This ensures the session is visible in the same audit trail reviewed during GMP inspections — not buried in a separate IT log file.

IQ Verification — What Gets Checked On-Site

Remote access controls are verified at IQ, not at OQ. The IQ is the installation qualification — it verifies that the system is built as designed. The remote access design is in the HDS (network zone architecture, firewall ruleset) and the FDS (FUNC-MNT-003, FUNC-CYB-002). The IQ checks that these designs were implemented correctly before functional testing begins.

The specific IQ checks for remote access are not pass/fail observations — they are documented verification steps with evidence attachments:

• VPN gateway installed and operational (IQ-CYB-020): Confirm the VPN gateway model, firmware version, and that MFA is enabled. The evidence is a screenshot of the VPN gateway configuration showing MFA enabled — not a verbal confirmation.
• Remote access test — Zone 2 only (IQ-CYB-021): Initiate a test VPN connection using authorised credentials plus MFA token. Confirm the connection succeeds and is limited to Zone 2. Then confirm Zone 1 is not reachable from the VPN session — attempt to ping a Zone 1 PLC IP address from the VPN session. Expected result: ping fails. This adversarial test is the evidence that FW-008 is working.
• Session log verification (IQ-CYB-022): After the test VPN session from IQ-CYB-021, verify that the session log entry was written to the historian RemoteAccess table. Verify the entry contains the required fields: user identity, source IP, connection timestamp. Attach the log entry as IQ-ATT-VPN-001. This connects the IQ evidence to the GMP record-keeping requirement — it proves the session logging is working before the system goes live.
• Firewall ruleset review (IQ-CYB-002): Compare the installed firewall rules against the HDS Section 7.3 table (firewall rules FW-001 to FW-009). Verify each rule: present, action correct (PERMIT/DENY), source and destination correct. Attach the firewall rule export as IQ-ATT-FW-001. The firewall ruleset export is the definitive evidence — "I checked the rules" is not.
• OT network isolation test (IQ-CYB-003 and IQ-CYB-004): From a corporate IT workstation, attempt to ping a Zone 1 PLC IP address — expected result: fail. From a Zone 2 workstation, attempt to ping an internet IP — expected result: fail. Both tests confirm the network segregation is functioning as designed.

Vendor Access During Ongoing Support

After go-live, the remote access process is governed by the SOP, not by informal arrangement. Every vendor remote access request follows the same sequence: vendor contacts the site Administrator with the reason for access and estimated duration, Administrator grants the time-limited session, vendor connects, session auto-expires, Administrator confirms the session log entry was generated and filed. If the vendor needs to take any action during the session that constitutes a GMP change (a setpoint modification, an RBAC change, a historian tag addition), that action must first be approved through change control — the remote session is for implementation after approval, not for making uncontrolled changes.

The session summary field in the session log requires the vendor engineer to document what actions were taken during the session. A blank summary field is not acceptable — the session log is a GMP record. If the vendor engineer only viewed diagnostic data and made no changes, the summary must say that explicitly. This field is what the QA reviewer reads when reviewing remote access records during a periodic review or an inspection preparation exercise.