The short answer
Password Policy for OT
Current guidance, including the federal digital identity guidelines, favors long passwords over complex ones, screening against lists of breached passwords, and changing passwords when there is a reason rather than on a schedule, and those principles apply to control systems with adjustments for availability. Operator consoles use a fast individual credential to unlock control with a view-only state that is always available and no lockout that could deny an operator the HMI; administrative accounts use long passphrases and multi-factor authentication; remote access requires multi-factor authentication without exception; service accounts use long random passwords stored in the platform credential store and rotated when the people who knew them leave; and devices with a single password get a unique, long, vaulted password per device, changed from the default at commissioning and rotated on every staff or contractor change.
Key points
- Length beats complexity: a long passphrase is stronger and easier to remember than eight characters of symbols.
- Rotate on events, not on a calendar: a departure, a finished contract, a suspected compromise.
- Screen new passwords against breached lists; the common ones are the first an attacker tries.
- Multi-factor authentication for remote access and administration, always.
- No lockout on operator consoles; alarm on failed attempts instead, and keep view-only always available.
- Every device password unique, long, vaulted, and never the default.
What changed in password guidance
For years policies demanded eight characters with uppercase, lowercase, digits, and symbols, changed every ninety days. The result was passwords like the current month with an exclamation mark, written on a note under the keyboard. The federal digital identity guidelines reversed that: length is what makes a password strong, forced periodic changes make passwords weaker by pushing people to predictable patterns, and the useful checks are a minimum length, screening against lists of passwords that have appeared in breaches, and a change when there is evidence of compromise. Control systems adopt those principles and add the availability constraint that an operator must never be locked away from the process.
Policy by account class
| Account class | Credential | Rotation | Multi-factor | Lockout |
|---|---|---|---|---|
| Operator console unlock | Badge, PIN, or short password; individual | On departure or compromise | The control room itself is the second factor; none required at the console | None; alarm on repeated failures; view-only always available |
| Supervisor and engineer | Passphrase of 14 characters or more; individual | On departure or compromise | Where the platform supports it; required for remote sessions | Short lockout with automatic release; view-only unaffected |
| Administrator | Passphrase of 16 characters or more; individual, used only for administration | On departure or compromise | Required | Lockout with alert |
| Remote access | Individual account | On departure or compromise | Required, no exceptions, including vendors | Lockout with alert |
| Service accounts | Long random password, 20 characters or more, in the platform credential store | When a person who knew it leaves; on compromise | Not applicable | Not applicable; no interactive login |
| Devices with one password | Unique per device, as long as the device allows, in the vault | On every departure or contractor change; on compromise | Not available; compensated by network restriction | Per the device |
| Break-glass | Sealed envelope in a safe, or a vault emergency access | After every use | Physical access is the factor | None |
Rules that apply everywhere
- No default passwords on anything, from the day it is commissioned. The default list is public.
- No password reuse between systems; the SCADA administrator password is not the switch password.
- No passwords in scripts, configuration files, project files, drawings, or spreadsheets; the credential store or the vault holds them.
- No password hints, no security questions, no email of passwords.
- New passwords screened against a breached password list where the platform supports it, and against a short list of obvious ones where it does not.
- Passwords are told to people in person or through the vault, never in email or a text message, and never on the phone to someone who called in.
- Every credential given to a contractor is recorded, and rotated when the engagement ends.
Availability first at the console
An office policy that locks an account after five failed attempts protects a mailbox. Applied to an operator console it means a mistyped PIN during an overflow, or an attacker deliberately failing logins, takes control away from the operator when it is most needed. The console design keeps the displays and alarms visible without any login, requires an individual credential only to command, uses a credential that is hard to mistype, and raises an alarm to the supervisor on repeated failures instead of locking anyone out. Lockouts belong on administrative and remote accounts, where availability of the process does not depend on them.
Writing it down
The policy is a short document: the classes, the rules for each, the rotation triggers, where credentials are stored, who approves exceptions, and how the policy is enforced on each platform. It is approved by the utility, applied to the platforms through their settings, and reviewed when a platform changes or an incident shows a gap. A policy that is longer than a page is not read; one that does not exist is whatever the integrator set.
Frequently asked questions
- The insurer or the auditor requires ninety-day password changes. What do we do?
- Show them the current federal guidance, which recommends against forced periodic changes, and the policy that rotates on events and uses multi-factor authentication and breached-password screening. Most auditors accept a documented, current policy. If a requirement is contractual and immovable, apply it to administrative and remote accounts, and keep the operator console exempt for availability, with the reasoning recorded.
- How long should a device password be?
- As long as the device allows, which on some controllers is disappointingly short. Use the maximum, make it unique, vault it, and compensate for the device limits with network restrictions so that the password is not the only thing between the internet and the controller.
- Should operators have multi-factor authentication?
- At the console, the control room and its physical access are the second factor, and a fast individual credential is enough. For any operator function reached remotely, from home or a phone, multi-factor authentication is required like any other remote access.
- What about the password on the HMI panel at a lift station?
- A device password: unique to the site, vaulted, changed from the default at commissioning, and rotated when people change. The panel is also physically inside a locked enclosure at a fenced site, which is part of the control, and its management interface is not on the network for anyone to reach.
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.
- 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.
- Multi-Factor AuthenticationRequiring a second proof of identity beyond a password, where it matters most in a control system and how to do it without locking an operator out: the factor types, where it is mandatory, where it does not fit, enrollment and recovery, and vendor accounts.
- 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.
- Security Program BasicsWhat a control system security program is for a utility that has never had one: a named owner, an inventory, a risk assessment, a few policies, baseline controls, training, vendor rules, an exercised incident plan, and a first-year plan for a small staff.
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.