Electronic Signatures

Overview

An electronic signature confirms that a specific person performed or approved a specific action, as required by 21 CFR Part 11 subpart C. Signing means re-entering your password in the Electronic Signature dialog and selecting a meaning such as Approval, Review, or Responsibility, with an optional comment.

Each signature stores the signer, the date and time of signing, the meaning, the comment, and the action it was issued for. Signatures are stored permanently and are linked to the audit trail records of the signed action, so the signed change and its signature can always be reviewed together. The signing itself is also recorded in the audit trail as a security event, including failed signing attempts.

When the Dialog Appears

While Part 11 compliance mode is enabled, the Electronic Signature dialog opens before any action in a category selected under Signature Required Actions in the Part 11 Compliance (21 CFR) section on the Parameters page. The action executes only after a valid signature; Cancel leaves the system unchanged.

Disabling Part 11 compliance mode always requires an electronic signature, independent of the selection above. This applies on the Parameters page and through the configuration API and MCP. Configuration changes, including importing a project and changing user accounts, are recorded in the audit trail without a signature.

Signature Required Variables

Signature Required is a setting of every variable, on the General tab of the Add variable and Edit variable dialogs of each device type and of Local Variables, and it is also available as a table column, shown with Columns as described in the Configuration Tables article. Write variables marked Signature Required applies to the variables that have it selected: select it on the variables whose writes are an approval point, for example a setpoint that defines product quality, and clear it on the variables whose writes the audit trail documents without a signature.

A write is checked in this order: the write rights of the user (User Groups), the value range (Min Scaled and Max Scaled), and then the signature. A write that the rights or the range refuse therefore does not open the Electronic Signature dialog and leaves no signature record.

The upgrade rule keeps a validated system unchanged: before this setting existed, Write variable values signed every variable write, so after the upgrade every variable still asks for a signature. Clear Signature Required on the variables that need no signature as part of the change control of the upgrade.

For the variables of a UDT instance, Signature Required is a setting of the variable member in the UDT definition, and Push applies it to every instance. An instance takes the setting over for one variable with Override in the Asset Manager.

Through the configuration API and MCP the setting is the SignatureRequired field of each variable and UDT variable member. A create that omits it follows the defaults above; an update writes the value it is sent, like every other field of the row.

When Signatures Are Required

Whether a record must be signed at all is determined by the applicable predicate rule, the underlying regulation such as 21 CFR Part 211, and not by Part 11 itself. 21 CFR 11.50 and 11.200 apply only to records that are actually signed. Records the system generates on its own, such as alarms activating and clearing, events being logged, and trend data being sampled, therefore carry no signature requirement. These records must be trustworthy: protected against change, stamped with computer-generated UTC timestamps, and attributable to a person where a person acted on them. The historian and the Audit Trail provide exactly that. See FDA Guidance for Industry, Part 11, Electronic Records; Electronic Signatures - Scope and Application (August 2003).

Routine operator actions follow the same logic. Acknowledging an alarm or writing a setpoint is expected to be recorded in the audit trail per 21 CFR 11.10(e), capturing who performed the action, when, and what changed. An audit trail record documents the action; it is not an electronic signature and is not required to be one.

Electronic signatures are expected at the approval points named by the predicate rules: batch release and production record review under 21 CFR 211.192, master production and control records under 21 CFR 211.186, and approving or downloading a master recipe to production. These approval points map onto the Signature Required Actions setting in the Part 11 Compliance (21 CFR) section on the Parameters page: the site quality team selects which operator actions cross that line for their process, and for variable writes it selects the variables, with Signature Required. A typical pharmaceutical deployment selects Download recipes to the process and leaves alarm acknowledgement as a one-click action backed by the audit trail.

Signatures apply to operator actions. Building and changing the project, including importing a project and administering user accounts, is engineering work and the responsibility of the system integrator: every configuration change is recorded in the audit trail, and its approval follows the site change control procedure. Disabling Part 11 compliance mode is the one configuration change that requires a signature.

