Implementing E-Signatures
in SCADA for
Batch Release

What Part 11 Subpart C Actually Requires

Most engineers implementing e-signatures in a SCADA for the first time read 21 CFR Part 11 and walk away with a vague sense that signatures need a username and password. That is necessary but not sufficient. Part 11 Subpart C — Sections 11.50, 11.70, 11.100, and 11.200 — defines five distinct requirements, all of which must be met simultaneously for a signature to be compliant.

The five requirements are: the signature must be linked to the specific record being signed (not just to a session or a time period), the signature must carry a printed name, date, time, and the meaning of the signature, the signed record must be unalterable after signing, the signature must use a unique identification code plus password (two distinct components — not a single token or biometric unless specifically validated as a biometric system), and the system must ensure that only the genuine owner of the credentials is using them at the time of signing.

The last requirement — genuine owner — is the one that creates the most implementation complexity. Part 11 does not allow a session login to serve as the e-signature. An operator who logged in at 08:00 and is still in session at 14:30 cannot approve a record by clicking a button that uses their existing session credentials. The e-signature event must re-prompt for credentials at the moment of signing. This is the distinction between authentication (logging in) and electronic signature (signing a specific record).

The Five-Step E-Signature Sequence

A compliant e-signature implementation in a SCADA follows a defined five-step sequence. This sequence must be documented in the FDS (as FUNC-SEC-004 or equivalent) and verified step-by-step at OQ. Deviating from the sequence — even in a minor way, such as pre-populating the password field or showing the credentials dialog before the record — is a design non-compliance.

Step 1 — Display the record: The complete record requiring signature must be displayed in full before the credentials dialog appears. The operator must be able to read what they are signing. A system that shows the credentials dialog first, then the record, does not satisfy the signed manifestation requirement — the signature precedes knowledge of what was signed.

Step 2 — Username pre-populated, not editable: The username field is populated from the active session and cannot be modified. This ensures attribution — the signer cannot claim someone else's identity.

Step 3 — Password blank, not pre-populated: The password field is blank and must be re-entered at this moment. A session token, a remembered credential, or a biometric bypass does not satisfy this requirement unless the system is specifically validated as a biometric e-signature system under Part 11.300. This is the step most platforms get wrong — many SCADA platforms have a "single sign-on" or "use session credentials" shortcut that appears to work but fails Part 11.

Step 4 — Meaning selection from a defined list: The signer must select the meaning of their signature from a controlled list. Free-text meaning fields are not compliant — they allow the meaning to be altered or left blank. The defined list is specified in the FDS and must not be modifiable by Operator or Supervisor roles. Typical values: Approved, Reviewed, Released. The list must be documented — an inspector can ask "what are the valid signature meanings for this system?" and the answer must be in the FDS.

Step 5 — Confirm, write, lock: On confirmation, three things happen simultaneously: the audit trail entry is written (user ID, timestamp, record reference, meaning), the signature is permanently linked to the specific record, and the record is locked against further modification. The lock is enforced at the application layer — a locked record cannot be edited through any SCADA interface regardless of role.

Which Records Need E-Signatures

Not every SCADA action requires an e-signature. The GMP requirement is that records requiring a signature under predicate rules — the FDA regulations that govern the activity, independent of Part 11 — must carry a compliant e-signature when those records are in electronic form. Part 11 governs the technical implementation of the signature; the predicate rule governs whether a signature is required at all.

In practice, on a pharma SCADA, the records most commonly requiring e-signature are: critical process records that require QA approval before use (for example, a sanitization cycle record before the sanitized loop is returned to service), batch or production records at release, GMP configuration changes at the SCADA level (alarm setpoint approvals, sequence parameter approvals), and periodic review sign-offs.

Setpoint changes by a Supervisor do not typically require an e-signature — they require audit trail attribution (which is automatic) and a mandatory reason field. The distinction is important: audit trail with authentication is not an e-signature. An e-signature is a deliberate act applied to a specific closed record. A setpoint change is a parameter modification with an audit trail entry. Conflating the two creates either over-engineering (requiring formal e-signatures on every parameter change, which is impractical) or under-engineering (treating audit trail entries as e-signatures, which does not satisfy Part 11).

Platform Implementation — What to Watch For

Every major SCADA platform has a mechanism for implementing e-signatures, but the default configuration on most platforms does not satisfy Part 11 out of the box. The engineer must configure it explicitly to meet all five requirements above.

In Ignition the e-signature component in the Vision or Perspective module provides the signature dialog — but the default configuration often uses the session user without re-prompting for the password. The password re-entry must be explicitly configured. In WinCC the electronic signature function requires configuration of the sign-off dialog with mandatory password entry — the "use current login" option must be disabled for GMP records. In FactoryTalk View SE the Audit feature handles signature events, but the meaning list and record-locking behaviour must be configured in the Audit settings. In Wonderware InTouch the e-signature control built into the InTouch security model supports all five steps when configured correctly — the key configuration points are: display record before credentials (sequence enforced by script order), password field blank on open, meaning list defined in InTouch security configuration, and record lock on confirm implemented via script that removes write access from the record object.

Regardless of platform, the SDS must document the specific implementation — which module or component handles the signature, how the five-step sequence is enforced, and what happens if the password entry fails (the record must remain in its pre-signature state, and the failed attempt must be logged).

The Signed Manifestation Requirement

Part 11 Section 11.50 requires that signed electronic records contain information associated with the signing that clearly indicates the printed name of the signer, the date and time when the signature was executed, and the meaning of the signature. The signed manifestation is the permanent printed record of those three elements — it is part of the record itself, not a separate log entry.

In practice this means the record, as stored and as exportable for review, must show a signature block that is visually part of the document: name, timestamp, and meaning, displayed in a way that cannot be separated from the record content. A record that stores signature data only in a separate database table — where the record display and the signature data are two independent objects — does not satisfy the signed manifestation requirement if the signature data can be deleted or orphaned from the record without detection.

The certified copy export (FUNC-DATA-003) must include the full signature block. When a QA reviewer requests a certified copy of a signed record, the exported PDF must show the signer name, timestamp, and meaning as part of the document. An export that strips the signature block and shows only the process data is not a compliant certified copy of a signed record.

OQ Testing for E-Signatures

The OQ test for e-signatures must verify all five steps of the sequence and include adversarial tests for the failure conditions. The positive test — completing the signature correctly and verifying the audit trail entry — is table stakes. The adversarial tests are what distinguish a validated e-signature from an assumed one.

• Correct sequence test: Execute all five steps in order. Verify the audit trail entry contains user ID, record reference, timestamp, and meaning. Verify the record is locked — attempt to edit a field in the signed record and confirm it is rejected.
• Wrong password test: At step 3, enter an incorrect password. The signature must be rejected. The record must remain in its pre-signature state (unsigned). The failed attempt must generate an audit trail entry noting the failed signature attempt with the user ID and timestamp.
• Session credential bypass test: If the platform has any mechanism that could allow the session credentials to satisfy the password requirement without re-entry, this must be tested and confirmed to be disabled. The test must verify that re-entry is required even for a user who authenticated 30 seconds ago.
• Record lock test: After a successful signature, attempt to modify any field in the signed record. Must be rejected for all roles including Administrator. Attempt via the SCADA HMI and — if possible — via direct database access. Both must be prevented or detected.
• Certified copy includes signature block: Export the signed record as a certified copy. Verify the exported document contains the signer name, timestamp, and meaning as part of the document content — not as a separate attachment or footnote.