Implementing Electronic Signatures
at PLC Level

When an E-Signature Is Required vs When It Is Not

The most important design decision in e-signature implementation is correctly identifying which actions require a formal electronic signature and which require only an authenticated action. These are different requirements under 21 CFR Part 11, and confusing them leads to either over-engineering (adding e-sig prompts to every operator interaction) or under-engineering (missing actions that genuinely require one).

An authenticated action is any system interaction that is attributed to a specific user via their logged-in session — changing a setpoint, acknowledging an alarm, starting a sequence. The audit trail records who did it, when, and what changed. This is the standard operating mode for all GxP SCADA actions. It does not require a separate signature prompt.

An electronic signature, by contrast, is required when a specific person must formally and intentionally certify or approve a record at a defined point in time — and that approval has regulatory significance. The distinction is intent: the person must actively affirm "I approve this specific record" rather than simply performing an action while logged in.

What Part 11 Actually Requires for E-Signatures

21 CFR Part 11 Subpart C defines the technical requirements for electronic signatures on computer systems used in FDA-regulated environments. The requirements for non-biometric e-signatures (the type used on virtually all pharma automation systems) are specific:

• Unique identification code plus password — the combination of a unique individual user ID and a password that only that person knows. Shared accounts are prohibited for e-signature purposes. The person signing must re-enter their credentials at the point of signing, even if they are already logged into the system.
• Re-entry of credentials at time of signing — the signature event requires active re-authentication. Being logged in is not sufficient. The system must present a signature prompt that requires the person to enter their ID and password again.
• Signed manifestation — the signature must be permanently linked to the specific record being signed. It cannot be transferred, cut and pasted, or reused for a different record. The signed record must display: the printed name of the signer, the date and time of signing, and the meaning of the signature (e.g., "Approved", "Reviewed and Released", "Authorised by").
• Audit trail entry — each e-signature event must generate an audit trail record containing the user ID, the signature meaning, the timestamp, and a reference to the specific record or action signed.

Implementation Architecture — Where the Logic Lives

On a modern pharma automation system, the e-signature mechanism is almost always implemented at the SCADA/HMI layer, not in the PLC programme itself. The PLC does not have a credential store, a certificate authority, or a UI capable of presenting a compliant signature prompt. What the PLC does have is the authenticated user session passed from the SCADA — a user ID token that the PLC can reference when writing audit trail records.

The practical architecture is: the SCADA presents the e-signature dialog, validates the credentials against the site Active Directory or local security server, and only then sends the authorised command to the PLC. The PLC receives the command with the authorising user ID attached, executes the action, and logs the user ID in the audit trail record. The e-signature itself lives in the SCADA layer; the audit trail evidence of the authorised action lives in both the SCADA audit trail and the PLC audit trail.

SCADA E-Signature Design — The Five Required Elements

The e-signature dialog in the SCADA must implement all five elements required by Part 11 Subpart C. Missing any one of them makes the e-signature non-compliant regardless of how well the rest of the system is designed.

PLC-Side Requirements — What the Programme Must Do

Even though the e-signature credential validation happens in the SCADA layer, the PLC programme has specific responsibilities that must be designed and validated:

Receiving and Storing the Authorising User ID

When the SCADA sends an e-signed command to the PLC — recipe activation, safety interlock bypass with dual authorisation, batch phase approval — it must include the authorising user ID as part of the command data, not just the command itself. The PLC receives a structured data type: command + user ID + timestamp + signature meaning code. The FB_AuditTrail call for that action logs all four elements. An audit trail entry that records "recipe activated" without the authorising user ID is incomplete under Part 11.

Blocking Actions That Require E-Signature If None Is Present

The PLC must not execute actions that are designated as requiring e-signature if the command arrives without a valid user ID token. This is the PLC-side enforcement of the requirement. If a command arrives via direct tag write (from an engineering tool bypassing the SCADA UI, for example) with no user ID, the PLC must reject it and log the attempt. The interlock logic is straightforward: the authorisation bit for e-signed actions is only set by the SCADA after successful credential validation, not by the PLC programme itself.

Dual Authorisation for High-Risk Actions

Some actions on pharma systems require two independent e-signatures — typically for safety-critical overrides, batch release, or changes to validated setpoints. The PLC data structure for these actions carries two user ID fields (initiator and approver), and both must be present and different before the action can execute. The SCADA sequencing is: initiator signs → PLC holds the action in a pending state with initiator ID stored → second person signs as approver → PLC receives approver ID, verifies it differs from initiator ID, executes action, logs both IDs in the audit trail.

Closed Systems vs Open Systems — The Part 11 Context

The open vs closed system classification under Part 11 affects how stringent the e-signature controls need to be. A closed system — one where access is controlled to authorised individuals through physical and logical means — has somewhat lighter requirements than an open system where external parties can access the electronic records.

Most pharma PLC/SCADA systems are classified as closed systems: the OT network is segregated, the workstations are in controlled areas, access requires site credentials, and the system is not accessible from the internet. In a closed system, the username + password combination for e-signatures is sufficient without additional biometric or token-based methods. The classification must be documented in the FDS and confirmed in the IQ network segregation verification.

OQ Validation of E-Signatures

The OQ must verify each of the five Part 11 elements for every e-signature event type on the system. The test cases are more specific than most first-time engineers expect:

• Attempt the e-signed action while logged in — verify the system presents a re-entry credential prompt and does not proceed on session authentication alone
• Enter incorrect credentials at the e-sig prompt — verify the action is blocked and the failed attempt is recorded in the audit trail with the attempting user ID
• Complete a valid e-signature — verify the signed record displays: signer's printed name, date/time of signing, and signature meaning before and after signing
• Verify the audit trail record contains all required fields: user ID, signature meaning, timestamp, and specific record/action reference
• For dual authorisation: attempt to approve using the same user ID as the initiator — verify the system blocks the approval and logs the attempt
• Verify the e-sig record cannot be modified via SQL or any other mechanism (same write-once verification as the general audit trail)