The short answer
Multi-Factor Authentication
Multi-factor authentication requires something the user has or is in addition to something they know, so that a stolen or guessed password alone does not open the door, and it is the single control that has stopped the most intrusions into utilities, because the most common entry is a valid password used by someone who is not its owner. It is mandatory on every remote access path, on every administrative account, on the vault, on email and cloud services the utility uses, and on vendor and contractor accounts above all; it is not applied at the operator console inside the control room, where the room is the second factor and availability of control comes first. Hardware security keys and authenticator apps are the factors to use; codes by text message are better than nothing and weaker than either. Enrollment, lost-factor recovery, and break-glass access are designed in advance so that the second factor never becomes the reason nobody can get in.
Key points
- Passwords leak; a second factor makes the leaked password useless on its own.
- Mandatory on remote access, administration, the vault, cloud services, and every vendor and contractor account.
- Not at the operator console in the control room; the room is the factor, and control must stay available.
- Hardware keys first, authenticator apps second, text messages last.
- Enrollment and recovery are procedures: a lost phone must not lock the utility out or let an attacker in.
- Vendor accounts are the ones attackers target; they get the strongest factor and are enabled per session.
Why
Utility intrusions have followed a pattern: a password for a remote access account, obtained by phishing, by a breach elsewhere where it was reused, by a former contractor, or by guessing a default, used from anywhere in the world to log in as if the attacker were the engineer. Every control that depends on the password alone failed at that moment. A second factor, a code from a device in the engineer pocket or a key on their keyring, means the password is not enough, and the attacker with the password is stopped at the login. It is not a sophisticated control and it is not expensive; it is the one whose absence is found in most incident reports.
Factors
| Factor | How it works | Strength | Use |
|---|---|---|---|
| Hardware security key | A physical device that signs a challenge when touched; bound to the site it was registered with | Strongest; resists phishing because it will not answer a fake site | Administrators, engineers, vendors with frequent access |
| Authenticator app | A phone app that generates a time-based code, or receives a push to approve | Strong; push approvals can be fatigued by repeated prompts, so number matching is enabled | Staff and vendors generally |
| Certificate on a managed device | The device itself carries a certificate that the VPN checks | Strong as a device factor; combined with a user factor | Managed laptops for remote access |
| Text message code | A code sent to a phone number | Weakest; numbers are ported and messages intercepted | Only where nothing else is possible, and temporarily |
| Badge or PIN at the console | Physical token or short code at the operator station | Proportionate with the control room as the second factor | Operator control unlock, not remote access |
Where it is required
- Every remote access path: the VPN, the remote access service, the jump host login, and the SCADA login reached through them.
- Every administrative account: operating system, directory, SCADA administration, firewall and switch management, hypervisor.
- The credential vault.
- Email and any cloud service the utility uses, because those are where the passwords are phished.
- Vendor and contractor accounts, with the utility issuing or requiring the factor.
- The historian replica and any web interface reachable from the office, where the platform supports it.
Where it does not fit
The operator console in the control room is the exception. An operator responding to an alarm at 3 a.m. must be able to command the process in seconds, and a second factor that requires a phone, a key, or a code is a delay and a failure point at exactly the wrong moment. The control room itself, with its locked door and its badge access, is the second factor for the console, and the console login is a fast individual credential that attributes actions to a person. Any operator function reached from outside the control room is remote access and gets multi-factor authentication like any other.
Enrollment and recovery
- 1
Enroll in person
The factor is registered by the administrator with the person present, or through a verified process; a factor enrolled by email link is a factor an attacker can enroll.
- 2
Two factors per person
A primary and a backup, such as a key and an app, so that a lost phone is not a lockout.
- 3
Recovery by procedure
A lost factor is replaced by the administrator after identity is verified in person or by a method the policy defines, and the old factor is revoked. Recovery codes, if used, are in the vault or a sealed envelope, not in email.
- 4
Break-glass
An emergency administrative account with its credentials in the safe, exempt from multi-factor or with its factor in the safe, used only when the multi-factor system itself has failed, and rotated after every use.
- 5
Offboarding
The factor is revoked with the account the day the person leaves; a factor on a departed phone is a live credential.
Vendors
Vendor and integrator accounts are the ones attackers look for, because they exist at many utilities with the same people and often the same passwords. Every vendor account has multi-factor authentication, with the factor issued by the utility or verified by the utility, the account enabled only for scheduled sessions, and the session logged. A vendor who cannot support a second factor for their staff cannot be given remote access; the alternative is a site visit under escort.
Frequently asked questions
- Our SCADA login does not support a second factor. What do we do?
- Put the factor in front of it: the VPN and the jump host require it, so that nobody reaches the SCADA login remotely without having passed it. Inside the control room the console is exempt by design. Ask the vendor for multi-factor support in the next version; most platforms now integrate with the directory for it.
- Is an authenticator app on a personal phone acceptable?
- For most staff, yes, with the person agreeing to it and the app enrolled in person; the app holds no utility data. Administrators and anyone with frequent privileged access are better served by a hardware key the utility issues, which does not depend on a personal device.
- What if the multi-factor service is down?
- The break-glass account in the safe gets an administrator in to fix it, and the manual operation procedures cover the plant meanwhile, since remote access is not how the plant is run. The multi-factor service is itself hardened, redundant where practical, and on the monitoring list.
- How long does it take to roll out?
- A few weeks for a small utility: choose the factor, enable it on the VPN and the directory, enroll each person, write the recovery procedure, and issue keys to the administrators. Vendors are enrolled as their next session comes up. It is the highest-value few weeks in the program.
Related topics
- VPN DesignHow a VPN fits remote access for a control system: it terminates in the DMZ and lands on a jump host, never the control network; site-to-site tunnels carry telemetry; user tunnels require multi-factor and individual accounts; the concentrator is patched fast.
- Jump HostsThe one machine every remote session must pass through: what a jump host is, how it is hardened, what it may reach, session recording, the tools it carries, and why a vendor laptop never gets past it.
- 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.
- 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.
- 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.
- Session LoggingRecording every remote session into the control system: who connected, from where, when, to what, and what they did, from the VPN log through jump host session recording to the SCADA audit trail and controller change log, stored off the systems and reviewed.
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.