Electronic Signatures

ProBeya Electronic Signatures provides a 21 CFR Part 11 compliant signing mechanism for regulated pharma and manufacturing environments. Every signature requires password re-entry, is secured with an HMAC-SHA256 integrity hash, and is recorded in an immutable audit trail -- ensuring that signed records meet the highest GxP documentation standards.

Overview

Pharmaceutical and manufacturing organizations operating under FDA 21 CFR Part 11, EU Annex 11, or similar regulations require electronic signatures that are legally equivalent to handwritten signatures. These signatures must be attributable to a specific individual, applied with intent, and verifiable for integrity after the fact.

ProBeya's Electronic Signatures feature meets these requirements by enforcing password re-entry for every signing event, generating a cryptographic integrity hash, and maintaining an immutable audit trail. Signatures can be applied to any entity in the system -- documents, deviations, CAPA records, audit reports, or custom entities.

Getting Started

1. Ensure users have passwords set -- Electronic signatures require bcrypt-hashed passwords. Users who authenticate solely via SSO/OIDC must have a local password configured for signing.
2. Apply a signature -- Navigate to any signable entity (document, CAPA, deviation record) and click the "Sign" button.
3. Re-enter your password -- Type your account password to confirm your identity. This is required for every individual signature.
4. Select a meaning -- Choose the signature meaning (e.g., "Authored", "Reviewed", "Approved", "Verified").
5. Add an optional comment -- Provide context for the signature if needed.
6. View signature history -- The signature panel on any entity shows all applied signatures with signer details and timestamps.

Key Concepts

• Signature Meaning -- The regulatory purpose of the signature (Authored, Reviewed, Approved, Verified, Rejected). Each signature must carry a meaning that reflects the signer's intent.
• Password Re-Entry -- Every signature requires the signer to re-enter their password, even if they are already logged in. This ensures the signature is an intentional act, not an accidental click.
• HMAC-SHA256 Integrity Hash -- Each signature record includes a cryptographic hash computed from the entity type, entity ID, signer ID, meaning, and timestamp. This hash can be re-verified later to detect tampering.
• Entity Type / Entity ID -- The generic reference system that allows signatures to be applied to any record. Common entity types include document, deviation, capa, audit_report, and change_control.
• Signature Chain -- The ordered sequence of all signatures on an entity. The chain's integrity can be verified in bulk using the verifySignature procedure.
• Immutable Record -- Signature records cannot be updated or deleted through the API. There are no update or delete procedures -- only create and read.

How It Works

Applying a Signature

When a user signs an entity, the system executes a four-step process:

1. Password verification -- The signer's password is fetched from the database and compared against the re-entered password using bcrypt. If the password is incorrect, the signature is rejected.
2. Record creation -- A new signature record is created with the entity reference, signer identity, meaning, server-side timestamp, and optional comment.
3. Hash generation -- An HMAC-SHA256 hash is computed using the AUTH_SECRET as the key and a canonical JSON representation of the signing payload. This hash is stored alongside the signature.
4. Activity logging -- The signing event is logged in the activity feed for audit trail visibility.

Viewing Signatures

The getSignatures procedure returns all signatures for a given entity, ordered by signing time (most recent first). Each result includes the signer's name and email from the users table for display purposes. All queries are filtered by organizationId for tenant isolation.

Verifying Integrity

The verifySignature procedure re-computes the HMAC hash for each signature on an entity and compares it against the stored hash. The verification report classifies each signature as:

• Valid -- Hash matches; the record has not been tampered with.
• Invalid -- Hash mismatch; possible data tampering detected.
• Unverifiable -- No stored hash (legacy record created before integrity hashing was added).

The overall chain is considered valid only if no signature is classified as "invalid".

Configuration

Setting	Description	Required
AUTH_SECRET	HMAC key for signature hash generation	Yes (shared with Auth.js)
User passwords	bcrypt-hashed passwords in the users table	Yes, for each signer

No additional feature flags are needed -- electronic signatures are available to all organizations. The feature relies on the existing AUTH_SECRET environment variable for HMAC key derivation.

Permissions

Role	Access
Any authenticated user	Can apply signatures to entities they have access to
Organization Owner / Admin	Can view all signatures across the organization
QA Auditor	Can verify signature chain integrity

The sign procedure uses orgProcedure, meaning any authenticated organization member can sign. Access to the entity itself (document, CAPA, etc.) is governed by the entity's own access control rules.

Tips & Best Practices

Require signatures in your workflow definitions

Configure your document approval workflows to require specific signature meanings at each stage. For example: Author signs as "Authored", QA signs as "Reviewed", and the responsible person signs as "Approved".

Run periodic integrity verification

Schedule monthly verification of signature chains on critical documents. This proactive check catches any data integrity issues before a regulatory audit surfaces them.

Use comments for context

When signing, add a brief comment explaining what was reviewed or why the approval was granted. This provides valuable context during audits and investigations without requiring a separate documentation step.

Ensure all signers have local passwords

Users who rely exclusively on SSO for login must also have a local password set for electronic signatures. The password re-entry requirement is a regulatory obligation -- SSO session tokens alone do not satisfy 21 CFR Part 11.

Troubleshooting

Issue	Cause	Solution
"User does not have a password set"	Signer's account has no bcrypt password hash	Set a local password for the user account, even if SSO is the primary login method
"Invalid password"	Incorrect password entered during re-entry	Re-enter the correct account password; this is the same password used for login
Signature hash verification shows "invalid"	Database record may have been modified outside the application	Investigate the database audit logs; escalate to IT security if tampering is confirmed
Signature hash shows "unverifiable"	Legacy record created before HMAC hashing was implemented	Not a security issue -- the record predates the integrity feature; consider re-signing if regulatory requirements demand it
Signatures not appearing on entity	Querying with wrong entity type or entity ID	Verify the entityType and entityId match the target record exactly

FAQ

Is the electronic signature legally binding under 21 CFR Part 11? ProBeya implements the technical controls required by 21 CFR Part 11: unique user identification, password re-entry for each signature, tamper-evident records, and complete audit trails. However, legal enforceability also depends on your organization's procedural controls (SOPs for signature policies, user training, access management). Consult your QA team to ensure procedural compliance complements the technical controls.

Can a signature be revoked or deleted? No. Signature records are immutable -- there are no update or delete procedures. This is by design for regulatory compliance. If a signature was applied in error, the correct approach is to apply a new signature with the meaning "Rejected" or "Superseded" and a comment explaining the correction.

What entity types support electronic signatures? Signatures use a generic entity type/entity ID reference system. Any record type can be signed -- common types include document, deviation, capa, audit_report, change_control, and custom entity types. The entity type is a free-text field, so it can be extended without schema changes.

What happens if AUTH_SECRET is rotated? If AUTH_SECRET changes, previously generated HMAC hashes will no longer verify because the new key produces different hashes. Plan key rotations carefully and consider re-signing critical records with the new key, or documenting the rotation in your audit trail.

Related Features

• GxP Compliance -- Comprehensive GxP compliance framework including 21 CFR Part 11 controls
• Approvals -- Workflow-based approval processes that can require electronic signatures
• Action Log -- Activity and audit trail for all system actions
• Cleanroom Management -- GxP-compliant cleanroom operations with audit trail