Network, Cloud & Endpoint Security for GxP Systems
Segmentation is what stops an ordinary compromise becoming a manufacturing incident. In a plant where the office network and the control network are reachable from one another, a phishing email is a production risk. The technical estate — network architecture, secure configuration, cloud workloads, endpoints and remote access — is where that reachability is either constrained or accidentally granted.
What an explainer is not
A topic explainer is SPEQ’s synthesis of what a practice involves, cited to the standards that govern it. It does not reproduce their text, and it does not determine which of them apply to your product or process.
[ POSITION IN THE FRAMEWORK ]
7 DIMENSIONS · 24 LINKSMoving a GxP system to a hosted platform moves the controls, not the accountability: the regulated organisation still has to demonstrate the record is attributable, complete and unaltered on infrastructure it does not run.
06 · QUALITY MATURITY — NETWORK, CLOUD & ENDPOINT SECURITY FOR GXP SYSTEMS, REACTIVE TO ADAPTIVE
Cloud systems are procured by function and connected. The provider’s certifications are treated as the site’s compliance.
Providers are assessed at selection and their certifications are on file, but nobody has established which controls the site retains and which the provider holds.
The shared responsibility boundary is written down per system, the site’s own controls are implemented on its side of it, and the provider’s change notification is contractual.
Provider performance and change are monitored in service rather than assessed once, and the endpoint estate reaching these systems is managed to the same standard.
Architecture assumes compromise somewhere: segmentation, least privilege and encryption mean no single failure puts a regulated record beyond reconstruction.
SPEQ’s shared five-stage progression, labelled synthesis — not the FDA QMM rating scale. Where does your organization sit? Score your quality system →
07 · REGULATORY & EVIDENCE
GOVERNING STANDARDS · 5
Derived from the 5 standards SPEQ maps to this subject, across 4 regulatory bodies: EMA, ISO, IEC, EC.
RECORDS & OBJECTIVE EVIDENCE
- The shared responsibility statement per hosted GxP system
- Provider assessment and certification review, with what the site verified independently
- Change notification obligations, and records of changes notified
- Endpoint controls for devices accessing regulated systems
- Encryption and key management arrangements for regulated data at rest and in transit
COMMON INSPECTION FINDINGS
- A provider certificate treated as the site’s own qualification of the system
- No documented responsibility boundary, so controls fall between site and provider
- Provider changes reaching production without assessment of validated state
- Unmanaged endpoints with access to systems holding regulated records
- Data location and transfer arrangements unknown to the regulated organisation
Segmentation, and why flat networks persist
The zone-and-conduit model in IEC 62443 makes the reachable set of a control system an explicit design decision: assets sharing a security requirement are grouped into a zone, every permitted path between zones is a defined conduit, and everything else is denied. IEC 62443-3-3 then states what a system must be capable of at a given security level, against seven foundational requirements including restricted data flow.
Flat networks persist not through ignorance but through accumulated convenience. A link opened during commissioning, a temporary route to solve a support problem, a reporting tool that needed direct historian access — each was justified and none was removed. This is why the useful control is periodic verification that actual segmentation matches the designed zones, performed against the running network rather than the drawing. The drawing is always correct.
Cloud: the responsibility line is the whole question
Cloud providers publish a shared-responsibility model, and the recurring failure is not reading which side of the line a given control falls on. The provider secures the infrastructure; the customer configures the service, manages identities and access, classifies the data, and sets retention. Almost every widely reported cloud data exposure has been a customer-side configuration, not a provider breach.
For regulated workloads two further obligations attach. The regulated user remains accountable under Annex 11 for supplier assessment and for the validated state, whoever operates the infrastructure — contracts allocate liability, they do not transfer regulatory accountability. And where personal data crosses regions, GDPR Chapter V requires the transfer to be lawful, which is an architecture constraint rather than a paperwork exercise. Read the scope of a provider attestation before accepting it: it frequently excludes the specific service in question.
Endpoints that cannot be touched
Standard endpoint management assumes a machine that can be patched on a schedule, run an agent, and reboot when told. Regulated environments are full of machines that fail all three: the workstation that is part of a qualified instrument configuration, the HMI whose operating system the vendor will not support an update to, the standalone analyser with a local account and no user management.
Treating these as exceptions to be granted and forgotten is how exposure accumulates. The defensible pattern is a documented exception with a compensating control and a review date — typically isolation from general network access, removal of unnecessary services, media controls, and tighter monitoring — so that an unpatchable endpoint is contained rather than merely tolerated. Application allow-listing is often the more workable protection on these machines than signature-based tooling that needs constant updates the vendor will not certify.
Remote access is the highest-value control here
Every regulated site has vendor remote access, and most of it was arranged during commissioning and never revisited. The standing tunnel terminating inside the manufacturing network, with credentials nobody at the site controls, opened for a validation issue years ago, is the single most common serious finding in OT security assessments.
IEC 62443-2-1 expects remote and third-party access to be granted per session rather than held as a standing connection, and the same expectation is reasonable for any GxP system. Per-session access with approval, monitoring and automatic expiry converts an open door into a recorded event — and it produces the access records an inspector or an investigator will ask for after an incident.
SPEQ interpretation — a security control on a validated system is a change
The tension that defines this domain is that the standard security response — deploy the agent, push the configuration, force the reboot — is a change to a validated system, and the change-control burden is real rather than obstructive. Teams resolve this badly in both directions: security deploys anyway and breaks a qualified configuration, or quality blocks everything and the estate stays exposed.
The workable resolution is agreeing the classification in advance. A standing assessment of which control classes are low-impact and re-verified by a defined regression set, which require targeted requalification, and which are not deployable on a given platform and need a compensating control instead. Made once, that agreement lets routine hardening proceed at security speed and reserves the change-control conversation for the changes that genuinely warrant it.
FREQUENTLY ASKED
Who is responsible for security in a cloud-hosted GxP system?
Both parties, on a published shared-responsibility line the customer must actually read. The provider secures the infrastructure; the customer configures the service, manages access, classifies data and sets retention. Under Annex 11 the regulated user also remains accountable for supplier assessment and the validated state regardless of who operates the infrastructure — contracts allocate liability, not regulatory accountability.
What do you do about an endpoint that cannot be patched?
Document it as an exception with a compensating control and a review date rather than tolerating it silently. Typical compensations are isolation from general network access, removal of unnecessary services, media controls and tighter monitoring; application allow-listing is often more workable than signature-based tooling the vendor will not certify.
Why is vendor remote access such a common finding?
Because it is arranged during commissioning to solve an urgent problem and then never revisited, leaving a standing tunnel into the manufacturing network with credentials the site does not control. IEC 62443-2-1 expects per-session access with approval, monitoring and expiry, which also produces the access records anyone investigating an incident will need.
Does deploying a security agent on a validated system require change control?
Yes — it is a change to a validated system. The proportionate approach is to classify control types in advance: which are low-impact and covered by a defined regression set, which need targeted requalification, and which cannot be deployed on a given platform and need a compensating control instead. That agreement lets routine hardening proceed without a bespoke debate each time.