This is a ready-to-use policy setting the authentication standard for computerized systems that hold GxP records. Authentication is the control that proves the person acting is really the account holder, which is what makes a record attributable and an electronic signature meaningful. Replace every <<FILL: ...>> placeholder, set your own values to the strength your risk assessment supports, and route it through document control. A filled settings specimen follows. Set numeric values to a documented standard appropriate to system criticality; the examples here are illustrative, not universal requirements.
Document control header
| Field | Entry |
|---|---|
| Document title | Password and Authentication for GxP Systems |
| Document number | <<FILL: POL-ID, e.g. POL-IT-004>> |
| Version | <<FILL: version, e.g. 1.0>> |
| Effective date | <<FILL: effective date>> |
| Supersedes | <<FILL: prior version or "New">> |
| Document owner | <<FILL: role, e.g. Head of IT Security>> |
| Applies to | <<FILL: systems / sites in scope>> |
1. Purpose
This policy defines the authentication controls <<FILL: COMPANY NAME>> requires on GxP computerized systems so that access and electronic signatures are reliably tied to identified individuals, and credential strength is proportionate to the criticality of the system.
2. Scope
This policy applies to all GxP computerized systems and to all human and service accounts that access them. It covers passwords and other authentication factors, multi-factor authentication, session and lockout controls, service-account credentials, single sign-on, and re-authentication at electronic signing. It does not replace the access-management SOP that governs the account lifecycle.
3. Policy statements
- Unique credentials. Every human user authenticates with individually assigned credentials. Shared or generic logins are prohibited on GxP systems.
- Credential standard. Passwords (or equivalent secrets) meet a documented standard for length, complexity or length-based strength, and reuse history, set to the strength the system criticality warrants. The standard, not a memory, is the reference.
- Multi-factor authentication. MFA is required for privileged accounts and for any remote access to GxP systems, and is applied more broadly where the risk assessment supports it.
- Session controls. Systems enforce an inactivity timeout short enough to be meaningful for the workflow, requiring re-authentication after the timeout. An unattended authenticated session is treated as a control gap.
- Failed-login lockout. Accounts lock after a defined number of failed attempts, and the event is logged. Lockout release follows a controlled process.
- Credential lifecycle. Initial credentials are delivered securely and changed on first use; credentials are changed on suspicion of compromise; retired user IDs are never reassigned.
- Service accounts. Non-human accounts have a named owner, vaulted credentials, defined rotation, and no interactive login that would let a human act anonymously behind the account.
- Single sign-on. Where SSO is used, the identity provider is treated as a critical dependency of every connected GxP system, deprovisioning propagates promptly from it, and the individual identity is preserved in the audit trail.
- Signing re-authentication. An electronic signature is a deliberate act that re-authenticates the genuine signer at the moment of signing, even when routine access uses SSO, consistent with the electronic-signature requirements.
- No credential sharing or storage in clear. Users never share credentials or a session; credentials are never stored or transmitted in clear text or posted where others can see them.
4. Roles
| Role | Responsibility |
|---|---|
| IT Security | Owns this policy and the credential standard; monitors compliance. |
| System / process owner | Ensures each GxP system is configured to this policy or has an approved exception. |
| IT / system administrator | Configures and maintains the authentication settings; never shares privileged credentials. |
| QA | Confirms authentication controls at validation and periodic review; approves exceptions. |
| End user | Protects their own credentials and never shares a session. |
5. Compliance and exceptions
Where a legacy or vendor system cannot meet a statement in section 3, the gap is documented as an exception with a risk assessment and compensating controls (for example, tighter network access, enhanced monitoring, or a shorter review cycle), approved by QA, and tracked with the vendor toward remediation. An undocumented deviation from this policy is a finding; a documented, risk-assessed, compensated exception is defensible.
6. References
21 CFR Part 11 (11.10(d) access limits; 11.200 identification-code and password components for signatures; 11.300 controls for identification codes and passwords). EU GMP Annex 11 (clause 12, security; controls appropriate to criticality). FDA Data Integrity and Compliance With Drug CGMP (2018); MHRA GXP Data Integrity Guidance. NIST SP 800-63 Digital Identity Guidelines (a public reference for authentication strength).
Confirm the current version and clause numbers of each reference before issue.
7. Revision history
| Version | Date | Author | Summary of change |
|---|---|---|---|
<<FILL: 1.0>> | <<FILL: date>> | <<FILL: author>> | Initial issue. |
8. Approvals
| Role | Name | Signature | Date |
|---|---|---|---|
| Author | <<FILL>> | ||
| Reviewer (QA) | <<FILL>> | ||
| Approver (IT Security) | <<FILL>> |
Filled specimen
The following shows a configured settings table for an illustrative high-criticality laboratory system. The values are illustrative and set to a documented internal standard; replace them with your own risk-based values.
| Setting | Configured value | Basis |
|---|---|---|
| Minimum password length | 14 characters | Internal standard for high-criticality systems |
| Complexity / strength | Passphrase permitted; screened against common-password list | Length-based strength preferred over forced complexity churn |
| Reuse history | Last 12 remembered | Internal standard |
| MFA | Required for all users (remote-reachable system) | System reachable outside the network |
| Inactivity timeout | 10 minutes, re-authentication required | Shared shop-floor terminals in the workflow |
| Failed-login lockout | 5 attempts, 30-minute lockout, event logged | Internal standard |
| Service accounts | Credentials vaulted, rotated every 90 days, no interactive login | Two integration accounts, named owners |
| Signing re-authentication | Password re-entry required at each signature | Part 11 signing is a deliberate act |
In this example the inactivity timeout is set to ten minutes because the terminal is shared by many operators through a shift, and MFA is required because the system is reachable from outside the network. Each value is tied to a stated basis, which is what turns a settings screen into a defensible, risk-based control.
Common inspection findings this policy prevents
- Shared or generic logins on GxP systems.
- An inactivity timeout so long it is not a real control (a full-shift timeout on a shared terminal).
- No MFA on privileged or remote access to critical systems.
- Service-account credentials shared, unrotated, or usable for interactive login.
- Authentication settings that do not match a documented standard, with no exception on file.
- A click-through confirmation used as a signature with no re-authentication of the signer.
How to adapt this policy
- Set your document number, owner, and effective date in the header.
- Set every numeric value in section 3 and the specimen to your risk-based documented standard, not the illustrative examples.
- Align the exception process in section 5 with your quality system.
- If you use SSO, confirm statements 8 and 9 match how your identity provider and signing actually work.
- Confirm every regulation in section 6 against the current published version before issue.