Password Plus Token

Password plus token is a multi-factor authentication (MFA) pattern in which a user proves identity with a password (knowledge) and a second, independent possession factor (e.g., hardware security key, smart card, or a time-based one-time password from an authenticator app). In regulated manufacturing MES, this control is applied at system login, at specific high-risk transactions (e.g., approve, release, override), and at the point of electronic signature to raise identity assurance and deter misuse of shared or compromised credentials.

While regulations do not universally mandate MFA for every login, electronic signatures not based on biometrics must employ at least two components, and computerized systems must enforce security and authorization suitable to risk. Accordingly, password plus token is a practical, standards-aligned way to satisfy identity binding and data integrity expectations when recording GMP-relevant actions and sign-offs.

"Electronic signatures that are not based upon biometrics shall: (1) Employ at least two distinct identification components such as an identification code and password."

Part 11 (11.200, 11.300) establishes that non-biometric e-signatures must use two distinct identification components and requires administrative and technical controls for identification codes and passwords (e.g., uniqueness, periodic checks, loss management). EU GMP Annex 11 requires robust security, access rights management, and attribution of actions to individuals, with electronic signatures controlled and equivalent to handwritten signatures where legally acceptable. MHRA and PIC/S data integrity guidance emphasize individual accounts, strong authentication, and governance over credentials and tokens. For industrial environments, NIST SP 800-82 recommends MFA, particularly for remote access, elevating the baseline for MES and supporting infrastructure.

• 21 CFR 11.200: Two components for non-biometric e-signatures; first signing with all components; subsequent signings with at least one component under conditions.
• 21 CFR 11.300: Controls for IDs/passwords (uniqueness, periodic revision, loss management, transaction safeguards).
• EU GMP Annex 11: Security, access authorization lifecycle, and e-signature attribution equivalent to hand-written signatures.
• NIST SP 800-82: MFA recommended for ICS and especially remote/third-party access into control networks.

A compliant design uses independent factors: something you know (password/PIN) plus something you have (token). Possession factors suitable for MES include hardware security keys (FIDO2/U2F-style), smart cards with digital certificates, one-time password (OTP) generators (time-based TOTP apps or hardware OTP), and site-issued badges with cryptographic challenge-response. The token choice must suit the risk profile, environment (gloves, cleanroom), network conditions (air-gapped segments), and lifecycle controls (issuance, revocation, loss).

• Avoid shared tokens; each token must be uniquely assigned to an individual and recorded.
• Establish loss/theft processes aligned with 21 CFR 11.300(b) (revocation, re-issuance, documented verification of identity).
• For cleanrooms, use wipeable keys or sleeves; validate disinfectant compatibility.

Apply MFA where identity assurance materially influences product quality, patient safety, or data integrity. Common patterns include MFA at system login to Level 3 MES; on specific operations that represent release/approval, overrides, or impact to the batch record; and at electronic signature prompts for entries that become part of the permanent eBMR/eDHR. Consider enforcing re-authentication with a token for risky transitions (e.g., switching from Execute to Review state) or when escalating privileges (temporary admin).

1. System access: MFA at login to MES and integrated QMS/LIMS portals, especially from non-hardened workstations or external networks.
2. Record-impacting actions: MFA challenge at approve/release, phase start/stop overrides, exception closure, recipe approval, parameter limits change.
3. Electronic signatures: Dual-component enforcement per 21 CFR 11.200; bind both components to the signed record with date/time and meaning.

Align enforcement with the ISA-95 model: Level 4 (ERP/IdP) may provide primary identity and token issuance, Level 3 (MES) enforces step-level re-auth and signature binding, while Level 2/1 (SCADA/PLC/HMI) may use engineering MFA for remote access and privileged operations.

Configuration should follow a risk-based approach (GAMP 5) while meeting Part 11 and Annex 11 controls. Define password policies, token enrollment, session control, and re-authentication triggers. Document identity proofing, token issuance logs, and revocation steps. Ensure time synchronization across systems to prevent OTP drift and signature timestamp discrepancies, and verify any offline caches do not bypass MFA for regulated actions.

