Why RBAC Is a GMP Requirement, Not an IT Policy
Role-based access control sits at the intersection of two regulatory requirements. 21 CFR Part 11 requires that system access is limited to authorised individuals and that the system uses authority checks to ensure only authorised individuals can use the system, operate input or output devices, alter records, or perform operations. EU GMP Annex 11 Clause 12 requires that access to data is restricted to authorised personnel. Both translate to the same practical design requirement: the SCADA must know who is logged in, what they are permitted to do, and must actively enforce those permissions — not just display them.
The word "enforce" is key. A SCADA system that displays a note saying "setpoint changes are for Supervisors only" but allows any authenticated user to change setpoints does not satisfy the requirement. A SCADA that greys out the setpoint field for non-Supervisor roles but allows a direct database write to bypass the HMI does not satisfy the requirement. The enforcement must be at the application layer and verified adversarially at OQ.
The other critical point that gets missed on first pharma projects: RBAC is not just about restricting GMP-critical actions. It is also about audit trail attribution. Every GMP-relevant action must be attributable to a specific, named individual. If your RBAC design permits shared accounts, group logins, or generic "Operator" accounts for any GMP function, the audit trail cannot attribute actions to individuals, and the system does not meet the ALCOA+ Attributable requirement. See the audit trail implementation guide for the full attribution design.
The Four-Role Model — What Each Role Covers
Four roles is the standard for a GMP SCADA. More than four creates testing complexity without meaningful benefit at this system scale. Fewer than four cannot cleanly separate production operations from engineering configuration from quality oversight. The roles are cumulative — each higher role includes all permissions of the roles below it.
A design principle worth stating explicitly: Administrator accounts should be held by the fewest people possible. The Administrator role can create and disable user accounts, install software updates, and modify system configuration. In a GMP environment those are change-controlled activities. Having ten people with Administrator access is a design weakness, not a safety net. Two named Administrator accounts — typically the OT system administrator and the validation lead — is the right number for most systems. Both accounts are individual and named, never shared.
The Permission Matrix — Why It Must Be in the FDS
The role permission matrix must be documented in the FDS before development begins. It is not sufficient to describe the roles in prose — QA needs a table that shows every GMP-relevant function against every role, with explicit permit or deny for each cell. This table becomes the test basis for the OQ role regression. If the matrix does not exist before the OQ, the testers are making up expected results during execution, which is a GMP documentation failure.
The matrix must cover at minimum 16 function areas: view process data and trends, alarm acknowledgement, initiate manual sequences, generate reports, modify process setpoints, modify alarm setpoints, initiate critical sequences (sanitization, CIP, etc.), activate maintenance mode, suppress non-critical alarms, mode transitions, manage user accounts, configure system parameters, manage backup schedules, install updates, grant remote access, and suppress Critical alarms. Each cell is a binary: permitted or denied. There is no "partially permitted" — a function is either within a role's authority or it is not.
The Supervisor-to-Administrator boundary at user account management is the most commonly misconfigured permission in first-project SCADA systems. On many platforms, whoever configures the security server during development gives themselves Administrator rights — and then doesn't restrict the Supervisor role correctly. The OQ test is simple: as a Supervisor-role account, navigate to User Account Management. It must be blocked. If a Supervisor can create, modify, or disable user accounts, the role boundary is broken — and the audit trail attribution for any account changes during that period is unverifiable.
Password Policy — The Parameters That Must Survive Boundary Testing
Password policy is specified in the FDS and verified at OQ with boundary tests. Every parameter must be tested at its exact limit — not at a comfortable value well inside it. This is what distinguishes OQ from a functional check. The parameters and their boundary test approach:
- Minimum length — 10 characters: Test exactly 9 characters (must be rejected with an explicit message) then exactly 10 characters (must be accepted). Both steps are required. A system that rejects 9 characters but accepts 8 has a different actual boundary than the FDS specifies.
- Complexity: Uppercase, lowercase, numeric, and special character all required. Test a 10-character password that meets length but omits each complexity element in turn — each must be individually rejected with a message stating what is missing.
- Password history — last 12 blocked: The OQ cannot test all 12 history positions, but must at minimum verify that the current password is rejected on immediate reuse. Document the full history depth as an FDS/SDS specification item that is acceptance-tested by configuration review at IQ.
- Account lockout — 3 consecutive failures: Test exactly 2 failures (account must NOT be locked) then the 3rd failure (account must lock, and the lock must be total — not just a delay). The 2-failure negative test is the boundary that is most often skipped.
- Session timeout — 15 minutes inactivity: Leave a session idle for 15 minutes and verify the screen locks and re-authentication is required before any action can be taken. Verify that a GMP action attempted immediately before the timeout (but after 14 minutes) cannot be completed by the next user who re-authenticates on the same workstation without their own credentials.
Unique Accounts and Concurrent Login Prevention
The requirement for unique individual accounts is non-negotiable for any GMP function. FUNC-SEC-003 states this explicitly: shared accounts, group accounts, and generic accounts are not permitted for any GMP-active function. When a user leaves the organisation, their account must be disabled — not deleted. Deletion breaks audit trail attribution for historical records. An audit trail entry that references a deleted user ID cannot be attributed, and an inspector who finds deleted accounts in the system will treat every action by those accounts as unattributable.
Concurrent login prevention is a separate but related control. The SCADA must detect when the same account is active on two workstations simultaneously and either block the new login or force the existing session out. Both responses are compliant — the FDS must specify which behaviour is configured. The audit trail must record the event either way. The OQ test is straightforward: log in with a named account on workstation WS-01, then attempt to log in with the same account on WS-02. The system must respond per the configured behaviour and generate an audit trail entry.
Active Directory Integration — What It Changes
Most enterprise pharma SCADA deployments integrate with Windows Active Directory for authentication rather than maintaining a separate SCADA user database. AD integration means the operator's domain credentials (the same username and password they use to log into Windows) authenticate them to the SCADA. Role assignment is managed by AD group membership — the SCADA maps AD groups to SCADA roles. In Ignition this is the Identity Provider configuration. In WinCC it is the Windows User Groups mapping. In FactoryTalk it is the FactoryTalk Directory with Windows AD authentication. In Wonderware InTouch it is the LDAP connection from the InTouch Security Server to the site domain controller.
AD integration has important implications for the validation documentation. The password policy is enforced at the AD level, not the SCADA level. The IQ must verify that the AD Group Policy Object (GPO) applied to SCADA user accounts enforces the parameters specified in the FDS. This is a configuration review item, not a functional test — the IQ tester reviews the GPO settings and records the actual values against the FDS specification. If AD is unavailable, the fallback to local SCADA accounts must be configured and tested — the OQ must verify that local accounts use the same password policy parameters as the AD-enforced policy.
The OQ RBAC Regression — What a Full Test Looks Like
The OQ RBAC regression is not a spot check. It is a systematic test of every role's permitted actions (positive tests) and every role's denied actions at the boundary above it (negative tests). At OQ the tests must use real AD accounts with the production role assignments — not test accounts created specifically for the OQ with elevated permissions. If the OQ is run with a single "Admin" test account that can do everything, nothing is proven about the role boundaries.
The minimum test sequence for a full four-role regression, in order:
- Read-Only role — four negative tests: attempt alarm acknowledgement, setpoint modification, manual sequence initiation, and User Account Management access. All four must be blocked with explicit messages. All four blocked attempts must appear in the audit trail with the Read-Only user's ID.
- Operator role — positive and negative: acknowledge a High alarm (positive — must succeed and be audit-trailed). Then attempt to modify the distribution pressure setpoint (negative — must be blocked). Audit trail must show the blocked attempt with the Operator user's ID.
- Supervisor role — positive and negative: modify a process setpoint with a reason (positive — old value, new value, user, timestamp, and reason must all appear in audit trail). Then attempt to access User Account Management (negative — must be blocked).
- Administrator role — positive: create a new test user account with Operator role. Audit trail must record account creation with Administrator user ID. Delete the test account after verification — account deletion must also be audit-trailed.
Two additional test cases that belong in the OQ but are frequently omitted: the disabled account test (disable an active account in the security server or AD; attempt to log in with that account — must be rejected, and the rejection must be audit-trailed), and the role change test (change a user's role assignment from Operator to Supervisor; verify the change is audit-trailed; log in as that user and verify the new permissions apply).
The FDS-SYS-001 Appendix D contains the full 4-role × 16-function permission matrix as described in this article — every cell explicitly permitted or denied, consistent with URS-SYS-001 Appendix B. FUNC-SEC-001 through FUNC-SEC-004 define the RBAC design, password policy parameters (10-char minimum, complexity, 12-history, 3-failure lockout, 15-minute session timeout), unique account enforcement, and the e-signature design. The SDS-SYS-001 Section 7 documents the AD integration (LDAP port 389/636, fallback local accounts, AD group mapping to SCADA roles, concurrent login detection), the password policy enforcement configuration, and the unique account requirement with the account naming convention. OQ-SYS-001 contains test cases OQ-010 (full 4-role regression — 6 steps covering all role boundaries with positive and negative tests), OQ-011 (concurrent login prevention — both workstation test), and OQ-012 (password policy boundary tests — 9-character rejection, 10-character acceptance, 2-failure no lockout, 3rd failure lockout) — the exact test sequence described in this article, with expected results defined and evidence attachment fields.