User Access, Privileged Accounts, and Electronic Signatures

User-access controls establish who may enter a computerized system, which functions and records each person may use, and which actions can be attributed to that individual. Effective control requires more than passwords. It includes identity verification, access approval, role design, account provisioning, authentication, privileged-access management, activity monitoring, periodic review, and prompt removal.

Electronic signatures add another control layer. They associate an identified individual with a specific record and defined action, such as review, approval, authorship, or acceptance. System login alone should not automatically be treated as an electronic signature.

The control strategy should reflect:

• the system’s intended use;
• criticality of its functions and data;
• consequences of unauthorized activity;
• administrative capabilities;
• remote-access arrangements;
• applicable predicate-rule records;
• 21 CFR Part 11 applicability; and
• available preventive and detective controls.

Identity and Account Lifecycle

Each human user should have an individually assigned identity that can be traced throughout the account lifecycle. The lifecycle should cover:

1. identity verification;
2. access request;
3. approval;
4. account creation;
5. role assignment;
6. authentication setup;
7. access modification;
8. periodic review;
9. suspension; and
10. permanent removal.

Account records should identify:

• the user’s full name;
• unique user identification;
• department or organization;
• employment or contractor status;
• system and environment;
• approved role;
• approving process or data owner;
• effective date;
• relevant training status;
• subsequent access changes;
• suspension date;
• removal date; and
• reason for suspension or removal.

Account history should be retained according to the applicable record-retention requirements. Removing access should not remove the user’s identity from historical audit trails, electronic signatures, or regulated records.

Identity Verification

The organization should verify a person’s identity before issuing credentials or establishing an electronic signature.

Verification may rely on:

• employment or contractor onboarding records;
• government-issued identification;
• in-person verification;
• approved remote identity-proofing controls;
• corporate identity-management services; or
• another controlled method proportionate to the risk.

Identity verification should be completed by an authorized function and documented. The process should prevent:

• duplicate identities;
• use of another person’s identity;
• reissuance of a former employee’s identification code;
• assignment of credentials to an unverified contractor; or
• creation of accounts outside the approved process.

Under 21 CFR 11.100, each electronic signature must be unique to one individual and must not be reused or reassigned. The organization must also verify the person’s identity before establishing or sanctioning the electronic signature.

Unique User Accounts

Each person performing regulated activity should use a unique account. A unique account provides the basis for attribution, access restriction, audit trails, investigations, and electronic signatures.

User identifiers should:

• be unique within the applicable identity environment;
• remain associated with the original individual;
• not be recycled or reassigned;
• remain recognizable in historical records;
• be disabled when no longer required; and
• be distinguishable from service, interface, and emergency accounts.

A user account should not be renamed and transferred to a replacement employee. A new person requires a new identity and account.

Shared Accounts

Shared accounts should not be used for regulated activities requiring individual attribution. Shared accounts prevent reliable determination of:

• who entered or changed data;
• who performed a review;
• who approved a record;
• who changed configuration;
• who accessed sensitive information; or
• who caused a security or data-integrity event.

Situations such as shared laboratory workstations, manufacturing terminals, or controlled-room computers do not justify shared application accounts. Several users may use the same physical device while authenticating to the application with separate identities.

A device, service, or interface account may be technically shared by a non-human process, but it should not be used by personnel to perform normal business activity. Such accounts require separate controls described under “Service Accounts.”

Access Requests and Approval

Access should be granted only through a documented request and approval process. The request should identify:

• the user;
• the system;
• the requested environment;
• the required role;
• the business justification;
• expected duration;
• required training;
• privileged or remote-access needs; and
• any potential segregation-of-duties conflict.

Approval should normally involve the process owner, data owner, system owner, or another defined authority. Technical administrators may provision approved access but should not independently decide what business access a user requires.

Temporary employees, consultants, supplier personnel, and support engineers should have:

• a defined sponsor;
• approved purpose;
• appropriate confidentiality obligations;
• limited access duration;
• restricted permissions;
• monitored remote access where applicable; and
• prompt removal at the end of the assignment.

Role-Based Access Control

Role-based access control assigns permissions according to defined job responsibilities rather than creating an unrelated permission set for every user.

Typical roles may include:

• operator;
• analyst;
• reviewer;
• approver;
• supervisor;
• quality reviewer;
• report user;
• master-data administrator;
• system administrator;
• security administrator; and
• read-only inspector or auditor.

