21 CFR Part 11 Compliance
This page describes how Medtech OS electronic signatures comply with 21 CFR Part 11. It is intended for customers implementing Medtech OS in a regulated environment and for auditors evaluating the system.
For user-facing guides, see the Signing and Audit Trail sections of the Medtech OS Reference.
Shared Responsibility
21 CFR Part 11 compliance is a shared responsibility between Innolitics (the Medtech OS vendor) and the customer organization. Innolitics is responsible for building and maintaining the system controls—cryptographic protections, audit trails, access controls, and signature integrity features. The customer organization is responsible for operational controls—validating the system for their intended use, maintaining written policies, managing signer credentials, and submitting required certifications to the FDA.
The traceability table below identifies each CFR requirement and whether it is met by Innolitics, the customer, or both. For guidance on customer validation activities, see the Client Validation Plan and the Client Validation Risk Assessment.
Overview
Medtech OS implements electronic signatures using two distinct identification components per signing event: the signer’s full name and a signing password. Each signing link is a single-use, cryptographically random token bound to a specific signer and revision. Signing tokens are stored as SHA-256 hashes (never in plaintext). Passwords are stored using bcrypt one-way adaptive hashing.
All signature records are immutable and include the signer’s printed name, UTC timestamp, signature meaning, and a SHA-256 hash of the signed document. A separate customer-visible audit trail records successful user-initiated controlled-record actions, including signatures, and preserves actor, record, timing, source, artifact, and integrity evidence. The trail is forward-only from deployment and verifies a tamper-evident sequence for each workspace.
Traceability
The table below maps each applicable 21 CFR Part 11 requirement to the responsible party and a description of how it is met.
| CFR Section | CFR Requirement | Responsibility | How It Is Met |
|---|---|---|---|
| § 11.10(a) | System validation for accuracy, reliability, consistent performance | Shared | Innolitics validates and tests the system. The customer validates it for their intended use per their own procedures. See the Client Validation Plan for guidance. |
| § 11.10(b) | Generate accurate, complete copies of records in human-readable and electronic form | Innolitics | Signed PDF includes a human-readable signature page. PDF artifacts are archived and attached to Notion. |
| § 11.10(c) | Protection of records for accurate retrieval throughout retention period | Innolitics | Signature records and customer audit events are retained without alteration. Artifacts are tenant-scoped and versioned. |
| § 11.10(d) | Limit system access to authorized individuals | Innolitics | Each signer must have a registered account. Signing tokens are bound to a specific signer and revision. |
| § 11.10(e) | Secure, computer-generated, time-stamped audit trails; changes must not obscure prior entries | Innolitics | The customer audit trail records signed Obsolete and Restore actions and automatic Supersede transitions alongside other successful controlled-record actions. It preserves the signed reason, affected revisions, causal approver, operator and recording times in an append-only, per-workspace tamper-evident sequence. |
| § 11.10(f) | Operational system checks to enforce permitted sequencing | Innolitics | System enforces sequencing. A revision must be in “Draft” before signatures begin. Refresh is blocked for In Review, In Approval, Approved, and Superseded revisions, while deletion is blocked for Approved and Superseded controlled history. |
| § 11.10(g) | Authority checks: only authorized individuals can sign | Innolitics | Identity verified via registration. Signing tokens bound to specific signer. |
| § 11.10(j) | Written policies holding individuals accountable for actions under their signatures | Customer | The customer organization must maintain written policies. The system enforces accountability by requiring individual authentication per signature. |
| § 11.10(k) | Controls over systems documentation including change control and audit trails | Customer | Covered by the customer’s document control and change management processes. |
| § 11.30 | Open systems: encryption and digital signature standards | Innolitics | All signing interactions over HTTPS. Signing tokens are cryptographically random. Document integrity ensured via SHA-256 hash in signature records. |
| § 11.50(a) | Signed records must include the printed name, date/time, and meaning of the signature | Innolitics | Every signature record includes the signer’s printed name, UTC timestamp, and meaning. Meaning is displayed on the signing page and recorded in the Signed PDF. |
| § 11.50(b) | Signature manifestation items subject to same controls as electronic records | Innolitics | Signature records are immutable and covered by the audit trail. |
| § 11.70 | Signatures linked to records so they cannot be excised, copied, or transferred | Innolitics | Each signature includes a SHA-256 hash of the signed document, cryptographically binding the signature to the specific artifact version. |
| § 11.100(a) | Each signature unique to one individual, not reused or reassigned | Innolitics | Each signer has a unique account with a unique email address. |
| § 11.100(b) | Organization must verify signer identity before assigning signature | Customer | The customer adds the person to the People database with a verified email. This constitutes identity verification. |
| § 11.100(c) | Certification to FDA that electronic signatures are legally binding | Customer | The customer submits a Letter of Non-Repudiation Agreement to the FDA. One-time organizational action. |
| § 11.200(a)(1) | Non-biometric signatures must employ at least two distinct identification components | Innolitics | Signing requires full name (identification component 1) and signing password (identification component 2). |
| § 11.200(a)(1)(ii) | Non-continuous session signings require all components | Innolitics | Each signing via email link is a non-continuous session; both components are always required. |
| § 11.200(a)(2) | Signatures used only by their genuine owners | Innolitics | Passwords are hashed; signing tokens are bound to specific signers. |
| § 11.200(a)(3) | Attempted use by non-owner requires collaboration of two or more individuals | Innolitics | An attacker would need both access to the signer’s email (to obtain the signing link) and knowledge of their signing password. |
| § 11.300(a) | Uniqueness of each identification code + password combination | Innolitics | Each signer has a unique account with a unique email address. |
| § 11.300(b) | Periodic checking, recall, or revision of credentials | Shared | Innolitics provides tools for administrators to deactivate signers and reset passwords. The customer maintains a periodic review schedule as a procedural control. |
| § 11.300(c) | Loss management for compromised credentials | Shared | Innolitics provides automatic account lockout after failed attempts. The customer’s workspace administrator resets credentials when needed. |
| § 11.300(d) | Transaction safeguards; detect and report unauthorized use attempts | Innolitics | Failed authentication attempts are logged with email and timestamp. Account locked after consecutive failures with administrator notification. |
| § 11.300(e) | Testing of devices bearing identification information | N/A | System uses passwords, not hardware tokens or cards. |