Electronic signature testing under 21 CFR Part 11

What is actually under test when you test a signature?

A stored data compilation and its attachment to one record. 11.3(b)(7) defines an electronic signature as "a computer data compilation of any symbol or series of symbols executed, adopted, or authorized by an individual to be the legally binding equivalent of the individual's handwritten signature", and section 11.70 then requires that compilation to be tied to its record so it "cannot be excised, copied, or otherwise transferred to falsify an electronic record by ordinary means". Two objects therefore go into the test plan: the thing stored when someone signs, and the fixity of its attachment.

Everything else in the suite falls out of four sections. section 11.50 governs what a reader sees. section 11.100 governs who may hold the credential. section 11.200 governs how it is executed. And section 11.300 governs the identification code and password behind it, where that is what the signature is made of. None of the four is under enforcement discretion: the 2003 Scope and Application guidance names the electronic signature requirements among the provisions it will continue to enforce, and closes that passage with "We expect continued compliance with these provisions, and we will continue to enforce them." Which records on your system are Part 11 records at all is a prior question, answered on what Part 11 asks of a computerised system.

In what order do the signature cases run?

The credential is settled first, then the execution rules, then the record, then the attempts that have to fail. Running the manifestation checks before the identity model is settled produces screenshots that have to be retaken.

What has to be visible on the signed record?

Three items, and the check runs twice on each. 11.50(a) requires signed electronic records to contain information associated with the signing that clearly indicates the printed name of the signer, the date and time when the signature was executed, and the meaning associated with the signature, such as review, approval, responsibility or authorship. 11.50(b) requires those three items to be subject to the same controls as for electronic records and to be included as part of any human readable form of the electronic record, "such as electronic display or printout".

The second run is where implementations part company. A screen that renders the signature block from a template and a PDF exporter that draws its own header are different code paths, and the meaning of the signing is the item that usually survives in one and not the other. The word "printed" in 11.50(a)(1) is doing work as well: a login identifier is not a printed name, and a suite that asserts on the user ID column will pass over the defect.

Items 21 CFR 11.50 requires on a signed record, each paired with a test case that fails a common electronic signature implementation.

Item in 11.50(a)	Case that fails a common implementation
(1) printed name of the signer	The block shows the account identifier. The person's name is held elsewhere and never joined
(2) date and time of execution	The stored value is the time the row was written, not the time the signer confirmed. The two differ under retry
(2) date and time of execution	The display renders in the reader's local zone with no zone stated, so two readers of one printout disagree
(3) meaning of the signature	The system supports one signing action, and the meaning is implied by the workflow step instead of stored
(3) meaning of the signature	Two meanings exist, and the export template hard-codes the first
11.50(b) human readable form	The screen carries all three items. The PDF carries two

Each row is a test case with a stored expected value, which is what puts it into the protocol set described under validation documentation.

How do the two components behave across a session?

11.200(a)(1) requires an electronic signature not based upon biometrics to employ at least two distinct identification components, "such as an identification code and password". The behaviour that has to be demonstrated is in the two sub-clauses under it, and they define the session case.

11.200(a)(1)(i) applies "when an individual executes a series of signings during a single, continuous period of controlled system access": the first signing is executed using all of the electronic signature components, and subsequent signings are executed using at least one electronic signature component that is only executable by, and designed to be used only by, the individual. 11.200(a)(1)(ii) covers signings not performed during a single continuous period, and requires each of them to be executed using all of the electronic signature components.

That turns into four cases, and the last one finds the defects.

Four session cases for electronic signing under 21 CFR Part 11, with the signature components the system has to demand in each.

Case	What the system has to demand
First signing in a fresh session	All components
Second signing in the same session	At least one component, and one that only the individual can execute
Signing after the continuous period ends	All components again
Signing after the period ends in a way your specification did not anticipate: the tab left open past an idle timeout, the session resumed from a remembered token, the second browser window, the mobile client holding its own session	All components, on each of those routes

The fourth case is where the specification has to say what a single, continuous period of controlled system access means on your system, because the clause sets the rule and your architecture decides where the period ends. A test cannot assert on a boundary nobody has written down. Fixing that boundary in the requirement, then tracing all four cases back to it, is the traceability work that FDA software validation carries.

The component demanded in case 2 has its own trap. The clause requires a component executable only by the individual, so a second signing that asks again for the identification code meets the count while missing the sentence: an identification code is frequently visible to colleagues, printed on a roster or derived from an email address.

Can one person use somebody else's signature?

11.200(a)(2) requires signatures to be used only by their genuine owners. 11.200(a)(3) is the testable form of it: signatures shall be administered and executed to ensure that attempted use of an individual's electronic signature by anyone other than its genuine owner requires collaboration of two or more individuals. The test question is therefore a count, and the case is written as an enumeration of single-actor paths to another person's signature.

The paths that exist in real systems are administrative. An administrator who can reset a password and then sign is one individual acting alone. So is a support role that can impersonate a user for troubleshooting, a database role that can write to the signature table, and a deployment account that can disable the challenge in configuration. Each is a case: attempt the path, record whether a second person was needed, and record what evidence of the attempt exists afterwards.

What happens to a signature when the signed record changes?

