Electronic Signatures Without a Vendor

What Part 11 actually requires

21 CFR 11.100 says electronic signatures must be unique to one individual, must not be reused or reassigned, and must be verified before use. 11.200 says non-biometric signatures must employ at least two distinct identification components (e.g., a password and a token). These requirements exist because the FDA needs to know that a specific human approved a specific record at a specific time.

The industry response has been to buy SaaS signing platforms. DocuSign Enterprise costs $25-50 per user per month. Adobe Sign runs similar. Both require internet connectivity, both send document data to external servers, and both introduce a vendor dependency into the compliance chain.

None of that is required by the regulation. Part 11 requires two-factor verification and an audit trail. It does not require a cloud service.

How Signal implements it

Signal's electronic signature system uses two standard-library primitives:

Factor 1: Password (something you know)

Passwords are hashed with hashlib.scrypt, the memory-hard key derivation function in Python's standard library. The parameters (N=16384, r=8, p=1) are chosen to make brute-force attacks computationally expensive while keeping verification under 100ms on commodity hardware. Each user gets a unique cryptographic salt. The password hash is stored; the password is not.

Factor 2: TOTP (something you have)

Time-based one-time passwords follow RFC 6238, implemented from hmac, struct, and base64. The user enrolls by scanning a QR code (or entering a base32 secret manually) into any standard authenticator app: Google Authenticator, Authy, 1Password, or a hardware token. The server generates a 6-digit code from the shared secret and the current 30-second time window. If the code matches, the second factor is verified.

No external TOTP library is imported. The implementation is 40 lines of Python using only standard-library modules. This is not novel engineering. It is a well-understood algorithm that has been in production across the industry for over a decade.

The signing process

When a user signs a record in Signal, four things happen:

1. The user provides their password. The system verifies it against the stored scrypt hash.
2. The user provides a TOTP code from their authenticator app. The system verifies it against the shared secret.
3. If both factors pass, a signature record is created: the user, the deployment, the record being signed, the meaning of the signature (e.g., "reviewed", "approved", "released"), the reason, and a SHA-256 hash of the signature content.
4. The signature event is witnessed to the Aletheia ledger. The witness entry includes the signature hash, so the signature itself becomes part of the tamper-evident chain.

Signature verification is a read operation: given a signature ID, the system recomputes the hash from the stored components and compares it to the recorded hash. If they match and the chain is valid, the signature is verified. No network call. No vendor API.

Access controls and emergency access

The signature system sits on top of a role-based access control layer. Users are assigned roles. Roles carry permissions. Permissions gate actions. Every permission check is witnessed to the ledger.

HIPAA 164.312(a)(2)(ii) requires an emergency access procedure for electronic PHI. Signal implements this as time-bounded break-glass access: an authorized user can grant temporary elevated permissions to another user for a specified number of minutes. The grant, the use, and the expiration are all witnessed. When the time window closes, the elevated permissions are automatically revoked.

HIPAA 164.312(a)(2)(iii) requires automatic logoff. Signal implements session idle timeout: if a session is inactive for a configurable period (default 30 minutes), it is invalidated. The next request requires re-authentication.

Why this matters

The compliance industry has trained organizations to believe that regulatory requirements require SaaS vendors. For electronic signatures, this is not true. The regulation requires two-factor verification and an audit trail. The Python standard library provides both. The result is an electronic signature system that:

• Runs on the client's own hardware with no internet dependency
• Never sends signature data, passwords, or TOTP secrets to any external server
• Works offline, including in air-gapped environments (ITAR, classified)
• Has zero vendor lock-in (the data is SQLite; the code is standard Python)
• Costs nothing per signature (no per-envelope or per-user SaaS fees)
• Produces a cryptographic audit trail that satisfies Part 11, HIPAA, and CMMC simultaneously

The signature system is part of Signal's operational intelligence platform. It is not sold separately. But the methodology is published here because the insight -- that Part 11 electronic signatures do not require a SaaS vendor -- is useful to any organization in a regulated industry.