Each role should define permitted activities, including:

• record creation;
• data entry;
• data modification;
• record deletion or invalidation;
• review and approval;
• electronic signatures;
• audit-trail access;
• report generation;
• data export;
• master-data maintenance;
• configuration changes;
• user administration; and
• system administration.

The organization should maintain an approved role-permission matrix or equivalent specification. It should identify prohibited combinations and functions reserved for controlled administrators.

Role design should be verified during Computerized System Functional and Control Testing.

Least Privilege

Least privilege means assigning only the access required to perform authorized responsibilities.

It does not mean giving every user the lowest available role. It means selecting permissions that are sufficient for the assigned work without providing unnecessary capabilities.

Least-privilege assessment should consider whether the user can:

• change or delete regulated data;
• modify approved calculations;
• change record status;
• approve their own work;
• modify audit-trail settings;
• change system time;
• alter security settings;
• create other users;
• export complete datasets;
• change master data;
• modify interfaces;
• install software; or
• access the underlying database or file system.

Broad access should not be granted merely because the available system roles were poorly designed. Where supplier-defined roles are excessive, the organization should determine whether permissions can be refined or whether compensating controls are required.

Segregation of Duties

Segregation of duties prevents one individual from controlling incompatible activities without independent oversight. Relevant conflicts may include:

• creating and approving the same record;
• performing and independently reviewing the same test;
• creating users and approving their access;
• administering the system while routinely generating regulated data;
• modifying specifications and approving the resulting change;
• changing security settings and reviewing security activity;
• developing custom code and independently approving its release; or
• investigating an event involving the investigator’s own administrative actions.

Absolute separation may not be practical in every small organization or specialized system. Where incompatible duties cannot be fully separated, the risk should be documented and controlled through measures such as:

• independent review;
• restricted administrative procedures;
• enhanced audit logging;
• management authorization;
• time-limited privilege;
• second-person verification; or
• retrospective review by the Quality Unit.

Administrator Independence

Routine users should not possess administrative capabilities that allow them to alter the records or controls governing their own work.

Administrative independence is particularly important for:

• laboratory instrument systems;
• manufacturing systems;
• quality-management applications;
• audit-trail configuration;
• electronic signatures;
• security roles;
• system clocks;
• database access;
• file deletion;
• backup administration; and
• interface configuration.

Administration may be performed by information technology, a separate system-support group, or appropriately independent personnel. The required independence should reflect the system’s risk, architecture, and organizational size.

Where a subject-matter expert must perform both operational and administrative duties, separate named accounts should be used:

• a routine user account for normal GMP work; and
• a privileged account used only for authorized administrative activity.

Privileged Accounts

Privileged accounts can modify the system, security model, configuration, underlying infrastructure, or regulated records outside ordinary workflows.

Examples include:

• application administrators;
• security administrators;
• database administrators;
• operating-system administrators;
• cloud-platform administrators;
• network administrators;
• backup administrators;
• domain administrators; and
• supplier support accounts.

Privileged accounts should be:

• individually assigned where technically possible;
• separately approved;
• restricted to authorized administrators;
• protected with strong authentication;
• used only for administrative work;
• prohibited from routine regulated processing;
• monitored through appropriate logging;
• periodically reviewed;
• disabled when not required; and
• promptly revoked following role change or departure.

Privileged activity logs should be protected from modification by the person whose actions are recorded. Monitoring should focus on meaningful events such as:

• account creation and deletion;
• role changes;
• security-setting changes;
• audit-trail changes;
• time changes;
• direct database activity;
• file deletion;
• configuration changes;
• backup or restoration activity; and
• disabling of monitoring controls.

The PIC/S Guidance on Data Integrity states that administrator rights for GMP-critical applications and infrastructure should be strictly controlled and should not be provided to normal system users.

Service Accounts

Service accounts are non-human identities used by applications, interfaces, schedulers, middleware, backup agents, monitoring tools, or automated processes.

Each service account should have:

• a defined technical purpose;
• an identified owner;
• documented system dependencies;
• least-privilege permissions;
• prohibited or restricted interactive login;
• protected credentials;
• controlled credential changes;
• monitored activity;
• periodic review; and
• a defined retirement process.

Service-account credentials should not be embedded in uncontrolled scripts, spreadsheets, configuration files, or source code. Where technically supported, credentials should be protected through managed secrets, certificates, tokens, or equivalent controls.