• Record token serials/keys against user identity; audit the assignment list periodically.
• For kiosk/shared workstations, enforce fast screen lock and per-action token challenges.
• Validate disinfectant and temperature limits for tokens used in Grade A/B areas.

Password plus token complements RBAC by raising assurance that the correct person is executing a role. Configure policies so that the same individual cannot use their MFA to approve their own work where two-person review is required; combine with electronic countersignature workflows. When capturing electronic signatures, collect and store: user ID, full name, date/time in system time, signature meaning (e.g., review, approval), and the fact that a token was successfully validated at signing. Ensure the audit trail logs successful and failed MFA events with context and record linkages.

• Prohibit generic accounts; every action must be attributable to a single named individual (Annex 11, MHRA DI).
• Bind signature components cryptographically to the record or tamper-evidently in the audit trail (Part 11 intent).
• Use workflow constraints to enforce independent review (see two-person e-signature) where required by SOPs or market authorization.

Validate password-plus-token as part of the computerized system validation (CSV/CSA) lifecycle. Requirements (URS) should state when MFA is required (login, step-level, e-sign), supported token types, lockout/timeout behavior, and audit trail content. Test cases should demonstrate: unique user accounts; correct enforcement of two components at first signature and allowable behavior for a signing series; lockout after failed attempts; token loss and revocation; time synchronization; and integrity of audit trails across integrations (MES, QMS, LIMS). Maintain SOPs for issuance, revocation, periodic review, and use in cleanrooms. Capture objective evidence, including screenshots, event logs, and configuration exports, and control them under change control.

• Risk-assess MFA scope per GAMP 5 (2nd ed.) and Annex 11 based on data criticality and threat vectors.
• Qualify dependencies (e.g., IdP, HSM, NTP) that materially affect enforcement of MFA or timestamps.
• Periodically challenge controls with negative testing (invalid token, drifted time, revoked token).

Manufacturing environments include constrained HMI/PLC/SCADA assets and segmented networks. Apply password-plus-token pragmatically: enforce MFA at jump hosts, remote access gateways, and MES Level 3 applications, per NIST SP 800-82 recommendations. For local operator HMIs, consider token-based re-auth only for engineering or privileged operations where supported. Ensure no bypass via cached sessions on thin clients. Implement time servers across OT to keep TOTP valid, and harden token middleware/driver installation on locked-down workstations.

• Enforce MFA for all remote access into the control network and for third-party vendor sessions.
• Use network segmentation so that authentication occurs before reaching MES and historian assets.
• Log MFA outcomes to a central security log in addition to the Part 11 audit trail; reconcile routinely.

Frequent failures include issuing shared tokens to teams, relying on cached SSO sessions that allow step approvals without fresh re-auth, placing tokens on keychains left at workstations, and failing to revoke lost tokens promptly. Risky token types (e.g., SMS OTP) can be undermined by SIM-swap and radio coverage issues in plants. Another trap is neglecting time synchronization, causing TOTP rejection and operators to bypass steps. Finally, some configure two components at login but not at e-signature, missing the explicit Part 11 requirement for dual components at signing.

• Never allow generic logins or pooled tokens; enforce individual accountability.
• Require re-authentication with token for each e-signature or justified signing series.
• Document and drill loss/theft procedures; audit issuance and revocations.
• Harden kiosks to auto-lock quickly; prevent token reuse without presence checks.

V5 implements password-plus-token at three layers: platform login (SSO/SAML/OpenID Connect with MFA), application-level re-auth for sensitive MES/QMS/LIMS actions, and electronic signature prompts bound to the record with dual components per 21 CFR 11.200. Administrators can define token types, issuance workflows, and revocation processes with full auditability. V5 logs successful and failed MFA attempts, enforces short kiosk idle timeouts, supports cleanroom-compatible hardware keys, and verifies time synchronization to protect OTP validity.

• Policy-based triggers for MFA at step start/stop, exception closure, disposition, and batch release.
• Signature meaning capture and dual-component binding to eBMR/eDHR records with cross-module audit trail.
• Loss/theft workflow with immediate revocation, risk assessment, and re-issuance controls under change control.