Recently, I was asked what are the 21 CFR Part 11 compliance implications with the following scenario:
The user (an Approver) used his id/password to login and continued his session and arrived at the "APPROVE NOW" screen. The software does not challenge the user (again) at the time of this critical event (e.g., APPROVAL) for his password again.
21 CFR Part 11: Authentication and Authorization
First, a little background on what the US Code of Federal Regulations has to say about electronic signatures. 21 CFR Part 11 uses "authority checks" to address two different aspects of information security - authentication and authorization.
Authentication concerns identifying the user:
11.10(d) Limiting system access to authorized individuals
Authentication also involves a procedural control, i.e., a controlled, documented, process for granting access to a new user and deleting a user account, before the userid and password are issued to the user.
Authorization concerns the level of access a particular authenticated user should have to secured resources controlled by the system:
11.10(g) Use of authority checks to ensure that 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.
(The clause in red concerns authentication and the clause in blue concerns authorization. I can understand the confusion caused by using "authorized" to describe authentication and combining both concepts into a single clause.)
Authorization also involves:
- Definitions of user privileges - different levels of access based on user responsibilities (if appropriate) that are documented and controlled (e.g., user access levels are approved by management prior to granting access to the user).
- Procedures - a controlled, documented, process for granting privleges to a new user, changing privileges for an existing user, and removing privileges.
- Software controls - the application verifies that an individual has the appropriate privileges to perform specific functions within the application before allowing them to do so (e.g., access the operation or computer system input or output device, alter a record, or perform the operation at hand). Specifically with regard to electronic signatures, the application verifies that an individual has the authority to electronically sign a record before allowing them to do so.
Cracking the Code
Now, with some background in 21 CFR Part 11, let's apply it to the scenario described above:
The user (an Approver) used his id/password to login [<=authentication] and continued his session and arrived at the "APPROVE NOW" screen. The software does not challenge the user (again) at the time of this critical event (e.g., APPROVAL) [<=authorization] for his password again.
Assuming the user has been properly authenticated with a userid/password login, the question now becomes does the person clicking "APPROVE" have the privilege to electronically sign the record. The risk is that between the time of authenticating the user and electronically signing the record, there is no way for the software to know if it's really the same user.
For example, an authorized user is authenticated (logs on) and then walks away from the device without locking it. A second person then uses the device to approve records (before a screen saver time out). Software that doesn't require some verification for an approval would have no way to know if the user is authorized. The only way the software would "know" at the time of the approval is to challenge the user to provide a shared secret, re-entry of the password.
For this reason, every electronic signature requires not only the meaning of the signature (such as review, approval, responsibility, or authorship) associated with the signature, but also the entry of the shared secret (password):
11.200(a)(1)(i) When an individual executes a series of signing during a single, continuous period of controlled system access, the first signing shall be executed using all electronic signature components [<=initial authorization, not authentication]; 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 [<=subsequent authorizations].
AND there should be a policy in place regarding NOT sharing passwords:
11.200(a)(3) 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 use of a userid and password to login to software is an issue of authentication and is performed once to identify the user and permit access to the software. This authentication does NOT address the requirement for authorization to electronically sign and approve electronic records, which must be done for each record. In short, since the software in question doesn't require the entry of a password for the electronic signature when approving electronic records, it doesn't comply with the requirements of 21 CFR Part 11.