Password or certificate changes should be coordinated because an uncontrolled change may interrupt interfaces, backups, monitoring, or other critical services.

Service-account activity should be distinguishable from human-user activity. If personnel can use a service account interactively, reliable attribution is lost.

Authentication Controls

Authentication confirms that a person or technical process controls the credentials associated with a recognized identity. The authentication method should reflect:

• sensitivity of the functions and data;
• consequences of unauthorized access;
• remote-access exposure;
• privileged capabilities;
• system limitations;
• threat environment; and
• available monitoring controls.

Authentication methods may include:

• identification code and password;
• smart card;
• hardware or software authenticator;
• cryptographic certificate;
• passkey;
• biometric factor;
• or a controlled combination of factors.

Successful login should create a session associated with the authenticated identity. The system should not allow users to change identity within the same session without appropriate reauthentication.

Password Controls

Where passwords are used, controls should address:

• minimum length;
• prohibited weak or compromised passwords;
• protection during entry and transmission;
• secure storage;
• initial password issuance;
• required change of temporary passwords;
• password reset;
• suspected compromise;
• failed attempts;
• reuse restrictions;
• disclosure prohibition; and
• account recovery.

Passwords should not be:

• shared;
• displayed in readable form;
• transmitted through unsecured channels;
• recorded on uncontrolled lists;
• embedded in ordinary procedures; or
• retained by supervisors for employee accounts.

21 CFR 11.300 requires controls to maintain the uniqueness of identification-code and password combinations. It also requires periodic checking, recall, or revision as appropriate, loss-management procedures, safeguards against unauthorized use, and testing of devices that generate or contain identification information.

This requirement should not be reduced to automatic password expiration alone. The organization should consider password compromise, authenticator risk, technical capability, and current security practices when defining the control.

Multifactor Authentication

Multifactor authentication requires more than one distinct authentication factor, such as:

• something the user knows;
• something the user possesses; and
• something inherent to the user.

Multifactor authentication is not explicitly required by Part 11 for every computerized system. It should be applied according to risk.

It is particularly appropriate for:

• remote access;
• privileged accounts;
• cloud administration;
• access from unmanaged networks;
• access to highly critical data;
• security-management functions; and
• systems exposed beyond a controlled internal environment.

Multifactor authentication does not correct excessive permissions or weak role design. It strengthens authentication but does not replace authorization, monitoring, or segregation of duties.

Current technical authentication practices are addressed in the NIST Digital Identity Guidelines.

Session Management

Session controls protect an authenticated account after login. Controls should consider:

• automatic lock or termination after inactivity;
• reauthentication after session timeout;
• protection against session reuse;
• logout at the end of work;
• concurrent-session restrictions;
• workstation locking;
• browser and token security;
• reauthentication before critical actions; and
• protection of unattended shared workstations.

Timeout values should reflect the operating environment. A short timeout may be appropriate for an unattended laboratory workstation but disruptive during a long manufacturing operation. Where automatic timeout could interrupt a controlled process, alternative protections should be documented.

A locked workstation should preserve the active process without allowing another person to continue under the first user’s identity.

Failed Login Handling

The system should detect and respond to repeated unsuccessful authentication attempts. Controls may include:

• temporary lockout;
• increasing delay between attempts;
• security alerts;
• notification to the user;
• administrator investigation;
• monitoring for distributed attacks; and
• documented account recovery.

The response should avoid creating a denial-of-service vulnerability in which an unauthorized person can permanently disable critical operational accounts.

Failed-login records should identify the account, time, source, and outcome to the extent supported by the system.

Remote Access

Remote access creates additional risks because the user, device, and network may be outside the controlled site environment. Remote-access controls should include, as appropriate:

• formal authorization;
• secure encrypted connections;
• multifactor authentication;
• approved devices;
• network segmentation;
• restricted access paths;
• time-limited supplier access;
• activity logging;
• session monitoring;
• file-transfer restrictions;
• prohibition of uncontrolled local data storage;
• prompt access termination; and
• incident-response procedures.

Supplier support access should not remain permanently enabled merely for convenience. Activation, purpose, duration, actions performed, and closure should be documented.

Remote access should also be considered within Cybersecurity Controls for GMP Computerized Systems.

Periodic Access Review

Periodic access review confirms that active accounts and permissions remain appropriate. The review should include:

