Shared Logins and Who Owns the Software: Access Control in a Small Lab

The single most common data integrity finding in laboratories is not falsification. It is a sticky note on the HPLC workstation with the login on it. Nobody put it there dishonestly. It is there because the software came with two licences, the lab has six analysts, and the instrument has to be usable on a Saturday. Every regulator that has written on the subject addresses it, and the reasoning is more interesting than the prohibition.
Quick answer
Why are shared logins a problem? Because attribution runs through the login. PIC/S puts it in one line: shared login credentials do not allow for traceability to the individual who performed the activity — and then closes the obvious escape route by adding that for this reason shared passwords, even for reasons of financial savings, should be prohibited.
The FDA reaches the same conclusion from the regulation: when login credentials are shared, a unique individual cannot be identified through the login, and the system would not conform to the requirements. The MHRA states that for systems generating, amending or storing regulated data, shared logins or generic user access should not be used — and acknowledges the cost directly: where the system design supports individual user access, this function must be used, and this may require the purchase of additional licences.
Three agencies, independently, name the budget objection and overrule it. That is unusual enough to be the point.
What a shared login actually destroys
Attribution is the first letter of ALCOA for a structural reason, covered in the nine words that decide whether a record counts: without it, none of the others can be checked. An audit trail that records a change, a time and a reason, but attributes it to LabUser, documents that something happened without documenting who is answerable for it. The record is complete, legible, contemporaneous and unverifiable.
The FDA draws one careful distinction that is worth keeping. Shared read-only accounts that do not allow the user to modify data or settings, it says, are acceptable for viewing data — but they do not conform with the requirements for actions, such as second-person review, to be attributable to a specific individual.
So a shared account for looking at results is tolerable. A shared account for approving them is not, because the approval is the thing being attributed.
Least privilege, and what a normal user should not reach
PIC/S sets the general rule as the least-privilege principle: systems should support different user access roles, and assignment of a role should follow the least-privilege rule, assigning the minimum necessary access level for any job function. As a minimum, simple systems should have normal and admin users; complex systems typically require more levels.
It then names what normal users should not be able to touch — and the examples are instructive. Normal users should not have access to critical aspects of the computerised system, such as system clocks and file deletion functions.
The clock is the one people do not anticipate. Contemporaneity is demonstrated by timestamps; if an ordinary user can move the clock, every timestamp on the system becomes an assertion rather than evidence. The MHRA asks for the operating system clock to be synchronised with connected systems and access to all clocks restricted to authorised personnel.
PIC/S also rules out the most tempting shortcut of all: the use of a single user access level on a system, assigning all users this role, which by definition will be the admin role, is not acceptable.
The finding most small labs do not see coming
Here is the requirement that catches well-run laboratories, and it has nothing to do with passwords.
PIC/S states that system administrators should normally be independent from the users performing the task, and should have no involvement or interest in the outcome of the data generated. Its example is specific enough to be uncomfortable: QC supervisors and managers should not be assigned as the system administrators for electronic systems in their laboratories — it names HPLC, GC and UV-Vis. Typically, it says, individuals outside the quality and production organisations, such as IT administrators, should serve as system administrators and hold the enhanced permission levels.
The FDA says the same thing in a sentence: the system administrator role, including any rights to alter files and settings, should be assigned to personnel independent from those responsible for the record content.
The MHRA explains the purpose. System administrator rights permitting activities such as data deletion, database amendment or system configuration changes should not be assigned to individuals with a direct interest in the data — data generation, data review or approval — and the intent, it says, is to prevent giving access to users with potentially a conflict of interest, so that they cannot make unauthorised changes that would not be traceable to that person.
In a laboratory of four people, the person who knows the chromatography software best is almost always the person who runs the chromatography. That is precisely the arrangement all three guidances are describing.
What a small organisation is actually permitted to do
PIC/S does not leave small labs in an impossible position. It provides an explicit carve-out, with conditions, and the conditions are the whole mechanism:
For smaller organisations, it may be permissible for a nominated person in the quality unit or production department to hold access as the system administrator. However, in these cases the administrator access should not be used for performing routine operations, and the user should hold a second and restricted access for performing routine operations. In these cases all administrator activities conducted should be recorded and approved within the quality system.
The MHRA permits the same shape: administrator access restricted to the minimum number of people possible, taking account of the size and nature of the organisation, with the generic administrator account not available for routine use, and personnel with administrator access logging in with unique credentials so that actions in the audit trail can be attributed to a specific individual.
| Arrangement | Status |
|---|---|
| One shared login for all analysts | Prohibited — attribution is lost |
| Shared read-only account for viewing results | Acceptable for viewing; not for review or approval |
| Analyst also holds admin rights on the instrument, used routinely | Not acceptable — conflict of interest in the data |
| Two accounts for one person: restricted for daily work, admin used only when needed and logged | Permitted for smaller organisations, with admin activity recorded and approved |
| Independent IT administrator outside quality and production | The stated preference |
The practical reading: two accounts for one person is the compliant small-lab answer, and the cost of it is a log of administrator actions rather than another licence.
The housekeeping that turns out to be substantive
Several PIC/S requirements look like IT hygiene and are really about whether access can be reconstructed later.
Systems should be able to generate a list of users with actual access, including user identification and roles, with names or unique identifiers that permit identification of specific individuals — and the list should be used during periodic user reviews. Systems should also be able to generate a list of successful and unsuccessful login attempts, including user identification, access role, date and time, and session length for successful logins.
The MHRA adds the historical dimension, which is the part that fails: companies must be able to demonstrate the access levels granted to individual staff members and ensure that historical information regarding user access level is available — and where the system does not capture this, a record must be maintained outside of the system.
Who has access today is easy. Who had access on the date of a particular result, two years ago, is the question that actually gets asked, and most systems do not answer it unless somebody wrote it down.
Two smaller items with real consequences. PIC/S asks for an inactivity logout at the application or operating system level, and notes the time should be shorter, rather than longer. And it rules a whole class of system non-compliant in one sentence: systems where a new password cannot be changed by the user, but can only be created by the admin, are incompatible with data integrity, because the confidentiality of passwords cannot be maintained. If the administrator knows your password, your signature is not yours.
Hybrid systems: the arrangement everybody actually has
Most working laboratories are hybrid — part electronic, part paper, with a human transcribing between them. PIC/S is unusually direct about it: hybrid systems require specific and additional controls in reflection of their complexity and potential increased vulnerability to manipulation of data, and for this reason the use of hybrid systems is discouraged and such systems should be replaced whenever possible.
The MHRA gives the reason in a phrase worth remembering: increased data review is likely to be required for hybrid systems because they are vulnerable to non-attributable data changes.
Where a hybrid system remains, PIC/S asks for procedures covering the three interfaces where things go wrong: manual input of manually generated data into computerised systems; transcription of data generated by automated systems onto paper records; and automated detection and transcription of printed data into computerised systems. Original data should be retained following transcription and processing. The MHRA adds that where manual transcriptions occur, these should be verified by a second person or a validated system.
Which records count as original in each half of that arrangement is the subject of static and dynamic records.
Blank forms, and the quietest control of all
One paper-side control appears in all three documents and is almost free to implement.
The FDA: bound paginated notebooks, stamped for official use by a document control group, provide good document control because they allow easy detection of unofficial notebooks as well as any gaps in notebook pages. If blank forms are used, they should be controlled by the quality unit or another document control method, numbered sets may be issued, and they should be reconciled upon completion. And: incomplete or erroneous forms should be kept as part of the permanent record along with written justification for their replacement.
The MHRA: access to blank paper proformas for raw or source data recording should be appropriately controlled, and reconciliation, or the use of controlled books with numbered pages, may be necessary to prevent recreation of a record.
That final clause is the entire purpose. An unlimited supply of blank forms means any record can be rewritten later and look original. Numbered pages mean a missing one is visible. It is the cheapest data integrity control that exists, and it costs a numbering stamp.
Culture is in the guidance, not around it
It would be easy to treat the human side as commentary. It is in the text.
The MHRA states that the impact of organisational culture, the behaviour driven by performance indicators, objectives and senior management behaviour on the success of data governance measures should not be underestimated, and that the data governance policy should be endorsed at the highest levels of the organisation. Its definition of data governance requires the creation of a working environment that enables visibility and actively encourages reporting of errors, omissions and undesirable results.
It also sets a sane ceiling, which is worth quoting in a field prone to over-correction: organisations are not expected to implement a forensic approach to data checking on a routine basis. Systems should maintain appropriate levels of control, while wider governance measures ensure that periodic audits can detect opportunities for data integrity failures.
A laboratory where an unwelcome result is a problem to be explained will generate records that need explaining. That is a management variable, not a software setting.
What to ask, and what to conclude
- Count licences against analysts before anything else. It is the arithmetic that produces the shared login, and all three guidances say to buy the licences.
- Check who administers the instrument software. If it is the person who runs the instrument, that is the finding — and the two-account arrangement is the permitted fix.
- Ask whether historical access levels can be reconstructed. Current access is easy; access as of a past date is the question that gets asked.
- Number the pages. Controlled, reconciled forms prevent a record being recreated after the fact, for almost no cost.
- Treat a hybrid workflow as needing more review, not less. The MHRA identifies it as vulnerable to non-attributable change.
Key takeaways
- Shared logins destroy attribution; PIC/S prohibits them even where the motive is cost saving, and the MHRA says additional licences may need to be purchased.
- Shared read-only accounts are acceptable for viewing data but not for second-person review.
- Access should follow the least-privilege rule; normal users should not reach system clocks or file deletion functions.
- PIC/S states QC supervisors and managers should not administer the electronic systems in their own laboratories.
- Smaller organisations may nominate an internal administrator, provided that person holds a second restricted account for routine work and all administrator activity is recorded and approved.
- Systems should produce user lists and login-attempt logs; historical access levels must be demonstrable, outside the system if necessary.
- A system where only the administrator can create passwords is incompatible with data integrity.
- Hybrid systems are discouraged by PIC/S and identified by the MHRA as vulnerable to non-attributable data changes.
- Controlled, numbered, reconciled blank forms exist specifically to prevent a record being recreated later.
Frequently asked questions
Is a shared login ever acceptable?
For read-only viewing, the FDA says yes. For anything that creates, changes or approves a record, no — that is the action requiring attribution.
What if the instrument software genuinely supports only one user?
Both guidances allow for it as a bridge. The MHRA accepts that some systems support only a single login, and says that where no suitable alternative system is available, equivalent control may be provided by third-party software or a paper-based method of providing traceability with version control, justified and documented — with increased data review likely to be required.
Does using a cloud service change anything?
It adds considerations rather than removing them. The MHRA asks for attention to the service provided, ownership, retrieval, retention and security of data, and specifically for the physical location where the data is held to be considered, including the impact of any laws applicable to that geographic location.
Why do USB restrictions appear in a data integrity guidance?
PIC/S covers them for a security reason it spells out: operating system vulnerabilities are known that allow USB devices to trick the computer by pretending to be another external device, such as a keyboard, and to contain and start executable code. It asks for ports to be opened only for approved purposes and devices to be scanned before use.
How does this affect buying research material?
Indirectly but genuinely. PIC/S observes that it is often not practical for a contract giver to review all raw data relating to reported results, and that emphasis should therefore be placed on a robust qualification process for the supplier. Access control is one of the things a qualification assesses — the broader logic in evaluating a research peptide supplier.
Sources
- Pharmaceutical Inspection Co-operation Scheme. PI 041-1: Good Practices for Data Management and Integrity in Regulated GMP/GDP Environments. Adopted 1 June 2021; entry into force 1 July 2021. PIC/S guidance
- Medicines and Healthcare products Regulatory Agency. GXP Data Integrity Guidance and Definitions. Revision 1, March 2018. MHRA guidance
- US Food and Drug Administration. Data Integrity and Compliance With Drug CGMP: Questions and Answers — Guidance for Industry. December 2018. FDA guidance
All quoted text is taken from the published guidance documents linked above.
This article describes record-keeping and laboratory systems practice only. It contains no usage instructions, no dosing information and no protocols of any kind.
For laboratory and in-vitro research use only. Not for human or veterinary use.
For laboratory and in-vitro research use only. Not for human or veterinary use. See our research-use disclaimer.