11.70 is a single paragraph with no sub-clauses, and it sets one standard: signatures shall be linked to their respective electronic records so they cannot be excised, copied, or otherwise transferred to falsify an electronic record by ordinary means. Ordinary means is the threshold, so the case list is an inventory of the ordinary means your product ships.

Run each of these against a signed record and an unsigned one:

• The copy, clone or duplicate function in the application.
• Export to file, then edit the file, then import it back.
• The API that returns a record and the API that accepts one.
• The report or extract that carries the signature block into another document.
• A restore of a single record from backup into a different record's place.
• The migration path used at upgrade, which moves signatures in bulk.

The edit case is separate and it is the one most often left out of a protocol. A field changes on a record that was already signed. What the system does next is a design decision, and the test reads it out of your specification before it reads it off the screen: the signature stays and now attests to text nobody signed, or it is invalidated and the manifestation says so, or the record is locked and the change is refused. All three are implementable. Only one of them matches what your specification claims, and the human readable form under 11.50(b) has to tell a reader which state the record is in.

Whether the change itself was recorded is a different section and a different page. 11.10(e) governs the trail, and the evidence a trail test has to leave behind is set out on audit trail testing.

What does the credential itself have to prove?

11.100(a) requires each electronic signature to be unique to one individual and not reused by, or reassigned to, anyone else. The negative case is a leaver: end one account, create a new person, and attempt to issue the same identification code. Uniqueness in 11.300(a) is stated on the combination, that no two individuals have the same combined identification code and password, so a uniqueness test written on the code column alone answers the wrong sentence.

11.100(b) requires the organisation to verify the identity of the individual before it establishes, assigns, certifies or otherwise sanctions an electronic signature or any element of one. That control is procedural, and its output is a record held outside the application. The test is a sample: take signatures issued in the last period, and look for the identity verification record behind each one.

Two more controls in 11.300 produce evidence on a schedule, dated at every execution. 11.300(b) requires identification code and password issuances to be periodically checked, recalled or revised, covering for example password aging. 11.300(e) requires initial and periodic testing of devices, such as tokens or cards, that bear or generate identification code or password information, to ensure that they function properly and have not been altered in an unauthorized manner. Both need a schedule and a record of the last execution, and a system that enforces password expiry in configuration has still not produced the record that 11.300(b) asks for.

The certification under 11.100(c) sits outside the software entirely. Persons using electronic signatures certify to the agency, before or at the time of use, that the electronic signatures in their system used on or after 20 August 1997 are intended to be the legally binding equivalent of traditional handwritten signatures, and 11.100(c)(1) requires that certification to be signed with a traditional handwritten signature. Since the amendment at 88 FR 13018 of 2 March 2023, the section points to FDA's web page on Letters of Non-Repudiation Agreement for where it goes.

What does the run hand over?

Artefacts an electronic signature test run under 21 CFR Part 11 hands to an FDA investigator, with what each one shows.

Artefact	What an investigator gets from it
Signature meaning register	Every record type that can be signed, every meaning available on it, and the 11.50(a)(3) value stored for each
Manifestation evidence set	Screen capture and exported document for one signing of each meaning, with the three items of 11.50(a) marked on both
Session matrix	The four session cases, the components demanded in each, and the definition of the continuous period they were run against
Transfer attempt log	Every ordinary means tried under 11.70, the result of each, and the build it was tried on
Impersonation path enumeration	Each role that can reach another person's signature alone, and the control that now needs a second individual
Post-change state record	What a signed record and its manifestation show after an edit, against the specified behaviour
Credential control records	The identity verification sample for 11.100(b), the issuance review under 11.300(b), and the device test record under 11.300(e)

The suite behind those artefacts is regression material. Every release that touches authentication, PDF generation or the record model re-runs it, and keeping an automated suite inside a validated system carries its own conditions, covered under test automation in a validated environment.

The environment question arrives with it. Signature testing needs populated user accounts and records that look like the real ones, and on a clinical or a patient system those records are the sensitive part of the estate. We do not need production PHI to test. Environments run on synthetic and de-identified data. The rest of the terms, including the agreement that has to exist first, are set out at how we work with protected health information.

Where does a signature suite go wrong?

• The whole suite is written against the login screen, so 11.200(a)(1)(i) is never exercised at the point of signing.
• The manifestation is checked on screen only, and the export that an investigator would actually take away is never opened.
• The meaning of the signing is asserted as a non-empty string, so a build that writes the same meaning for every action passes.
• The session case is run twice in one session and never across the boundary, which leaves 11.200(a)(1)(ii) untested.
• Transfer attempts stop at the user interface, and the import path and the public API are left out of the inventory.
• The impersonation cases are run as an administrator, which is the one account for which the answer is uninteresting.
• The device test under 11.300(e) is recorded once at issue, against a requirement that reads initial and periodic.
• Signature timestamps are compared against the test machine clock, and the time zone the system documentation declares is never checked.
• Every case is positive, so the protocol contains no expected refusal and cannot fail.

On a trial platform the same suite has to run against the roles a study actually uses, which is part of what a clinical trial platform has to prove about its records and signatures.

Section numbers and quoted text on this page are read in 21 CFR Part 11, in the eCFR text current as of 31 August 2026, and from the 2003 Scope and Application guidance. Compliance itself is held by the organisation that ships the product. What the work above produces is the evidence that each of these sections was exercised on a named build.