• active user accounts;
• inactive or dormant accounts;
• terminated or transferred personnel;
• contractors and supplier accounts;
• assigned roles;
• privileged accounts;
• service accounts;
• emergency accounts;
• remote-access authorization;
• segregation-of-duties conflicts; and
• unexplained accounts.

The reviewer should compare system access with current employment status, job responsibilities, approved requests, and training requirements. Simply asking a manager to approve an unchanged user list without reviewing permissions provides limited assurance.

Review frequency should reflect:

• system criticality;
• privilege level;
• personnel turnover;
• remote exposure;
• previous findings;
• supplier involvement; and
• ability to monitor access continuously.

Privileged and remote access may require more frequent review than ordinary read-only access.

Review evidence should document:

• scope;
• data source;
• review date;
• reviewer;
• exceptions;
• required changes;
• completion of changes; and
• approval or closure.

Emergency Access

Emergency or break-glass access may be needed when ordinary access is unavailable during a critical event. Emergency-access controls should define:

• permitted circumstances;
• authorization;
• account activation;
• available permissions;
• authentication;
• time limitation;
• logging;
• notification;
• post-use credential change;
• retrospective review; and
• prompt deactivation.

Emergency accounts should not become routine alternatives to the standard access process. Every use should be investigated sufficiently to confirm that the access was justified and that all actions were appropriate.

Electronic Signatures

An electronic signature is a computer-data compilation of a symbol or series of symbols executed, adopted, or authorized by an individual as the legally binding equivalent of a handwritten signature.

The signature should represent a deliberate action by an identified person. It should not be confused with:

• system login;
• record creation;
• clicking an ordinary navigation button;
• a typed name without controlled authentication;
• an image of a handwritten signature;
• an automatically populated user field; or
• a generic approval performed through a shared account.

A documented Part 11 assessment should identify where electronic signatures are used for required records and which controls apply.

Signature Meaning

Each electronic-signature function should have a defined meaning appropriate to the business action. Examples include:

• performed by;
• reviewed by;
• verified by;
• approved by;
• authorized by;
• released by;
• witnessed by;
• responsibility accepted by; or
• authorship confirmed by.

Generic labels such as “signed” or “completed” may be insufficient when the record requires a specific decision.

The signature meaning should be defined in:

• requirements;
• workflow specifications;
• configured action labels;
• procedures;
• training; and
• displayed signature information.

Different meanings should not be treated as interchangeable. A reviewer’s signature does not automatically constitute approval or release.

Signature Manifestation

Under 21 CFR 11.50, signed electronic records must 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.

This information must be subject to the same controls as the electronic records and must appear in human-readable forms of the record, such as displays or printouts.

The displayed date and time should be derived from a controlled system clock. Time-zone handling should be defined where users, systems, or records span different locations.

Signature-to-Record Linking

21 CFR 11.70 requires electronic signatures and handwritten signatures executed to electronic records to be linked to their respective records so that they cannot be excised, copied, or otherwise transferred to falsify another electronic record.

The system should therefore preserve the association between:

• signer;
• signed record;
• record version;
• signature meaning;
• signature date and time;
• workflow state; and
• subsequent changes.

A copied signature image or typed name does not provide this controlled linkage.

Where a signed record is changed after approval, the system should follow a defined behavior. Depending on the intended process, it may:

• invalidate the prior approval;
• require a new signature;
• create a new record version;
• preserve both versions;
• record the change in the audit trail; or
• prevent the change entirely.

Signature Components

For electronic signatures that are not based on biometrics, 21 CFR 11.200 requires at least two distinct identification components, such as an identification code and password.

During a single continuous period of controlled system access:

• the first signing should use all required signature components; and
• later signings may use at least one component executable only by the individual.

When signings are not performed during a single continuous period of controlled access, each signing should use all required signature components.

The signature action should require deliberate execution. A system should not automatically apply an electronic signature merely because the user previously logged in.

NSignature Attribution, Legal Intent, and FDA Certification

Electronic-signature controls should provide reliable evidence that a specific individual deliberately signed a specific record for a defined purpose. The controls should make the signed action attributable to that individual and prevent credible denial that the signature was executed.

Supporting controls include:

