A supplier needs remote access to investigate a controller fault during production. The connection is available, but nobody can state which assets it reaches, who authorizes the session or how changes will be reconciled with the approved configuration. The immediate support problem exposes an architectural weakness. OT cybersecurity for GMP manufacturing must make legitimate operation and maintenance controlled, observable and recoverable.
The objective is to reduce cyber risk while respecting physical process behaviour, safety, availability and record requirements. Security controls and GMP validation controls interact, but they are not interchangeable. A validated process application can remain insecure, and a hardened server can still execute an incorrect or inadequately verified manufacturing function.
Start with assets, functions and dependencies
Maintain an inventory that identifies controllers, operator stations, servers, network devices, engineering workstations, interfaces and supporting services. Record ownership, software and firmware versions, support status and critical dependencies in proportion to the risk. Include portable service equipment and supplier-managed components that may be absent from central IT inventories.
Link assets to functions and consequences. Determine which failures can affect product quality, process control, data integrity, safety or continuity. A seemingly minor service can become critical if it provides identity, time, name resolution or licence functions to several systems. Understand those dependencies before applying isolation or shutdown actions.
[GUIDANCE] NIST SP 800-82 Revision 3 addresses OT security with attention to operational and physical-process constraints. At this article's review date, Revision 4 was an initial public draft, not the final replacement. Use the operative guidance with current threat and vulnerability information relevant to the installed assets.
Define zones and conduits from assessed needs
Group assets according to function, risk and required trust relationships. Define the communications that must cross boundaries, including direction, service, identity and purpose. A network diagram should show maintenance, backup and administration paths as well as production data flows. Uncontrolled secondary routes can undermine otherwise careful segmentation.
Use firewalls and other controls to enforce justified exchanges. Avoid broad permanent access merely because a supplier cannot initially describe its requirements. Test the permitted flows and the operational consequences of blocked or unavailable services. A segmentation design must remain maintainable when equipment is added or a service address changes.
[STANDARD] The ISA/IEC 62443 series addresses industrial automation and control security through several parts with different scopes and editions. Its zones and conduits concepts support risk-based design; they do not prescribe one network topology for every pharmaceutical site. Select applicable parts and responsibilities deliberately.
Manage identity and privileged access
Define roles for operation, engineering, administration and supplier support. Restrict privileges to the functions required and separate routine use from elevated maintenance where appropriate. Maintain accountability for consequential actions and manage service identities according to their purpose rather than treating them as ordinary user accounts.
Assess authentication dependencies. Central identity can improve governance while creating a dependency that must be understood during outages. Define controlled emergency access and its subsequent review. Multi-factor authentication is valuable where applicable, especially for remote or privileged access, but implementation must account for the capabilities and operational constraints of the actual system.
Control credentials, certificates and trust relationships throughout their lifecycle. Assign owners for renewal, revocation and recovery. Avoid embedding unmanaged shared secrets in scripts or vendor configuration files. The design should enable legitimate support without making unrestricted access the only practical way to resolve an incident.
Make remote support a bounded operational process
Remote access should have an identified requester, authorizer, purpose, scope and duration. Use an approved access path with appropriate authentication, monitoring and session termination. Define which systems can be reached and whether file transfer, clipboard use or configuration changes are permitted for the task.
Coordinate the session with production and the responsible system owner. A supplier may understand its equipment but not the site's current manufacturing state or connected dependencies. Establish communication and stop conditions before intervention. Record consequential actions and reconcile changes with the controlled configuration and maintenance record.
Test revocation and closure. Disabling one account may not terminate an existing session or remove another persistent route. Verify that temporary access ends as intended and that unattended remote tools are governed. Include subcontractors and emergency support in the agreement rather than assuming that the main supplier controls every participant.
Assess vulnerabilities with process context
Combine asset information, supplier advisories, relevant vulnerability information and exposure analysis. Prioritize according to the affected function, credible access paths and potential consequences. A severity score is useful input but does not by itself determine the safest remediation sequence for a running process.
Use discovery and scanning methods appropriate to the equipment. Some OT assets can be sensitive to intrusive techniques. Coordinate assessment methods with knowledgeable personnel and suppliers, using controlled environments or passive approaches where justified. Security assessment should improve understanding without unexpectedly disrupting production.
Track decisions and compensating controls. If a vulnerability cannot immediately be remediated, document exposure reduction, monitoring, operational constraints and a responsible resolution plan. “Validated system” is not a sufficient reason to ignore vulnerabilities indefinitely; equally, an unassessed emergency change can introduce process or record failures.
Engineer patching and endpoint controls
Define a risk-based patch process covering assessment, compatibility, testing, deployment and recovery. Consider operating systems, application software, firmware and supporting components. Coordinate vendor support statements with the site's own intended-use assessment; neither unsupported assumptions nor blanket supplier assurances are adequate.
Use representative testing for consequential changes. Verify affected control, interface, record and recovery functions, and plan rollback or restoration if deployment fails. Schedule implementation with the process state and continuity requirements in mind. There is no universal GMP patch frequency appropriate to every controller or server.
Endpoint protection, application allowlisting and removable-media controls can reduce risk where technically suitable. Assess their effect on process applications, performance and maintenance. Define handling of legitimate updates and exceptions so that a protective control does not become an unmanaged bypass. Record exclusions with a rationale and review them when conditions change.
Protect backups and demonstrate recovery
Identify the complete recovery set: controller programs, recipes, application configuration, databases, audit information, licences, installation media, keys and infrastructure settings as applicable. Protect recovery copies from unauthorized modification and from failures that could affect production systems. Replication alone may propagate corruption or malicious changes.
Derive recovery time and acceptable data loss from process consequences, record obligations and continuity needs. Define recovery order because services can depend on identity, time, storage or network configuration. Recovery of a server image does not necessarily restore the manufacturing workflow or reconcile its records.
Exercise a representative restore and record the prerequisites, versions and limitations. Confirm that recovered data remain interpretable and that the system returns to an acceptable controlled state. Backup frequency and restore-test timing should be justified for the system; do not present arbitrary intervals as universal regulatory requirements.
Prepare incident response for manufacturing consequences
Assign responsibilities across production, automation, IT security, quality, maintenance and suppliers. Define how suspected incidents are recognized, escalated and assessed. The response needs to consider physical process conditions and product impact, not only the state of computers.
Establish coordinated containment options. Disconnecting a network may stop malicious communication but also remove supervision, records or essential services. Pre-assess credible options and the conditions for using them. Preserve relevant evidence while prioritizing safe and controlled operations through authorized site procedures.
Define return-to-service criteria. Confirm configuration integrity, required functionality, record reconciliation and any product-quality assessment before resuming affected use. An antivirus scan showing no detection is not by itself a complete release basis. Capture lessons from exercises and incidents and update the architecture or procedures where necessary.
Keep security and GMP assurance responsibilities distinct
| Control or activity | Security purpose | Related GMP assurance question |
|---|---|---|
| Network segmentation | Restrict unauthorized or unnecessary communication | Do permitted and blocked flows preserve the intended process and records? |
| Privileged access management | Control elevated actions and accountability | Are consequential changes authorized, traceable and assessed? |
| Patch deployment | Reduce known vulnerabilities | Does the changed configuration remain fit for intended use? |
| Protected recovery copies | Support recovery after compromise or loss | Can the complete system and necessary records be restored correctly? |
| Security monitoring | Detect suspicious activity | Can relevant incidents be correlated with manufacturing and record impact? |
The columns overlap in evidence but retain different objectives. Plan coordinated work so that security changes receive appropriate engineering assessment and GMP processes do not become barriers to necessary risk reduction.
Worked example: an unsupported supervisory workstation
An illustrative utility system uses a supervisory workstation whose operating system is no longer supported. The controller can operate independently under defined conditions, but the workstation provides operator access and historical retrieval. Replacing it immediately during production would introduce unassessed interface and record risks.
The site inventories dependencies, limits unnecessary communication and establishes a controlled maintenance route while preparing a supported replacement. It confirms recovery copies and spare arrangements, assesses relevant exposure and defines temporary operating controls. These measures reduce risk during a time-bounded migration plan; they do not make unsupported software permanently acceptable.
The replacement is tested for communication, operator actions, historical access, time behaviour and recovery. Cutover includes configuration verification and record reconciliation. Security and quality representatives assess different aspects of the same change, with production and automation confirming operational readiness. The final decision is specific to the system's risk, exposure and intended use.
Specify supplier responsibilities and lifecycle evidence
Procurement should address supported versions, vulnerability notification, patch compatibility, remote access, incident cooperation and end-of-support notice. Clarify responsibilities for underlying operating systems and third-party components. A supplier's support contract may exclude precisely the infrastructure the site assumes is covered.
Request an inventory of relevant software components or equivalent information suited to the solution, along with a process for security advisories and updates. Confirm that the site can obtain configuration and records needed for recovery or migration. Include secure retirement and removal of remote access when equipment or service contracts end.
Maintain a register of accepted limitations, owners and review conditions. Reassess when process use, connectivity, threats or support status change. Link the work to legacy migration and supplier selection so that security is sustained through the commercial and technical lifecycle.
Verify controls without losing the operational context
Acceptance should include authorized and unauthorized access attempts, permitted and blocked communication paths, remote-session closure and recovery of a representative service. Define the test scope and safeguards with system owners. Record the configuration tested and the actual observations, including any operational effects of the security control.
For monitoring, verify that a relevant event reaches an accountable person with enough context to act. A log retained somewhere on a server is not necessarily an operational detection capability. Agree escalation and investigation responsibilities and distinguish security events from GMP audit-trail review requirements.
Exercise the response to a plausible incident through a controlled discussion or simulation. Include production status, supplier availability, communications, record preservation and return-to-service decisions. Identify dependencies that the team could not resolve and turn them into assigned actions. The exercise is useful when it exposes uncertainty before a real event, rather than producing an unsupported claim that every incident can be handled.
Keep the evidence proportionate to the risk and the control's intended purpose. A comprehensive penetration test is not automatically the appropriate acceptance activity for every isolated legacy controller, while a superficial connectivity check is inadequate for a newly exposed remote-access service.
Release checks and applicable framework
[REGULATORY REQUIREMENT] Apply relevant GMP computerized-system, documentation and change controls to the intended use. They complement cybersecurity risk management rather than replacing it. [GUIDEGXP RECOMMENDATION] Before release, confirm asset ownership, approved flows, controlled privileged and remote access, vulnerability handling, usable recovery evidence and coordinated incident responsibilities.
Review credible failure scenarios with the process owner and verify the configured controls. For connected utilities and facilities, use the process context in Critical Utilities Systems and Cleanrooms & HVAC Systems. Return to the Automation & Digital Systems hub for the complete engineering scope.
Primary references and status
Reviewed 23 September 2026: NIST SP 800-82 Revision 3, final September 2023; ISA/IEC 62443 series; EU GMP EudraLex Volume 4. The NIST page announced Revision 4 as an initial public draft on 21 September 2026; it was not a final replacement at review. The ISA/IEC series contains separately dated parts, so applicability must be assessed by part. Examples and comparison questions are original GuideGxP engineering recommendations.
