E-signature

Part 11 defines an electronic signature at §11.3(b)(7) as 'a computer data compilation of any symbol or series of symbols executed, adopted, or authorised by an individual to be the legally binding equivalent of the individual's handwritten signature.' The rule then defines the controls that make the signature trustworthy enough to substitute for ink. The definition is intentionally broad — it does not specify the technology — but the controls are specific, and it is the controls that determine whether a given implementation is a Part-11 signature or merely a checkbox.

Three things have to be true at the moment of signing. The signing must be performed by a uniquely identified individual, using authentication credentials that only that individual possesses. The signing must be bound to a specific record at a specific version, so the signature cannot be silently re-attached to a different version later. The signing must display the printed name of the signer, the date and time of signing, and the meaning of the signing — review, approval, responsibility, authorship, witnessing — drawn from a controlled list rather than free text.

Three sections of Part 11 carry the operational requirements. §11.50 governs how the signature is displayed on the record. §11.100 governs who can sign and how identity is established before credentials are issued. §11.200 governs the authentication mechanics at the moment of signing. Implementations fail on one of these three almost without exception.

1. §11.50 — Signature manifestation. Every signed electronic record must clearly indicate the printed name of the signer, the date and time of signing, and the meaning of the signing (review, approval, responsibility, authorship). These three items must be subject to the same controls as the underlying record and must be included as part of any human-readable form of the record (display, print, electronic export).
2. §11.100 — Uniqueness and identity verification. Each electronic signature must be unique to one individual and must not be re-used by, or reassigned to, anyone else. Before issuing signing credentials the organisation must verify the identity of the individual (typically through HR onboarding plus role-based access provisioning). Persons using electronic signatures must, prior to or at the time of such use, certify to the FDA that their electronic signatures in their system are intended to be the legally binding equivalent of traditional handwritten signatures (the §11.100(c)(2) certification — usually a one-time form submitted with the agency).
3. §11.200 — Components and controls. Non-biometric signatures must employ at least two distinct identification components (typically a user ID and a password). The first signing of a continuous session of controlled system access must use all components; subsequent signings during the same continuous session must use at least one component executable only by the signer (usually the password). When the signer leaves the system, the next signing must again use all components. Biometric signatures must be designed so they cannot be used by anyone other than their owner.

The terms are often used interchangeably but they describe different mechanisms. An electronic signature is an authentication event recorded by a controlled system; the integrity guarantee comes from the system's access controls and audit trail. A digital signature is a cryptographic operation that produces a verifiable hash bound to the document using public-key infrastructure (PKI); the integrity guarantee comes from the math, and can be verified independently of the originating system.

Part 11 permits either, and the FDA Scope and Application Guidance (2003) makes clear that the agency takes a technology-neutral position — what matters is that the controls satisfy §11.50 / §11.100 / §11.200, not the specific cryptographic implementation. In practice the overwhelming majority of regulated MES / QMS / LIMS deployments use system-recorded electronic signatures (Part 11 §11.200 compliant) rather than per-record PKI digital signatures, because the operational overhead of PKI key management at scale is prohibitive and the audit-trail-plus-access-control model is sufficient for inspection.

Outside the US pharma/device context, the EU eIDAS regulation defines a tiered hierarchy — Simple Electronic Signature (SES), Advanced Electronic Signature (AdES), Qualified Electronic Signature (QES) — that maps loosely onto the e-sig vs digital-signature distinction. SES is the system-recorded model; AdES adds unique-signer linkage and tamper-evidence; QES adds a Qualified Signature Creation Device (QSCD) and a Qualified Trust Service Provider (QTSP) certificate. EU GMP Annex 11 §14 does not require QES for GMP records, but some jurisdictions and customer contracts do specify a tier above SES.

§11.70 requires that 'electronic signatures and handwritten signatures executed to electronic records shall be linked to their respective electronic records to ensure that the signatures cannot be excised, copied, or otherwise transferred to falsify an electronic record by ordinary means.' The practical interpretation is a binding manifest captured at the moment of signing and stored alongside the audit trail.

