The short answer
User Accounts and Roles
A SCADA system enforces least privilege through roles: view-only, operator, supervisor, engineer, and administrator, each with a written set of permissions for what it can see, acknowledge, command, change, and configure, plus service accounts for the application processes and vendor accounts that are disabled until a session is arranged. Every person has an individual account so that the audit trail names them, the operator console reaches a view-only state without a login and requires an operator login for control, accounts live in a directory dedicated to the control system or in local accounts on a small system rather than the corporate domain, access is removed the day a person leaves, the account list is reviewed each quarter, and logins and privileged actions are logged to a collector.
Key points
- Roles are a written permission matrix; the platform implements the matrix, not the other way round.
- Individual accounts for every person, including operators; the console auto-logs into view-only, not into control.
- Service accounts run the application with minimum rights and no interactive login; vendor accounts are disabled between sessions.
- The control system has its own directory or local accounts; the corporate domain is not extended onto it.
- Offboarding is same-day, and it includes every device the person knew a password for.
- Quarterly review of every account against the staff list; logins and privileged actions logged off the box.
The roles
| Role | Can | Cannot | Who |
|---|---|---|---|
| View-only | See displays, trends, alarm lists | Acknowledge, command, change anything | Managers, office staff, the auto-login state of a console |
| Operator | Acknowledge alarms, start and stop equipment, change setpoints within operator limits, shelve low and medium alarms | Change limits, bypass permissives, edit configuration | Certified operators on shift |
| Supervisor | Everything an operator can, plus setpoints beyond operator limits, alarm shelving at higher priority, permissive bypasses, out-of-service entries | Edit displays, tags, or logic | Shift supervisors, chief operators |
| Engineer | Configure tags, displays, alarms, historian, and communications; download to controllers | Administer the operating system or user accounts | Control engineers, the integrator under a change record |
| Administrator | Operating system, user accounts, backups, patching, security configuration | Used for daily operation | Named system administrators, used only for administration |
| Service | What the application process needs: read tags, write history, run reports | Interactive login | The SCADA services, the historian collector, the database connection |
| Vendor | The role the session needs, usually engineer | Anything when no session is arranged; the account is disabled | Integrators and vendors, enabled per session and disabled after |
The matrix is written first, as a table of roles against actions, and agreed by operations, engineering, and management. The platform then implements it with its own role and security mechanisms, which differ by product but can express this matrix on every serious platform. A matrix that exists only in the platform configuration cannot be reviewed by anyone who does not administer the platform.
Individual accounts and the console
Accountability requires that every action is attributed to a person, which requires that every person has an account. Operator consoles are the place where this usually fails: a shared operator account logged in for years because logging in and out at shift change was inconvenient. The workable design is a console that starts automatically into a view-only state, with all displays visible and nothing commandable, and an operator login, by badge, PIN, or a short password, that unlocks control for that person and times back out to view-only after inactivity. The displays are never lost, control is never anonymous, and shift change takes seconds.
Where accounts live
A large system uses a directory dedicated to the control system, with its own domain controllers on the control network or in the DMZ, so that the corporate directory and its compromise cannot reach the SCADA and the SCADA does not depend on the corporate network to authenticate. A small system uses local accounts on each machine, managed by a procedure, which is acceptable for a handful of machines and becomes unmanageable beyond that. What is not acceptable is joining SCADA servers to the corporate domain, which puts the control system inside every phishing campaign the office receives and makes the corporate helpdesk an administrator of the water plant.
Lifecycle
- 1
Onboarding
A request naming the person, the role, and the systems, approved by the responsible manager. The account is created in the role, no more, and the person signs the acceptable use policy.
- 2
Role change
A request, an approval, and a change; a person promoted to supervisor gets the supervisor role and loses nothing they should not have had.
- 3
Offboarding
The same day: the SCADA account disabled, the directory account disabled, remote access revoked, and every shared device password the person knew rotated. A checklist, run by someone who is told about departures.
- 4
Vendor sessions
The vendor account enabled for the session, with the scope and the time recorded, and disabled when the session ends. Never left enabled for convenience.
- 5
Quarterly review
The account list against the staff list and the vendor list, with the manager confirming each one. Accounts not confirmed are disabled.
Logging
- Every login and logout, successful and failed, with the account and the station.
- Every control action, setpoint change, alarm acknowledgment and shelve, with the account.
- Every configuration change and controller download, with the account.
- Every account creation, role change, and disable, with the administrator who did it.
- All of it forwarded to a collector off the server, retained per the security policy, and reviewed on a schedule for failed logins, logins at odd hours, and privileged actions.
Frequently asked questions
- Operators say individual logins slow them down. What works?
- A badge reader or a short PIN at the console, a view-only state that is always there so nothing is hidden while logging in, and a timeout that returns to view-only rather than locking the screen. Most operators accept individual logins once the login takes two seconds and the displays never disappear.
- Should the integrator have a permanent engineer account?
- A named account for each integrator engineer, disabled between engagements and enabled for a defined session under a change record. A permanent, always-enabled integrator account is a shared account with a long list of people who once knew the password.
- Can the corporate IT department manage SCADA accounts?
- They can run the dedicated control system directory if the utility decides that, with the control system owner approving every account and role. What they should not do is extend the corporate domain onto the control network or apply corporate policies, such as lockouts and forced password changes, to operator consoles without the control system owner agreeing.
- How many administrators should there be?
- As few as can cover vacations and emergencies, usually two or three, each with a named administrative account used only for administration and a separate daily account. An administrator account that is used to browse displays is an administrator session waiting to be hijacked.
Related topics
- Shared Account ProblemsWhy the shared operator login, the vendor account everyone knows, and the single PLC password are the weakest point in most utilities: no accountability, no offboarding, no detection. Containing what cannot be avoided and migrating the rest.
- Password Policy for OTA password policy that fits a control system rather than an office: length over complexity, rotation on events, screening against breached lists, multi-factor authentication, no lockouts that take control from an operator, and unique vaulted device passwords.
- SCADA ClientsThe workstations, browsers, and mobile devices operators use to see and control the system: thick, thin, web, and mobile clients, roles and permissions, where control is allowed from, workstation design, session policy, licensing, and failover behavior.
- Vendor Remote AccessIntegrators and equipment vendors need to get in. How to let them without leaving a permanent door open: utility-controlled sessions, named accounts, MFA, a jump host, session recording, and what to do about the modem you did not know was there.
- Server HardeningReducing what an attacker can do with a SCADA server: a baseline from the vendor guide and a benchmark, unused services removed, the host firewall on, application allowlisting, controlled media, separate administrator accounts, and logs sent off the box.
- Default CredentialsThe passwords printed in the manual: where they hide in a control system, why they are the first thing an attacker tries, how to find every one on site, and the procedure for changing them without locking yourself out.
Direct contact
Have a controls question?
Reach Eric Sullivan directly about anything on this site, a controls or automation topic, or one of his personal projects.