The short answer
Default Credentials
Default credentials are the factory usernames and passwords that ship on controllers, HMIs, switches, radios, drives, analyzers, and cameras, and they are published in every manual and collected in public lists. They are the most common way into a control system that is reachable at all. Removing them means inventorying every device with a login, changing each default with the new credential recorded in a managed store, verifying the change, and making the check part of commissioning so that new and replaced devices do not reintroduce them.
Key points
- Every device with a web page, a console, or a protocol login shipped with a default. Assume it is still there.
- Public lists index default credentials by vendor and model. An attacker does not need to guess.
- Change them one device at a time, record the new credential in the store first, and verify before leaving.
- Network switches, radios, and embedded web servers are the ones inventories miss.
- Add the check to the commissioning checklist so a replaced device does not arrive with its defaults.
Why they matter
An attacker who reaches a device login page has two choices: try to exploit a vulnerability, or type the default. The default works often enough that it is tried first. Public databases list default credentials by vendor and model, scanning tools test for them automatically, and the exposure surveys of internet-reachable control devices find the same defaults year after year. A device on a control network with its default password is not protected by that password; it is protected only by whatever keeps the attacker off the network, and that is one layer where two were intended.
Where they hide
| Device | Typical default login | Note |
|---|---|---|
| Managed Ethernet switches | Web and console management with a well-known admin account | Often installed by the electrical contractor and never touched; the management interface is on the control VLAN |
| Serial and cellular radios | Web configuration page | Vendor-installed; the same password across the whole fleet |
| PLC and RTU web servers | Diagnostic and configuration pages enabled by default | Disable the server if unused; change the password if used |
| HMI panels | Runtime login levels with default passwords, and a maintenance or engineering level | The engineering level often has a documented default that lets a user exit the runtime to the operating system |
| Drives and soft starters | Keypad parameter lock codes and network web pages | Rarely changed; a lock code of zero is the default on many |
| Analyzers and smart instruments | Configuration menus and web interfaces | Also HART and other protocols with write protection off |
| SCADA software | Built-in administrator accounts and default project users | The installation guide lists them |
| Windows and Linux servers | Local administrator, service accounts created by installers | Vendor installers create accounts with documented passwords |
| Cameras, UPS cards, environmental monitors, power meters | Web management | Every one has a network card and a login; most inventories miss them |
| SNMP community strings | Public and private on nearly every network device | A read-write community string is a password to the device configuration |
Finding every one
- 1
Start from the asset inventory
Every device with a network address, and every device with a keypad or console login even without one. If the inventory does not exist, this is the reason to build it.
- 2
Add the devices inventories miss
Walk the panels. Switches, radios, cellular modems, UPS network cards, camera systems, power meters, and anything with an RJ-45 port.
- 3
Identify the login surfaces on each
Web page, console, SSH or Telnet, SNMP, vendor protocol, keypad lock. A single device may have four.
- 4
Check each against the default
Log in with the documented default. If it works, the device is on the list.
- 5
Rank the list
Devices reachable from outside the control zone first, then network infrastructure, then controllers and servers, then the rest.
Changing them
Changing a password on a device that runs a process is a change, and the risk of locking yourself out is real. The procedure is deliberate.
- 01Decide the new credential according to the password policy: unique per device, long, recorded in the credential store before it is set on the device.
- 02Confirm the recovery method for that device: a physical reset, a console port, a master password, a vendor procedure. Know it before changing anything.
- 03Change the credential, then log out and log back in with the new one. Do not trust the change until the new login has worked.
- 04Where the device supports named users, create them and disable the default account rather than only changing its password. A disabled account cannot be guessed.
- 05Change the SNMP community strings, or disable SNMP, on every network device. Treat a read-write community string as an administrator password.
- 06Record the change: device, date, person, the store entry, and the recovery method. Not the password itself, anywhere but the store.
- 07Update the anything that used the old credential: a SCADA driver that logs into a device, a monitoring tool that polls it, a backup script.
Keeping them changed
- Add a default credential check to the commissioning checklist for every new and replaced device. A replaced switch arrives with its defaults.
- Include the check in the periodic vulnerability review: scan for known defaults with a tool, on a schedule, from inside the control network.
- Write the requirement into integrator and vendor contracts: no device is handed over with a default credential, and the credentials are delivered to the utility store.
- When a person who knew credentials leaves, rotate what they knew. Named accounts make this a short list; shared credentials make it everything.
Frequently asked questions
- The device only has one account and no way to disable it. What then?
- Change its password, restrict which addresses can reach the device with a firewall or an access list, disable the interface if it is not needed, and record the limitation. Many older devices are in this category, and network restriction is the compensating control.
- What if changing the password could break the SCADA connection?
- It might, if the SCADA driver or a monitoring tool logs into the device with that credential. Find those dependencies first from the driver configuration, schedule the change with operations, and update the dependent configuration in the same window with a rollback ready.
- Is a lock code on a drive keypad worth setting?
- Yes, where the drive is in a location people other than trained staff can reach, and always on the network web interface. A keypad lock prevents a casual or mistaken parameter change; the network credential prevents a remote one.
- How do we handle vendor default accounts in SCADA software?
- Rename or disable the built-in administrator where the product allows, set a long unique password where it does not, and create named accounts for every person. Vendors document their built-in accounts; treat that documentation as a list of what an attacker knows.
Related topics
- 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.
- 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.
- Zones and ConduitsThe IEC 62443 way to segment a control system: grouping assets into zones with a shared security level, inventorying every conduit between them, and turning the drawing into firewall rules. With a worked water utility example.
- Water and Wastewater Utility Threat LandscapeWhat has actually happened at water utilities, what those incidents had in common, and the small number of controls that would have prevented most of them.
- IEC 62443The international standard series for industrial automation and control system security: how it is organized, what security levels and foundational requirements mean, and how a utility or integrator actually uses it.
- 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.
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.