• verification of the individual’s identity before assigning the signature;
• a unique electronic signature that is never reassigned;
• signature credentials controlled exclusively by the individual;
• deliberate execution of each signature;
• a defined signature meaning, such as performed, reviewed, approved, or released;
• recording the signer’s printed name;
• recording the date and time of signing;
• permanent linkage between the signature and the applicable record and version;
• protected audit trails and signature information;
• procedures for reporting lost or compromised credentials;
• monitoring for unauthorized access or signature attempts; and
• training on the responsibilities and legal significance of electronic signatures.

A system login alone does not demonstrate that the user intentionally signed a record. The electronic signature should require a separate, deliberate action using the authentication components specified by the approved system design.

Under 21 CFR 11.100(c), persons using electronic signatures must certify to FDA that their electronic signatures are intended to be the legally binding equivalent of traditional handwritten signatures.

The organization should maintain evidence of the certification and be able to provide additional certification or testimony when requested by FDA.

Electronic-Signature Functional Testing

Electronic-signature testing should verify the complete configured behavior rather than only confirming that a signature button exists.

Testing should confirm:

• only authorized roles can sign;
• the signer must authenticate as required;
• one user cannot execute another user’s signature;
• the signature action is deliberate;
• the correct signature meanings are available;
• inappropriate meanings are unavailable;
• required comments or reasons are enforced;
• printed signer name is correct;
• signature date and time are correct;
• the signature is linked to the correct record and version;
• the signed record displays the signature information;
• reports and printouts include required signature manifestations;
• failed signature attempts are handled correctly;
• account lockout does not improperly bypass controls;
• changes after signing follow the approved workflow;
• copied or exported records do not falsely appear signed;
• audit trails record relevant signing events;
• session timeout affects signing as intended; and
• signatures remain accurate after backup, restoration, migration, and archival.

Negative testing should challenge:

• unauthorized signing;
• signing with another user’s credentials;
• signing without required authentication;
• approval of one’s own work where prohibited;
• signing an incomplete record;
• signing after session timeout;
• modifying an approved record;
• signature removal;
• signature transfer;
• incorrect system time; and
• use of disabled or suspended accounts.

Test evidence should include the executed action, expected result, actual result, record identifier, user role, date and time, and objective evidence.

Access-Control Records and Monitoring

Access controls should generate sufficient records to reconstruct important identity and authorization events. Relevant records may include:

• account creation;
• account activation;
• role assignment;
• permission changes;
• password reset;
• authenticator replacement;
• account suspension;
• account reactivation;
• account removal;
• failed login;
• privileged access;
• remote access;
• emergency access;
• signature execution; and
• security-configuration changes.

Monitoring should focus on meaningful exceptions rather than collecting logs that are never reviewed.

The relationship between security logs, GMP audit trails, and record review is addressed in Audit Trails, Data Changes, and Review Controls.

Supplier and Cloud Considerations

Supplier-hosted and cloud systems may divide responsibility for identity, authentication, application roles, platform administration, and infrastructure access among several organizations. The responsibility model should identify who controls:

• identity creation;
• authentication;
• multifactor authentication;
• application roles;
• privileged access;
• provider support access;
• subcontractor access;
• logging;
• access review;
• security incidents;
• account removal; and
• electronic-signature configuration.

The regulated organization should retain sufficient evidence to confirm that provider personnel and subcontractors cannot access or alter regulated data without authorization, traceability, and appropriate oversight.

These arrangements should be addressed in Cloud and SaaS Systems in GMP Environments and Computerized System Supplier Assessment and Evidence Leverage.

Maintaining Effective Access and Signature Controls

User access and electronic-signature controls must remain effective throughout the system lifecycle. They should be reassessed following:

• organizational changes;
• role redesign;
• new workflows;
• supplier releases;
• authentication changes;
• identity-provider changes;
• remote-access changes;
• security incidents;
• audit findings;
• system migration;
• infrastructure changes;
• mergers or site transfers;
• and significant regulatory or procedural changes.

Periodic review should confirm that:

• user lists remain accurate;
• privileges remain appropriate;
• administrators remain independent;
• service accounts remain necessary;
• shared accounts have not been introduced;
• remote access remains controlled;
• signature meanings remain correct;
• signature manifestations remain complete;
• signature-to-record linking remains effective; and
• identified weaknesses have been corrected.

The objective is to maintain reliable attribution and authorization. Every regulated action should be performed by an identified person or controlled technical process, using approved permissions, with sufficient evidence to determine what occurred and who was responsible.