FDA Findings: Analysts With Admin Rights and Shared Logins

If the person generating a result can also delete it, change its date, or do it under someone else’s name, the result cannot be trusted — however honest that person is. That is why access control keeps appearing in FDA Warning Letters. Three recent letters show the same pattern in different forms.

Background: data integrity and ALCOA+ in practice.

What FDA found

Company X1 — shared login, admin rights, deleted sequences

Cited under 21 CFR 211.68(b). According to the letter:

• the firm used a common username and password to access HPLC equipment used for impurity testing;
• analysts had administrator privileges to modify and delete data;
• investigators found multiple deleted GC analytical sequences — including system suitability and stability sequences — in the computer’s recycle bin.

The firm attributed this to one employee not following procedure and to a software update that let users bypass access restrictions. FDA found the response inadequate and requested an independent assessment of computer system security covering, among other things, user privileges, segregation of administrators from laboratory users, unique logins, audit trail review and prevention of data deletion.

Company X2 — admin rights including test dates and times

Cited under 21 CFR 211.68(b). The letter states that laboratory instruments generating release and stability data lacked restricted access and sufficient controls, and that “your analysts had administrative rights capable of altering and deleting data, files, and folders” — including the date and time of tests. Investigators documented numerous deleted electronic raw data files, and the firm did not ensure retention of complete electronic raw data for all laboratory instrumentation.

FDA found the response inadequate because it lacked a comprehensive review of each piece of equipment and of the impact of discarded or lost data.

Company X3 — a repeat finding

Cited under 21 CFR 211.194(a). According to the letter, analysts had administrative rights on chromatographic systems that allowed them to alter and delete data, files and folders — including the spreadsheet used for assay calculations. FDA notes that deficiencies in the firm’s electronic data security controls had been identified and discussed during previous inspections.

Why this happens

Interpretation — the letters state findings, not root causes. These are common patterns, not claims about these firms.

• Installed as delivered. Many systems ship with one powerful default account. If nobody designs the roles, the default becomes the way the lab works.
• Convenience on shift. One login on the instrument PC is faster than everyone logging in and out. Over time it becomes normal.
• No one to be the admin. Small labs often have no IT or independent administrator, so the most experienced analyst gets the rights.
• The operating system is forgotten. Application roles may be set correctly while the operating system still lets users delete or rename raw data files directly. A recycle bin full of sequences (X1) is an operating-system problem as much as an application one.
• Spreadsheets sit outside the system. A calculation spreadsheet anyone can edit (X3) bypasses every control in the chromatography software.

What good looks like

Example: a fictional QC lab with three chromatography workstations running a CDS we’ll call ChromaLog.

1. One person, one account. Every user has a unique ID and password, at application and operating-system level. No generic “analyst”, “lab” or “admin” accounts for GxP work.
2. Roles designed, not inherited. A role matrix defines what each role can do: analysts acquire and process; reviewers review and approve; administrators configure. Analysts cannot delete data, change dates and times, disable the audit trail, or alter methods outside change control.
3. Segregation of duties. Administrator rights go to people independent of the record content — IT or a designated system owner — and administrator activity is itself audit-trailed and reviewed.
4. Lock the file system. Raw data folders are protected so files cannot be deleted, moved or renamed outside the application. Validation tests this from the operating system, not just from inside the software.
5. Control the spreadsheet too. A spreadsheet used for GxP calculations is validated, locked and version-controlled — or replaced by a calculation inside the validated system.
6. Test it in OQ. Log in with each role and try the forbidden actions: delete a result, change the clock, disable the audit trail, edit a locked method. Each attempt is expected to be blocked, and the expected result is written down before testing — see writing good test scripts.
7. Review access periodically, and after every update. User lists are reviewed on a defined schedule; leavers are removed; role changes follow a documented process. Software updates go through change control and security settings are re-checked afterwards — the side effect the X1 firm itself reported.

Regulatory basis

• 21 CFR 211.68(b) — appropriate controls over computer or related systems so that changes to records are instituted only by authorised personnel.
• 21 CFR 211.194(a) — laboratory records must include complete data derived from all tests.
• 21 CFR Part 11, §11.10(d) — limiting system access to authorised individuals. Where ID/password combinations are used as electronic signatures, §11.300(a) also requires that no two individuals have the same combination.
• FDA guidance: Data Integrity and Compliance With Drug CGMP — Questions and Answers (final, December 2018): question 4 (how access should be restricted, including assigning system administrator rights to personnel independent from those responsible for the record content) and question 5 (why shared logins are a concern — a unique individual cannot be identified). Guidance is non-binding; the regulations above are.

EU angle

In the EU, the equivalent expectation sits in EudraLex Volume 4, Annex 11 (in operation since 30 June 2011), clause 12: physical and/or logical controls should restrict access to computerised systems to authorised persons, and creation, change and cancellation of access authorisations should be recorded. A revised Annex 11 was published as a draft for consultation in July 2025; check EudraLex Volume 4 for whether the final text has been adopted.

Takeaways

• Attributable starts with the login. A shared account makes every record unattributable.
• Admin rights for analysts mean the lab cannot prove its own data was not changed.
• Check access at both the application and the operating-system level.
• Updates and patches can quietly undo security settings — re-check after every change.