SCADA User Management
for 21 CFR Part 11

What Part 11 Actually Requires on User Accounts

21 CFR Part 11 Subpart B deals with electronic records and the controls around them. Subpart C deals with electronic signatures. Both have direct implications for how user accounts are configured on a pharma SCADA, and they go further than most engineers expect when they first encounter them.

The core requirements that flow through to user management are: individuals must be uniquely identified on the system (§11.10(d)); system access must be limited based on authority (§11.10(d)); there must be procedures for authorising, creating, and removing access (§11.10(i)); and the system must generate secure, computer-generated audit trails that capture the individual user identity associated with each action (§11.10(e)). Every user account design decision you make — how many roles, what each role can do, how passwords work, what happens when someone leaves — traces back to these requirements.

The open versus closed system classification also matters here. A closed system — where only authorised personnel have access — can rely on the system's own logical controls. An open system needs additional procedural and cryptographic controls. Almost all pharma SCADA systems are closed systems, but the classification must be explicitly stated in your FDS and URS.

The Four-Role Model — Why It Works

The most common mistake in SCADA user management design is either too few roles (Operator and Admin, full stop) or too many (a bespoke role for every person). The four-role model hits the right balance between granularity and manageability, and it maps directly to the actual job functions in a pharmaceutical manufacturing environment.

Read-Only exists for a reason that surprises some engineers: QA reviewers and auditors need to access the system to review process data and audit trail records without any possibility of inadvertently changing anything. A role with zero write access, properly enforced at the software level, gives QA confidence that their review activity will not affect the system state and cannot generate spurious audit trail entries.

The Operator role covers the day-to-day actions of a process technician: acknowledging alarms, initiating permitted manual sequences, exporting process data. It does not include setpoint modification — that requires a Supervisor. This boundary is important: setpoint changes are high-impact actions with direct quality consequences, and the audit trail on a setpoint change must show a Supervisor-level identity, not an operator.

Supervisor covers process engineers and shift leads who need to modify setpoints, initiate the sanitization sequence, or authorise alarm suppression. The specific actions that require Supervisor role must be defined in the FDS User Role Access Matrix — not just described in policy but enforced at the software level such that an Operator-role account literally cannot execute them.

Administrator is a small population: typically the Automation Engineer, the IT contact, and the Validation Lead. It covers everything that changes the system configuration — user account management, system clock modification, remote access grants. Critically, no individual should be the only Administrator. A minimum of two people hold Administrator role so that account management is not blocked if one person is unavailable.

Active Directory Integration — The Right Architecture

The question of whether to use Active Directory integration or local SCADA security server accounts comes up on every pharma project. The right answer for most sites is AD integration with a local account fallback.

AD integration means that users authenticate with their domain username and password — the same credentials they use for their workstation, email, and other site systems. Password policy is enforced at the domain level by Group Policy, so there is a single enforced standard across all systems. When a user leaves the site and their AD account is disabled, their SCADA access is automatically revoked. There is no risk of a departed employee's SCADA account remaining active because someone forgot to remove it from a local security server list.

The AD group mapping must be documented: the domain group Group_PWS_Operators maps to the Operator role in the SCADA security server, Group_PWS_Supervisors maps to Supervisor, and so on. Adding a user to the correct AD group grants them the correct SCADA role. Removing them from the group revokes it. The mapping is defined in the FDS User Role Access Matrix and verified in the OQ.

The fallback to local accounts matters because AD infrastructure can be unavailable — planned maintenance, network issues, a domain controller failure. The SCADA must not become completely inaccessible because AD is down. Local accounts with the same password policy requirements provide continuity. The key constraint is that local accounts must never be the primary method of access — they are a documented fallback, their existence is justified in the SDS, and their use is logged.

Password Policy — The Parameters That Must Be Defined

Saying "the system has a password policy" is not sufficient for a QA review. Every parameter of the policy must be explicitly defined in the SDS and verified with boundary tests during OQ. Vague policies like "strong passwords are required" cannot be verified — and therefore cannot be validated.

The boundary testing methodology matters. The OQ test for minimum password length is not "set a short password and see if it is rejected." It is: attempt exactly 9 characters (boundary below limit) and confirm rejection; then attempt exactly 10 characters (limit value) and confirm acceptance. The boundary test generates unambiguous evidence that the enforcement is correctly configured at the specified threshold, not somewhere close to it.

Account lockout after exactly 3 consecutive failures — not 2, not 4 — is another boundary test. The OQ makes 2 failed attempts and confirms the account is still active. The 3rd attempt locks it. The OQ then confirms that the locked account cannot be unlocked by the account holder themselves, only by an Administrator. This test is generating evidence against a specific Part 11 requirement (§11.300(d)) and must be documented accordingly.

Unique Accounts and Concurrent Login Prevention

Part 11 §11.300(b) requires that user identification codes are unique and that use of identification codes is periodically checked. The practical implication at the software level is that no two people share an account and no account is used simultaneously by two people.

Shared accounts — "Operator" as a generic login, "Shift1" — are not compliant regardless of how well the rest of the system is configured. The audit trail entry for a setpoint change by "Operator" cannot be attributed to a specific individual. The audit trail is useless for its primary purpose, which is attribution of actions to responsible persons.

The concurrent login prevention requirement is enforced at the software level: the SCADA security server is configured to detect when a second login attempt is made for an account that is already active. The system either blocks the new login or forces out the previous session — which approach is used should be defined in the SDS (both are compliant; the choice has operational implications). Either way, the event is audit-trailed. The OQ includes a specific test for this: log in on workstation WS-01 with a named account, then attempt to log in with the same account on WS-02 and verify the correct behaviour is triggered and recorded.

What Audit Trail the User Management System Must Generate

The audit trail requirements for user management actions are distinct from the process audit trail. The following events must each generate an audit trail entry with timestamp, user ID, and action detail:

• Login and logout — every session start and end, with user ID and workstation.
• Failed login attempts — each failed attempt, with the username attempted and workstation.
• Account creation, modification, and deletion — by the Administrator who made the change.
• Account lockout — triggered by 3 consecutive failures, with the username locked.
• Role changes — when a user's role is changed, recording old role, new role, and who made the change.
• Session timeout — when a session times out due to inactivity, not just when a user actively logs out.
• Concurrent login attempt — when a concurrent login is blocked or the previous session is forced out.

These events must be written to the same immutable historian that stores process data. They must not be stored only in Windows Event Viewer, which is not a validated record store and which an Administrator can clear. The SCADA security event historian should be subject to the same retention requirements — typically seven years — as the process audit trail.

OQ Test Coverage

Three OQ test cases cover user management: the full four-role regression (OQ-010), unique account and concurrent login prevention (OQ-011), and password policy boundary testing (OQ-012).

OQ-010 tests every role boundary systematically: each of the four roles attempts all the actions it should be able to perform (confirming they work) and all the actions it should be blocked from (confirming they are blocked). Each blocked action must generate an audit trail entry recording the denied attempt with the user's ID. This is the test that proves the role matrix in FDS Appendix D is actually implemented in the software — not just described in a document.

OQ-012 includes boundary tests at exact parameter values for every password policy parameter in the table above. Each test case is referenced back to the specific URS requirement and FDS functional description it is verifying. The OQ evidence for these test cases — screenshots of rejections and acceptances at the boundary values — is the documented proof that the policy is enforced as specified.