VPN and Remote Access
for Validated Systems
What Compliance Actually Requires

The Compliance Basis for Remote Access Controls

Annex 11 §12 requires that computerised systems are protected from unauthorised access. §12.4 specifically addresses remote access, requiring that appropriate controls are in place for systems accessed externally. 21 CFR Part 11 connects through the open vs closed system classification — a system accessible via remote connection over infrastructure your organisation does not fully control may require the additional transmission security controls of §11.30.

The practical requirements that flow from these provisions are: every remote session must use a secure, encrypted connection (VPN or equivalent); every session must authenticate the user uniquely — no shared credentials, no generic "remote" accounts; every session must be logged with enough detail to reconstruct who did what from where and when; and the authorisation to open a remote session must be controlled by the system owner, not the remote user. These are not optional refinements — they are the minimum controls an Annex 11 inspector will expect to see documented and verified.

The Architecture — Why a Jump Host Is Required

The standard compliant architecture for remote access to a pharma OT system routes all remote sessions through a jump host (also called a bastion server or privileged access workstation) located in the DMZ. No direct VPN tunnel from the internet to the OT network is permitted — the path is always: remote user → VPN concentrator in DMZ → jump host in DMZ → target system in OT zone. The jump host is the single authorised gateway, and every session through it is logged.

The reason a direct VPN-to-OT-network tunnel is not acceptable is zone boundary integrity. A direct tunnel bypasses the inner firewall and places the remote device logically inside the OT zone. The jump host architecture preserves the zone boundary — the remote device connects only to the DMZ, and from the DMZ a separate authenticated session is initiated into the OT zone. This means two authentication events per remote session (VPN authentication plus jump host authentication), and two log entries.

MFA — When It Is Required and What Counts

Multi-factor authentication (MFA) is the standard for all remote access to OT systems in pharma. Annex 11 §12 does not prescribe MFA by name, but the access control requirement combined with the principle that remote access represents a higher risk than local access makes MFA the de facto minimum standard for any post-2022 pharma OT project. An Annex 11 inspection finding that a remote access VPN uses only password authentication, with no second factor, is foreseeable.

What counts as a second factor: a time-based one-time password (TOTP) authenticator app (Google Authenticator, Microsoft Authenticator); a hardware token (RSA SecurID, YubiKey); a certificate stored on a managed corporate device. What does not count: a second static password; a security question; an SMS code to an unregistered device. The HDS must specify which MFA method is implemented, and the IQ must verify it is active and enforced — typically by attempting to authenticate with only a password and confirming the session is rejected.

Session Logging — What the Log Must Capture

The remote access session log is a GMP record. It must be retained for the same period as other GMP records from the validated system — typically 7 years or the product lifecycle, whichever is longer — and it must be protected from modification. The log entries must include:

• User identity (unique user ID, not a shared account or generic remote access account)
• Source IP address of the remote device
• Session start timestamp — NTP-synchronised, matching the OT system time
• Session end timestamp — or last activity timestamp if session was force-terminated
• Authentication outcome (success or failure) — failed attempts must also be logged
• Target system accessed via the jump host (which OT device the user connected to)
• For sessions involving configuration changes: what was changed, verified in the validated system's own audit trail

The session log location matters. If the log only exists on the jump host server and the jump host is outside the validated system boundary, the log may not have the same protection as the validated system's audit trail. The preferred approach is for the jump host to forward session events to the SCADA or historian audit trail in addition to its own local log, so that remote access activity is visible within the validated system's GMP record set.

Authorisation Control — Who Opens the Session

The authorisation to initiate a remote session must be controlled by the site — not by the remote user. This means the VPN or jump host must be configured so that a remote user cannot self-service their own access. The typical implementation is time-limited access: the site administrator enables access for a specific user for a specific time window (e.g., 2 hours on Tuesday afternoon for a software update), and access is automatically revoked at the end of the window regardless of whether the session is still active.

For third-party vendor access — the most common source of remote access in OT environments — this means the vendor cannot access the system whenever they choose. Access requires a formal request, site approval, and time-limited enablement. This is a procedural control that must be documented in SOP-ADMIN-SYS-001 (System Administration SOP) and verified at OQ by demonstrating that vendor access cannot be initiated without site authorisation.

OQ Test Cases for Remote Access

Remote access controls are primarily verified in the OQ, after the IQ has confirmed the infrastructure is installed as designed. The remote access implementation article covers the SCADA-specific configuration — the OQ test cases for VPN and jump host controls focus on the access control and logging behaviour.