Which 21 CFR Part 11 controls does Abundera Sign satisfy?

§11.10 (closed system controls, audit trail, operational checks, authority checks), §11.30 (open system controls via TLS 1.3 and document encryption), §11.50 (signed electronic records show signer name, signing date and time, and meaning of signature), §11.70 (signature is bound to the record so it cannot be excised or copied), §11.100 (unique signature per individual), §11.200 (two-component authentication via password plus SMS OTP or passkey), §11.300 (controls for identification codes and passwords).

Does Abundera Sign require Part 11 system validation (IQ/OQ/PQ)?

The regulated entity is responsible for validating any computerized system used in Part 11 workflows. Abundera Sign provides documentation that supports validation: a public OpenAPI spec, an immutable hash-chained audit log, RFC 3161 timestamp tokens issued by qualified TSAs, and AATL-certified signing keys backed by an HSM at Azure Key Vault (FIPS 140-2 Level 3). Customers under active QMS programs can request the technical evidence pack to support their own IQ/OQ/PQ documentation.

How does Abundera Sign meet §11.300 controls for identification codes?

Authentication is delegated to abundera.ai, the central identity hub, which supports passkeys (WebAuthn), passwords with rate limiting and lockout, SMS OTP for second factor, and government ID verification via Veriff. Each user receives a unique identifier; identification codes are not reused across accounts. Account lockout, password complexity, and session expiry are enforced centrally.

FDA-regulated industries

21 CFR Part 11, control by control

Q: How does Abundera Sign capture the meaning of a signature?

Senders can pre-assign a Part 11 meaning per signer at envelope create time via the signature_meaning field ('Approved by', 'Reviewed by', 'Authored by', 'Acknowledged by', 'Witnessed by', or a custom value up to 80 characters). When set, the meaning is captured in the immutable hash-chained audit trail at sign time, rendered on the Certificate of Completion that ships with every signed PDF, and attested in the cryptographic PAdES signature Reason field that covers the whole document. Per-signature-block rendering on the document face and signer-selected meaning at signing time are on the near-term roadmap.

Q: Is the audit trail tamper-evident?

Yes. Every audit entry contains a SHA-256 hash that includes the previous entry's hash, forming a Merkle-style chain. Any modification to a prior entry would invalidate every subsequent hash. The chain is anchored to GitHub at fixed intervals and timestamped by RFC 3161 TSAs (DigiCert and Sectigo), so the chain head is fixed at a public point in time and cannot be back-dated.

For pharmaceutical, biotech, medical device, and clinical research teams using electronic records and signatures under FDA jurisdiction. This page maps Abundera Sign to each Part 11 control so your QA and validation teams can review the technical basis directly.

§11.10Closed system controls

Procedures and controls for closed systems holding electronic records.

Validated computerized system, Cloudflare Pages on a defined runtime with reproducible deploys
Ability to discern invalid or altered records, every artifact is SHA-256 hashed and recorded in the audit trail
System access limited to authorized individuals, JWT plus product-scoped API key with KV-cached revocation
Secure, computer-generated, time-stamped audit trails recording the date and time of operator entries and actions that create, modify, or delete electronic records (see §11.10(e))
Operational system checks to enforce permitted sequencing of steps and events, signing order enforcement and gate-by-gate evidence capture
Authority checks ensure only authorized individuals can use the system, electronically sign a record, access the operation or computer system input or output device, alter a record, or perform the operation at hand

§11.10(e)Audit trail

Secure, computer-generated, time-stamped audit trail.

Every audit entry is hashed with SHA-256 and includes the previous entry's hash, the chain breaks if any prior entry is modified
Timestamps are recorded in UTC with millisecond precision on the system clock and counter-signed by RFC 3161 trusted timestamp authorities (DigiCert primary, Sectigo secondary)
Audit trail captures: envelope creation, signer view, access code entry, OTP send and verify, field changes, signature submission, decline, delegation, clause flagging, seal, and download
Audit records are retained for the full envelope retention period (3 to 99 years) in WORM (Write Once Read Many) storage
Audit trail is available for FDA inspection through the public verify API and a downloadable JSON export

§11.30Open system controls

Additional controls when records flow over an open network.

TLS 1.3 in transit, terminated at Cloudflare edge with HSTS preload
Document content stored in encrypted R2 buckets at rest
PAdES-LTA digital signature embeds the document hash inside the cryptographic signature, so any byte change invalidates the signature
HMAC-signed webhook callbacks to customer endpoints
Content Security Policy restricts script sources, the signing surface uses strict same-origin script policy

§11.50Signature manifestation

Signed records must clearly display the printed name, date and time of signing, and meaning of the signature.

