The short answer
Shared Account Problems
A shared account is one whose password is known to more than one person, and in most utilities that describes the operator console login, the integrator account, the SCADA administrator account, and the password on every controller, switch, and HMI. The problems are that no action can be attributed to a person, that an employee or contractor who leaves takes the password with them and it is never changed because changing it would break something, that misuse cannot be distinguished from use, and that every audit and every incident investigation ends at the shared account. The fix is individual accounts wherever the platform supports them, starting with the SCADA and the operating systems, with the console designed so that individual login is fast; and for the devices that support only one password, containment: unique passwords per device stored in a vault, rotation on every staff or contractor change, network restrictions on who can reach the device, and logging of who was given the password when.
Key points
- A shared account gives every action the same name, which is no name.
- The password that everyone knows is the password that never changes, because changing it breaks things.
- Departed employees and finished contractors keep every shared password they were ever given.
- Individual accounts on the SCADA and the operating systems come first; they cover most actions and most audits.
- Devices with one password are contained: unique per device, vaulted, rotated on change, reachable only from the engineering zone.
- The migration succeeds when individual login is faster than the shared one was.
Where shared accounts hide
| Account | Why it is shared | What goes wrong |
|---|---|---|
| Operator console login | Logging in at shift change was inconvenient; the display had to stay up | Every control action for a decade is attributed to OPERATOR |
| SCADA administrator | Set up at installation, used by everyone who administers | Configuration changes with no author; the password is in the integrator project files |
| Integrator or vendor account | One account for the firm, used by whichever engineer visits | Engineers who left the firm still know it; it is enabled permanently |
| Controller, HMI, switch, and radio passwords | The device has one password | The same password on every device; known to every contractor who ever touched one |
| Service accounts used interactively | Convenient for troubleshooting | A high-privilege account with a password that cannot be rotated without touching every service |
| Remote access account | One VPN login for the on-call rotation | Nobody knows who connected at 2 a.m. |
What it costs
- Accountability: the audit trail, the alarm acknowledgment record, and the incident timeline all say the same name. The question who did this cannot be answered.
- Offboarding: the checklist for a departing employee cannot include changing a password that fifteen people use and that is embedded in scripts and vendor documents, so it is not changed. Former staff and finished contractors retain access indefinitely.
- Detection: a login by an attacker with the shared password looks like a login by staff. There is no anomaly to detect.
- Compliance: every assessment, insurer questionnaire, and regulatory review asks about unique accounts, and the answer is no.
- Password quality: a password that many people must remember and type is short and simple, and it is written down near the console.
Individual accounts first
The SCADA platform, the operating systems, the directory, and the remote access system all support individual accounts with roles, and they cover the actions that matter most: control, configuration, administration, and remote connection. Moving those to individual accounts is a project of a few weeks: define the roles, create the accounts, configure the console for view-only auto-login with a fast operator login, disable the shared accounts, and rotate the passwords on any that must remain for service use. Operators accept it when the login is a badge tap or a four-digit PIN and the displays never go away; they resist it when it is a twelve-character password typed on a screen that went blank.
Containing the unavoidable
A controller with one password, a managed switch with a local admin account, a radio with a web login: these will be shared among the people who maintain them, because the device offers nothing else. The containment is to make sharing narrow and visible.
- 1
Unique per device
No two devices with the same password; a compromised password then opens one device, not the plant.
- 2
Vaulted
The passwords in a credential vault with individual access, so that who retrieved which password when is logged; that log is the accountability the device cannot provide.
- 3
Rotated on change
Every time a person who had access leaves, or a contractor engagement ends, the passwords they were given are changed. The vault log says which ones.
- 4
Reachable only from the engineering zone
Firewall rules and switch configuration so that the device management interface is reachable only from the engineering workstations, where individual logins already apply.
- 5
Logged where possible
Devices that support a syslog or an audit log send it to the collector; devices that support a central authentication server use it instead of local passwords.
Frequently asked questions
- Our operators share one login and it has worked for twenty years. What is the actual risk?
- That nobody can say who did anything, that every former operator and every contractor still knows the password, and that an intruder who learns it is indistinguishable from staff. The risk has always been there; the difference now is that attackers are looking for water utilities, and a shared login is the first thing they try.
- The PLC has one password. How is that not a shared account?
- It is one, and it cannot be avoided on that device. The containment makes it narrow: unique to that controller, in the vault, rotated when people leave, and the controller reachable only from engineering workstations where the person logged in with their own account. The individual accountability is at the workstation and the vault, not the controller.
- How do we rotate a password that is embedded in scripts and configurations?
- Find every place it is used, which the inventory and a search of the project files reveal, move each use to a service account with the credential in the platform credential store rather than in the script, and then rotate. It is tedious once and routine afterward. A password that cannot be rotated is a permanent vulnerability with a known value.
- Is a badge login on the console secure enough?
- For unlocking operator control on a console that is physically inside the control room, a badge or a short PIN is proportionate: the control is physical access to the room plus the credential, and the goal is attribution and fast switching. Administrative and remote access keep strong passwords and multi-factor authentication.
Related topics
- User Accounts and RolesWho can do what on the SCADA and how it is enforced: roles from view-only to administrator and their permission matrix, individual accounts including the operator console, service and vendor accounts, same-day offboarding, and the quarterly review.
- 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.
- Credential StorageWhere the passwords and keys of a control system are kept: a vault with individual access and a log, break-glass copies in a safe, platform credential stores for service accounts, and the places they must not be, from spreadsheets to project files.
- 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.
- 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.
- Controller HardeningWhat can be locked down on a PLC or RTU: keyswitch and mode, credentials, unused services, access lists, firmware, and the engineering workstation that is the real target.
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.