What is an FDA 21 CFR 11 Compliant Electronic Signature?

Marion Lepmets _SoftComply_

Title 21 of the Code of Federal Regulations, Part 11, also known as 21 CFR 11, deals with the requirements for Electronic Records and Electronic Signatures to be considered “trustworthy” by the FDA.

If you work in the MedTech or Pharma sector, you probably have heard about this regulation plenty of times. And if you are an Atlassian user, you have probably seen it mentioned in several Apps, claiming to be compliant to it.

It is worth now to make some clarity around what this regulation exactly requires and what “compliant” apps means.

We will split this discussion in 2 posts, one for Electronic Records and one for Electronic Signatures.

Like any piece of regulation, it can be accessed for free, in this case here: FDA 21 CFR 11: Electronic Records, Electronic Signatures.

For the discussion on 21 CFR 11 compliant Electronic Records, please see the next blog post here.

Electronic Signatures

From 21 CFR 11.3:

Electronic signature means 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.

Digital signature means an electronic signature based upon cryptographic methods of originator authentication, computed by using a set of rules and a set of parameters such that the identity of the signer and the integrity of the data can be verified.

In simple words, digital signatures are electronic signatures where the signed document is accompanied by some sort of “certificate”. This allows to verify the authenticity of a signed document when it is transferred between users. But in order to be able to verify a digitally signed document, “signer” and “recipient” must use some sort of common software, e.g. Adobe Sign.

To Electronically Sign a document means more generally the execution of a series of actions that are secret and unique to each user. Excluding biometric methods, this is typically achieved with a unique ID and a “secret” (e.g. username and password or token.)

Do I need Digital Signatures to be compliant?

No.

The FDA requires Electronic Signatures, not necessarily Digital. Furthermore, if you submit a Digitally Signed PDF document to the FDA or Notified Body, most likely they will not be able to trust your certificate.

Technical requirements for Electronic Signatures

Note: biometrics based signatures are not discussed in this post.

#	Requirement	which means…	Common misconceptions	What to look for in an App
1.	Employ at least two distinct identification components such as an identification code and password.	Username + password/token, or something like this. To be entered every time you apply your e-signature.	Ticking a box is not sufficient. An “Approved” sent by email is neither. Nor typing your name at the bottom of the document. They are not “unique” actions.	The App must require every user to set up their secret.
2.	When an individual executes a series of signings during a single, continuous period of controlled system access, the first signing shall be executed using all electronic signature components; subsequent signings shall be executed using at least one electronic signature component that is only executable by, and designed to be used only by, the individual. When an individual executes one or more signings not performed during a single, continuous period of controlled system access, each signing shall be executed using all of the electronic signature components.	Typically this is achieved by signing into Confluence/Jira (where you have to enter your ID), then after that you can sign documents using only the password/token.	You do not need to enter both ID and secret every single time.	The secret must be asked by the App every time a signature is required.
3.	Be used only by their genuine owners.	“Secrets” must be, well, secret.	Password or account sharing is a big no-no. Seriously.	The App should not share the secret with any user, not even Admins.
4.	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.	A single user must not be able to “impersonate” another user. This is something Admins can sometimes do.	It is NOT ok for admins to take control of someone else’s account and signature, not even if required.	Given that in the Atlassian ecosystem accounts can be managed, Admins can potentially log in with other user’s credentials. This means that the App must use secrets that are not the Atlassian account login password.
5.	Maintaining the uniqueness of each combined identification code and password, such that no two individuals have the same combination of identification code and password.	No two users can have the same ID and password.	The secret is not the only important part of the signature.	In general, the user Atlassian account ID takes care of it. Every user has a unique Atlassian ID. Email addresses are also a safe choice. Having said that, be careful if the App requires to enter/create additional IDs that can be duplicated.
6.	Ensuring that identification code and password issuances are periodically checked, recalled, or revised (e.g., to cover such events as password aging).	Secrets can’t last forever.	Password must be changed regularly.	Make sure that if the App uses passwords, they expire regularly and must be changed. If the App uses TOTP tokens then you are ok, as they last only 30 seconds.
7.	Following loss management procedures to electronically deauthorize lost, stolen, missing, or otherwise potentially compromised tokens, cards, and other devices that bear or generate identification code or password information, and to issue temporary or permanent replacements using suitable, rigorous controls.	It must be possible to block the ability of the user to sign a document. E.g. recalling the signature.	Just creating another account if one is compromised is not sufficient. You have to block the compromised one too.	The App should allow Admins to recall user’s' signatures if necessary.
8.	Use of transaction safeguards to prevent unauthorized use of passwords and/or identification codes, and to detect and report in an immediate and urgent manner any attempts at their unauthorized use to the system security unit, and, as appropriate, to organizational management.	Keep an eye out for potential breaches, bruteforce attacks, and more. Report it to the Admins.		The ability to identify failed signature attempts and act if they become “too many”, e.g. blocking a signature after N unsuccessful attempts.
9.	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.	If the secret is generated by electronic means (e.g. TOTP tokens on mobile Authenticator Apps), there must be some sort of check on how they are generated.	Pick a reliable TOTP App.	The Atlassian Apps cannot do much for this requirement, unless it comes with its own TOTP mobile App. For large companies that provide company mobile devices, this can be easily achieved by locking the devices and installing appropriate security software. Otherwise, the company must ensure that users have basic notions of cyber-hygiene and can use a mobile device in a secure manner.
10.	Signed electronic records shall contain information associated with the signing that clearly indicates all of the following: The printed name of the signer; The date and time when the signature was executed; and The meaning (such as review, approval, responsibility, or authorship) associated with the signature.	Name, timestamp and action must be part of the document being signed.	It’s not enough to have this information somewhere in the system. They must be inside the document.	The ability to create the so-called Change History Table containing all this information, or at least the ability to visualize this information.
11.	Electronic signatures and handwritten signatures executed to electronic records shall be linked to their respective electronic records to ensure that the signatures cannot be excised, copied, or otherwise transferred to falsify an electronic record by ordinary means.	Once applied, signatures cannot be modified by anyone. Signatures must remain with the original document when copied. It must be 100% clear who-signed-what.		The App must have a solid way to link signatures to documents. Signature must not be modifiable.

Conclusion

If you are looking for an App with 21 CFR 11 compliant electronic signatures, make sure you understand what part of 21 CFR 11 it complies to. As compliance to this regulation is not certifiable, use a checklist like the one above to ensure you are picking the right tool.

The SoftComply Document Manager on Confluence Cloud meets the requirements of 21 CFR 11 for electronic signature and electronic records. You can try it out for free for 30 days.