• Printed name of the signer (not just the user ID — the human-readable name as it appears on HR records).
• Date and time of signing in a controlled timezone (typically captured in UTC, displayed in the operator's local timezone with the timezone label).
• The meaning of the signing — 'reviewed', 'approved', 'prepared', 'witnessed', 'released', 'rejected' — drawn from a controlled, version-controlled list rather than free text.
• A reference to the exact version of the record being signed (signing v3 of an SOP is not the same as signing v4; the signature manifest must carry the version identifier or a cryptographic hash of the record content).
• An audit-trail entry recording the signing event with the signer ID, the signing meaning, the record reference, the timestamp and the IP / device fingerprint.
• On any human-readable rendering of the record (PDF, print, electronic export) the three §11.50 elements — name, timestamp, meaning — must appear, not as a separate cover sheet but as part of the record itself.

§11.200(a)(1)(i) requires that the first signing of a continuous session of controlled system access use all two identification components, and §11.200(a)(1)(ii) requires that subsequent signings during the same continuous session use at least one component executable only by the signer. When the session ends — whether by explicit logout, by inactivity timeout, or by the system being left unattended in a way that allows another individual to access it — the next signing must again use all components.

Three practical patterns recur. A kiosk operator running a dispense job re-enters their password for every weight confirmation; the password is the §11.200(a)(1)(ii) component. The same operator returning from a meal break logs out (or is logged out by the idle timeout) and must re-enter user ID plus password on resumption — the next signing is treated as a new session under §11.200(a)(1)(i). A reviewer approving a batch record across multiple screens within a few minutes uses the password component per signing; if the reviewer steps away long enough for the session to expire, the next signing requires full re-authentication.

Several regulations explicitly require two distinct signatures — preparer and independent reviewer — on the same record. The second signer cannot be the same person as the first, and the system must block the attempt rather than rely on the second reviewer to notice.

• 21 CFR 211.186 — pharma master production and control records (MPRs) require preparation, dating and signing by one person and independent checking, dating and signing by a second person.
• 21 CFR 211.188 — pharma batch production and control records (BPRs) require review and approval by the quality control unit, distinct from the preparing operator.
• 21 CFR 111.205 — dietary supplement master manufacturing records (MMRs) require preparation by one qualified individual and independent verification by a second qualified individual.
• 21 CFR 111.260 — dietary supplement batch production records (BPRs) carry the same two-person requirement for review.
• 21 CFR 820.40 — medical device document approval; QSR requires review and approval prior to issuance, with reviewer distinct from author.
• EU GMP Part I Chapter 4 §4.20 — second-person independent check of any operation that could affect product quality.
• ICH Q10 §3.2.4 — pharmaceutical quality system; two-person review of critical decisions as part of management responsibility.

See the dedicated two-person e-signature page for the full pattern. The point here is that the same §11.50 / §11.100 / §11.200 controls apply to each of the two signatures independently — both must be uniquely identified, both must re-authenticate at the moment of signing, both must record the meaning, and both must be bound to the record version. The system must additionally enforce that the second signer is not the first.

1. Operator stays signed in indefinitely. Every 'signing' becomes a click with no authentication. Single most common 483 observation on Part 11. Fix: enforced idle timeout (typically 5–15 minutes) plus explicit logout button; subsequent signing requires full §11.200(a)(1)(i) re-auth.
2. Shared accounts. 'kiosk_operator_01' used by whoever is on shift. Fatal to §11.100(a) uniqueness. Fix: per-individual accounts with HR-linked identity verification before credentials are issued; shared kiosks use named-user sign-in at session start, not shared logins.
3. Signing without recording the meaning. The signed PDF says 'signed by J. Smith' but not whether they approved, witnessed, or merely acknowledged. Violates §11.50(a)(3). Fix: controlled meaning list drawn from a version-controlled vocabulary; every signing requires meaning selection before the password prompt.
4. Signing the wrong version. The record was edited after the signature was captured; the signature now applies to a different artifact. Violates §11.70 binding. Fix: signature manifest captures the record version hash at signing time; subsequent edits trigger a new version requiring re-signing.
5. No re-authentication required for the first signing of a session. The operator logs in once at shift start and every signing thereafter is implicit. Violates §11.200(a)(1)(i). Fix: first signing prompts for both components even if the user is logged in; session-state and signing-state are distinct.
6. Hardcoded 'system' or 'admin' signatures appearing on production records. An automated step (lot release, batch close, schedule promotion) is recorded as signed by 'system'. Violates §11.100(a) — 'system' is not a unique individual. Fix: automated steps are recorded as system events without a signature; any step requiring a signature must be performed by a named human.
7. Identification code policy weaker than §11.300. Passwords reused across systems, no periodic forced change, no lockout on failed attempts. Violates §11.300 controls for identification codes. Fix: password policy aligned with §11.300 — periodic change, lockout, no reuse across recent history, immediate revocation on departure.
8. Signing manifestation missing from human-readable export. The audit trail shows the signing but the rendered PDF does not display the printed name / timestamp / meaning. Violates §11.50(b). Fix: PDF render pipeline embeds the §11.50 manifest as part of the record body, not as a separate audit-log appendix.

Part 11 is the US umbrella rule, but every major regulated regime carries a parallel requirement. The operational signing pattern is identical; the regulatory citations vary by industry and jurisdiction.

• 21 CFR Part 11 (US, all regulated industries) — §11.50 manifestation, §11.70 binding, §11.100 uniqueness, §11.200 components, §11.300 password controls.
• EU GMP Annex 11 §14 — electronic signatures must have the same impact as hand-written signatures, be permanently linked to their respective record, and include the time and date that they were applied.
• EU Annex 11 §12 — physical and logical controls restricting system access to authorised individuals.
• 21 CFR 211.186 / 211.188 — pharma MMRs and BPRs requiring two-person signing.
• 21 CFR 111.205 / 111.260 — dietary supplement MMRs and BPRs requiring two-person signing.
• 21 CFR 820.40 — medical-device document approval requiring independent reviewer.
• EU MDR 2017/745 Annex IX — quality management system documentation approval; signature requirements follow the QMS controls (typically ISO 13485 §4.2.4).
• ICH Q9(R1) — quality risk management; signature event is itself a risk control and the signing function is part of the validated state.
• ICH Q10 §3.2.4 — management responsibility for review and approval of critical decisions.
• ISO 13485:2016 §4.2.4 — control of documents; approval, review and update with identifiable history.
• eIDAS Regulation (EU) 910/2014 — SES / AdES / QES tiering for signatures outside pharma scope; relevant for cross-border commercial contracts and some authority-facing submissions.

• Signing-manifest completeness — share of signed records where the §11.50 triple (name, timestamp, meaning) is present on the human-readable rendering. World-class: 100%. Anything below is a structural validation gap.
• Re-authentication enforcement rate — share of signings preceded by an explicit password re-entry (or biometric verification). World-class: 100% of regulated signings. Below 100% means session-state is being treated as signing-state.
• Idle-timeout compliance — share of sessions terminated by the system before exceeding the configured idle threshold. World-class: 100%. Manually-managed logout is not a control.
• Unique-signer rate — share of signings attributed to a named human (not 'system', 'admin', or a shared account). World-class: 100% on regulated records.
• Two-person signing on records requiring it — share of 211.186 / 211.188 / 111.205 / 111.260 / 820.40 records with both signatures present, signed by distinct individuals, with the second signer not the first. World-class: 100%.
• Version-binding integrity — share of signatures where the manifest version hash matches the current record version. Drift indicates record was edited after signing; should be zero.
• Password-policy compliance per §11.300 — share of accounts meeting periodic change, no recent reuse, lockout on failed attempts, immediate revocation on departure. World-class: 100%.
• Inspection findings on Part 11 / Annex 11 — mature sites: zero in any inspection cycle. Any finding here is a structural process gap, not a one-off operator error.

1. Identity provisioning is HR-linked. User accounts cannot be created without a verified identity reference (employee ID, contractor reference, or supplier user with verified email and signed user-agreement). The §11.100(b) identity verification step is captured as a controlled record on the user profile.
2. Every regulated signing prompts for the password (or hardware-attested biometric on supported kiosks). The session-state and signing-state are distinct — being logged in does not authorise signing.
3. Idle timeout is enforced server-side at 10 minutes (configurable per tenant from 5 to 15). Crossing the threshold ends the session and forces full §11.200(a)(1)(i) re-authentication on the next signing.
4. The signing meaning is drawn from a controlled vocabulary per record type (review, approval, witnessing, release, rejection, training acknowledgement, deviation acknowledgement). The vocabulary is version-controlled and changes go through change-control.
5. Two-person signings (MMR / BPR / SOP / change-control approvals) enforce that the second signer is not the first; the system blocks the same user from completing both roles even if their permissions permit both.
6. Every signing writes an immutable audit-trail row with signer ID, signer printed name, meaning, record reference, record version hash, timestamp in UTC, source IP and device fingerprint. The audit trail is append-only and protected by RLS so no tenant user — including platform admins — can edit historic rows.
7. Rendered PDFs (regulated-reports bucket) embed the §11.50 manifest in the record body, generated through the @react-pdf/renderer Worker-safe pipeline. The signing manifest is part of the rendered artifact, not an appendix.
8. Password policy is §11.300-compliant: periodic forced change, no recent reuse, lockout on failed attempts, immediate revocation on user disablement (which is itself a signed change-control event).
9. Validation pack documents the signing function with IQ/OQ/PQ evidence; any change to the signing path triggers re-qualification and bumps the V5 Ultimate PATCH version under the validation-versioning scheme.
10. Mobile-safe ≤390px rendering for every signing screen — operators on shop-floor handhelds get the same Part-11 controls as desktop reviewers, with no horizontal scroll.