Remote Instrument Support: Authorisation and Controls

A remote connection lets a technician inspect an instrument error without entering the laboratory. It can also expose configurations, data and functions unnecessary for diagnosis. Authorisation therefore needs to describe a bounded intervention: who connects, to which system, for what task, with which rights and until when.

The endpoint is a documented decision on return to use. A closed connection or a “problem solved” message alone does not show that records remain intact and affected functions are reliable. The following organisational example requires local adaptation; it provides no instructions for configuring or bypassing real networks.

Define the intervention and the internal owner

The request should identify the instrument, software, version, fault, operational consequences and expected support outcome. Specify whether only observation and diagnosis are permitted or whether assessed changes are also included. Identify ongoing sequences, affected samples and other systems reachable from the workstation: an apparently local application may access shared data.

Appoint an internal owner to coordinate laboratory, IT and quality responsibilities. A support contract does not replace approval of the particular activity required by procedure. Verify the technician’s identity and organisation through established contacts, including during an urgent failure. Decide when analytical work must pause and how continuity will be managed without losing records.

Limit identity, duration and technical scope

Provide access attributable to the individual, with task-appropriate privileges, an authorised window and verifiable closure. Do not lend the analyst’s account or turn diagnostic access into permanent administration rights. The principles of user role management also apply to external personnel and emergency access.

IT should assess the channel, authentication, originating device and entry point against risk and company rules. Consider multifactor authentication, connection protection and limits on reachable systems. Calling the connection a “secure VPN” is insufficient: establish which actions and transfers it permits. Adopting a support tool or extending privileges requires the prescribed assessment, not an improvised technician decision.

Define which files may be viewed or transferred, their permitted destinations and who approves an external copy. Use test data when suitable; where real records are necessary, protect confidentiality, completeness and traceability. Screen sharing itself may reveal confidential information.

A before, during and after checklist

Link the checklist to an intervention identifier and record outcomes, evidence and exceptions instead of context-free ticks. This matrix is an operational proposal, not a mandatory regulatory form.

Supervision should enable an effective response: decide beforehand who can interrupt the session and who will be available. If the contact does not understand a proposed operation, obtain an explanation and competent assessment before allowing it.

Record activities and assess changes

Retain a report linking identity, start and end, affected instruments, actual work and outcome. A connection log evidences access; an application audit trail records particular record-related events; video shows what was captured on screen. These are not interchangeable. Video recording is not a universal requirement: justify need, proportionality, protection and retention in context.

Work affecting drivers, configuration, interfaces or data requires the assessment prescribed by change control and, where relevant, a deviation. Support must not delete files, overwrite results or remove audit trails to make an anomaly disappear. Preserve originals and investigation context. If unexpected transfer or unauthorised action is observed, interrupt according to procedure, protect evidence and involve incident owners.

For potentially impactful work, define protection and recovery beforehand: backup with verified restoration may be a dependency, but neither replaces approval nor justifies uncontrolled changes.

Simulated case: diagnosis needs more privileges

An external technician receives read-only access to investigate instrument results failing to reach the LIMS. During the session, the technician proposes restarting a connector with administrator rights. The internal contact pauses that part of the intervention: diagnostic approval does not cover changing the service.

IT and the system owner assess the request, active acquisitions, queued messages and the risk of duplicate or untransferred results. If approved, they define temporary privileges, the executor, stop conditions and reconciliation checks; nobody lends a colleague’s account. Urgency follows the documented emergency process, without fictitious retrospective approvals.

After the intervention, the laboratory checks transfer and correspondence of affected records, IT confirms closure and revocation, and the competent functions decide on return to use. An unresolved discrepancy keeps the investigation open. The case does not describe an intervention actually performed.

Sources and closure criteria

EU GMP Annex 11, January 2011 revision, addresses third-party agreements, changes, security and incidents (§§3, 10, 12–13). PIC/S PI 041-1, 1 July 2021, develops security and access considerations for GMP/GDP data management (§9.5).

NIST SP 800-53 Rev. 5, September 2020, December 2020 update, controls AC-17 and MA-4, is a technical reference for remote access and maintenance; it does not automatically establish GMP obligations. Sources consulted 2 October 2026; the 2025 Annex 11 revision draft is not treated as current requirements.

Close the intervention when activities, data effects, remaining access and checks support a reasoned decision. Retain open problems, their owners and use restrictions as well: the supplier’s report contributes evidence, while fitness for use remains the laboratory’s decision.