The default, with no categories selected, is deliberate. Signatures are friction by design, and requiring them on routine actions trains operators to enter their password reflexively, which weakens the control at the approval moments where it matters. Recommended practice: audit everything, and sign only what the site SOP designates as an approval.

Signing

The Electronic Signature dialog contains the following fields. The user name is fixed to the logged-in user: a signature can only be issued for your own identity, and the password is verified against that account through the same verification path as the login page, including Active Directory accounts and login throttling.

Press Sign to complete the signature and execute the action, or Cancel to abandon it.

How a Signature Is Recorded

Completing a signature does two things. It records a signature manifest and it links that manifest to the audit trail record of the action that was signed.

The signature manifest is the 21 CFR 11.50 record of what the signature means. It stores the signer, the signer's user name, the date and time in UTC, the meaning, the optional comment, and which identification components were used (both the user name and password, or the password only for a later signing in the same continuous session).

The signing act itself is recorded in the audit trail as a Security record with the action Sign, so the trail always shows that a signing took place. The audit trail record of the signed action then carries the Signature ID of that manifest. The Signature ID column is available in the Columns picker on the Audit Trail page and is included in the CSV export, so a reviewer can see which action a signature authorized.

The link is permanent by design (21 CFR 11.70). The signature fields are part of the content that is hashed into the audit record's chained hash, so a signature cannot be removed from its record or copied to a different record without breaking chain verification. This is the same hash chain described in the Audit Trail article.

The Printed Name (Full Name)

21 CFR 11.50(a)(1) requires a signed record to show the printed name of the signer. Each user account has a Full Name field on the Users page. The signature records this Full Name as the printed name and freezes it onto the signature at the moment of signing, so it stays fixed even if the account is later renamed or removed (21 CFR 11.70).

While Part 11 Compliance Mode is enabled, a local account must have a Full Name set before it can sign. If the Full Name is empty, the signature dialog reports that a full name is required and the signing is refused until an administrator sets it on the Users page. Populate the Full Name of every account that will sign as part of account setup. Setting or changing a Full Name is an ordinary user account change on the Users page.

Accounts authenticated through Active Directory have no local Users record; for these the account name is used as the printed name.

API Usage

API and MCP clients sign in two steps. First, POST /API/Signature/Verify with the credentials, the meaning, an optional comment, and the action key. The endpoint verifies the credentials, records the signature, and returns a token. Second, repeat the protected request with the token in the X-Signature-Token header. The token is single use, is bound to the requested action key and user, and expires after 2 minutes.

When a protected endpoint is called without a valid token, it answers with signatureRequired true, the action key, and the configured meanings, which is also how the GUI knows to open the signature dialog.

WriteVariable on the Runtime API and the WriteVariable MCP tool answer signatureRequired for a variable that has Signature Required selected; other variables are written directly.

POST http://127.0.0.1/API/Signature/Verify
Content-Type: application/json

{
  "userName": "jsmith",
  "password": "********",
  "meaning": "Approval",
  "comment": "Setpoint change approved",
  "actionKey": "Variable.Write"
}

Response:
{
  "token": "0b1c2d3e4f...",
  "signatureId": 42,
  "expiresUtc": "2026-07-15T09:32:00.0000000Z"
}

Then repeat the protected request with the header:
X-Signature-Token: 0b1c2d3e4f...

MCP clients run the same flow with tools. Call the SignAction tool with the same fields to record the signature and obtain the token, then repeat the protected tool call with the token in its signatureToken argument. A tool call carries no request headers, so the token travels as a tool argument instead of the X-Signature-Token header, and the signature record, the single use rule, the 2 minute validity and the link into the audit trail are the same as for an API client.

Related Settings

The following settings tune the signing behavior. Signature Meanings and Always Require Both Signature Components are set in the Part 11 Compliance section of the Parameters page, and Enforce Single Session in its Login and Password Policy section; all three are also available through the configuration API under the parameter names below. Changes apply without a restart.