Printed signer name on every signature block, captured from the verified profile, not user-typed at signing time
Signing date and time in UTC with millisecond precision, anchored to the RFC 3161 timestamp token
Meaning of signature, sender pre-assignable per signer via the signature_meaning field on envelope create (Approved by, Reviewed by, Authored by, Acknowledged by, Witnessed by, or a custom 80-character string). Captured at sign time in the immutable hash-chained audit trail, rendered on the Certificate of Completion, and attested in the cryptographic PAdES signature Reason field that covers the whole document. Per-signature-block rendering on the document face is on the near-term roadmap
Signature block also shows IP address, user agent, geolocation (if captured), and signature evidence hash for cross-reference with the audit trail
Certificate of Completion appended to every signed PDF aggregates all of the above per signer plus the hash chain head

§11.70Signature/record linking

Signatures must be linked to records so they cannot be excised, copied, or transferred.

PAdES-LTA embeds the cryptographic signature inside the PDF, the signature covers the entire byte range of the document
AATL-certified signing certificate, issued to Abundera, Inc., backed by an RSA-3072 key in Azure Key Vault HSM (FIPS 140-2 Level 3)
Removing the signed PDF from its evidence package does not weaken admissibility, the public verify endpoint resolves the document hash to the sealed evidence record
Long Term Validation (LTV) information embedded so the signature remains verifiable after the signing certificate expires

§11.100Unique signatures

Each electronic signature shall be unique to one individual and shall not be reused by, or reassigned to, anyone else.

Signature identity tied to the signer's verified email address and, for high-assurance flows, a passkey (WebAuthn) bound to the signer's authenticator
Signing tokens are 256-bit CSPRNG, stored as SHA-256 hashes, single-use, and rotated to fresh tokens for any re-send
Delegation creates a new signer record with a fresh signing token and a delegation audit event linking it to the original
Signer profiles store verified attributes (verified email, optional government ID, optional passkey credential) per individual

§11.200Non-biometric signature components

Non-biometric electronic signatures must use at least two distinct identification components.

Component one, signing token delivered to the signer's verified email address
Component two, SMS one-time passcode to the signer's verified phone number (or passkey biometric for Professional plus tier)
OTP rate limited to 3 sends per signer, 60 second cooldown, 3 verification attempts per code
For continuous-session signing, signer must re-authenticate after any session break before completing the signing event

§11.300Identification codes / passwords

Controls to ensure the security and integrity of identification codes and passwords.

Identity is centralized at abundera.ai (the parent product), users do not maintain separate credentials for Abundera Sign
Uniqueness of code and password combination enforced at the central identity hub
Periodic re-validation through passkey or password rotation, configurable per organization
Account lockout after failed attempts, alerting to security operations on anomalous activity
Lost or compromised tokens can be revoked through the dashboard or by API call, revocation is reflected immediately in the KV cache

What is on the roadmap

Signer-selected meaning of signature at signing time (in addition to today's sender-assigned meaning), a Part 11 envelope mode that forces 2FA plus reason-for-change capture plus meaning selection on every signing event, and a published validation pack (IQ/OQ/PQ templates) to accelerate customer system validation. Email compliance@abundera.ai if your QA team needs a target date.

Frequently asked questions

Is Abundera Sign 21 CFR Part 11 compliant?

Part 11 compliance is a property of how a regulated entity uses the system, not the software alone. Abundera Sign provides the technical controls Part 11 requires. The regulated entity is responsible for system validation in its environment, SOPs, and operating under a quality management system.

What evidence does Abundera Sign produce for an FDA audit?

Every signed envelope produces a sealed evidence package containing the signed PDF (with embedded PAdES-LTA signature and RFC 3161 timestamp), Certificate of Completion, hash-chained audit trail, signature data per signer, and external anchors. The package is stored in WORM buckets with retention locks of 3 to 99 years depending on plan.

Does Abundera Sign require system validation (IQ/OQ/PQ)?

The regulated entity is responsible for validation. Abundera Sign provides the technical evidence pack on request to customers under active QMS programs: OpenAPI spec, immutable audit log, RFC 3161 tokens, and AATL-certified signing keys backed by an HSM.

How is signature meaning captured?

Sender pre-assigns the meaning per signer at envelope create time (signature_meaning field). It is captured in the hash-chained audit trail at sign time, rendered on the Certificate of Completion appended to every signed PDF, and attested in the cryptographic PAdES Reason field that covers the whole document. Per-signature-block rendering on the document face and signer-selected meaning at signing time are on the near-term roadmap.

Is the audit trail tamper-evident?

Yes. Each entry hash includes the previous hash. The chain is anchored to GitHub at intervals and counter-signed by RFC 3161 timestamp authorities, so the chain head is fixed at a public point in time and cannot be back-dated.

Need a signed copy of the technical evidence pack, an MSA with FDA-applicable terms, or a quote for a Part 11 enterprise deployment? Email compliance@abundera.ai or see the Trust Center for the full security and privacy posture.