Perspective
Build Named Sign-in Into the Software, So Every GMP Record Shows Who Made It
A shared login means a GMP record cannot say who made it. We treat it as a design question, and build named sign-in into the first version so the easy way to work is the attributable one.
4-minute read5 November 2026
In Brief
- FDA's 2018 guidance says that where credentials are shared, a unique individual cannot be identified, and the system would not conform to the CGMP requirements in 21 CFR parts 211 and 212.
- People share logins for practical reasons, so a procedure changes little. We see four actions: find the reasons, make named sign-in the quickest route, separate the administrator role, and test it on real shifts.
- Thinqmesh maps your process with the people who perform it, agrees the first version in writing, and builds with sign-in as part of that scope. The code sits in your own repository.
When several analysts log in to a chromatography system under one name, the first thing an inspector sees is a weakness in access control. The consequence reaches further. Every result produced under that login has lost the ability to say who produced it, and a company that cannot say who did something will struggle to show that nothing improper was done. Our view is that a shared login is a defect in how software is designed and bought, and it is put right by those who build it.
Procedure Alone Leaves the Reasons in Place
FDA's 2018 guidance states that where credentials are shared, a unique individual cannot be identified through the login, and the system would not conform to the CGMP requirements in 21 CFR parts 211 and 212. The MHRA says shared logins should not be used on systems that generate, amend or store GXP data.
People share for practical reasons: a licence per user, a slow sign-in in a controlled area, a run that spans two shifts. Training does not remove those pressures. The cost is evidence you cannot rely on at the point it matters, such as an inspection or the release of a batch. Software that makes named sign-in the quickest route removes the reason to share.
Four Actions That Make a Named Login the Easy Way to Work
Each starts from why people share, since a rule that ignores those reasons leaves them in place.
Find Out Why People Share
Per-user licences, slow sign-in in a controlled area, a run across two shifts and urgent service access are common reasons.
We sit with the people who use the system and list the reasons, one by one. Each reason is a design requirement. A procedure that forbids sharing leaves the pressure in place, while a system built around the pressure removes the need to share.
Get started
- Ask three analysts when they last used someone else's login, and why.
- List each reason as a requirement the software must meet.
Make Named Sign-in the Quickest Route
Fast, individual sign-in at the point of work, including in gloves and in controlled areas.
Where signing in takes minutes, people will share. We design the sign-in for the place it is used, with quick switching between users, sessions that carry across a handover, and short routes for the review and approval steps. When the attributable path is the fast one, no policy is needed to enforce it.
Get started
- Time a sign-in at the slowest terminal in your plant.
- Note every task where a second person must approve and how they do it.
Separate the Administrator Role
Whoever administers the system should be independent of those responsible for the records in it.
FDA recommends that the system administrator role sit with personnel independent of the content of the record. We build roles so that people who create records cannot change who may sign them, and so that changes to access are themselves recorded.
Get started
- List who holds administrator rights on each system today.
- Mark anyone who both administers a system and produces records on it.
Test It on Real Shifts and Real Scenarios
Tests use your real scenarios and data, including handovers, absences and urgent access.
A design that works at a desk can fail at the end of a night shift. We test with your real scenarios, such as a run that spans two shifts and a service engineer who needs access at short notice, so the named route holds when the pressure arrives.
Get started
- Write down three awkward scenarios from the last quarter.
- Walk each through the planned sign-in flow with the people involved.
How Thinqmesh Solves This
We begin by mapping the process with the people who perform it, then agree in writing what the first version must do. Software is delivered in short cycles, so progress is visible and direction can change early.
- Week 1
The Process Mapped With the People Who Do It
We map how the work is done today, including why logins are shared, and agree in writing what the first version must do.
- Week 2
Named Sign-in in the First Cycle
The first short cycle builds the core job with individual sign-in and roles in place from the start.
- Week 3
Tests on Your Real Scenarios
Testing uses your real scenarios and data, including handovers and urgent access, with progress visible each cycle.
- Week 4
A First Working Version
A first working version of the defined scope is in your hands, with the code in your own repository and documentation your team can continue from. The full engagement runs to eight weeks.
You finish with working software for the defined scope, tests on your real scenarios, and the source code and documentation, all owned by you.
