Default credentials in OT systems: a more widespread problem than you might think

How widespread the problem is

When the topic of default credentials in OT systems comes up, the common reaction is scepticism: "surely in our plants the passwords were changed at installation time." In many cases this belief is wrong.

The data emerging from penetration tests and OT security audits describes a different reality. Default credentials, or trivially simple passwords set at deploy time and never changed, are found frequently in industrial plants, even at companies that have invested in other aspects of cybersecurity.

The problem does not stem from gross negligence. It stems from the convergence of several structural factors that make changing credentials in OT systems far more complicated than it seems.

Why credentials stay at default

Understanding the causes helps identify real solutions instead of simply prescribing "change the passwords."

Changing the password breaks connected functionality: many OT systems have integrations between components that use hardcoded credentials or credentials stored in configuration files. Changing the password of the SCADA server administration account can break communication with the historian database, with the reporting system, with automatic notifications. Before changing the password you need to understand where it is used: an analysis that takes time and in-depth knowledge of the system.

Dependence on the vendor: for many OT systems, any change to the configuration, including changing access credentials, must be carried out by the vendor or under their supervision, so as not to void the warranty or the maintenance contract. The vendor has its own processes and timelines. The vendor's access account, with its standard service password, is often the same on every installation of the same product worldwide.

Absence of a hardening process at deploy time: OT systems are often installed by system integrators who focus on operational functionality, getting the production line running, and not on security. Commissioning checklists rarely include changing default credentials. And once the system is in production and everything works, stepping in to perform hardening requires a strong reason.

The "if it works, don't touch it" syndrome: an HMI with the password "admin" that has been running for six years without problems is perceived as less risky than a password change procedure that might cause unplanned downtime. The implicit risk assessment is distorted, but it is understandable in an operational context where production continuity is the absolute priority.

Proliferation of service accounts: SCADA systems and OT application software often have multiple service accounts: an account to run the Windows service, an account for the database connection, an account for communication with field devices. Each one has a password. Often they are the same default passwords set by the installer, forgotten, and never updated.

How an attacker finds the credentials

The availability of information on default credentials for OT systems is surprising to anyone who has never actively looked for it.

Public vendor documentation: the installation manuals and quick-start guides of a great many OT products are freely available on the vendor's website or on technical documentation sites. These manuals typically include the default credentials, the first-access procedures, and sometimes even the service account credentials. A targeted search makes it possible to find the default credentials of most widespread OT products in a matter of minutes.

Specialised search engines: Shodan and similar tools index devices exposed on the internet, including the remote-access panels of OT systems. Combining a specific product (identified through the response banner) with its default credentials from the vendor documentation is a documented attack vector that is actively used.

Bruteforce on protocols without lockout: many OT protocols and the management interfaces of field devices do not implement lockout mechanisms after multiple failed attempts. An attacker with access to the OT network can try dictionaries of common passwords, and the default credentials of all known products, without the risk of locking the account.

Sharing on underground forums: the default credentials of the most widespread OT products circulate on underground forums alongside exploit techniques specific to industrial protocols. It is not a closely guarded secret: it is information that is widely available in the ecosystem of threat actors interested in industrial environments.

What traffic monitoring reveals

Passive monitoring of OT traffic can detect both compromise attempts using default credentials and access that has actually taken place.

Multiple failed authentication attempts: a bruteforce, even a slow and distributed one designed to avoid detection, produces a recognisable pattern in the traffic. Repeated access attempts toward the same destination, especially if coming from unusual sources, are a signal to investigate.

Unauthorised management sessions: even if an attacker uses valid credentials (because they were the default ones), a management session opened at an unusual time, from an unexpected IP address, or with a command pattern different from the baseline is detectable. The legitimate traffic of an operator has different characteristics from the traffic of an attacker exploring the system.

Access outside maintenance windows: in well-managed OT networks, configuration and management sessions take place within defined time windows. An administration access during normal production hours, when no intervention is planned, is an anomaly that deserves attention.

Traffic toward management addresses from unauthorised zones: a field device or a PLC reached by a system that does not normally communicate with it (an IT server, a laptop connected at an unusual point) is an indicator of possible anomalous use of credentials.

Practical hardening without stopping production

Changing default credentials in an active OT environment requires a methodical approach, not a massive, improvised intervention.

First phase: account inventory

The starting point is understanding how many accounts exist, on which systems, and what the dependencies are. This requires examining SCADA systems, OPC servers, historian databases, HMIs, network switches, and every component that has an authentication interface. For the most critical systems, the analysis must be coordinated with the vendors so as not to make incorrect assumptions about dependencies.

Second phase: prioritisation by risk

Not all accounts have the same risk profile. The most critical accounts to address first are those on systems with active remote-access interfaces or interfaces reachable from networks that are not fully trusted. An account with a default password on a system that is completely isolated from the network has a very different risk profile from the same account on a system reachable from the IT network or from the internet.

Third phase: planned, per-system intervention

For each system, the credential change should be carried out in a planned maintenance window, with:

• A backup of the current configuration
• A map of the dependencies (which other systems use these credentials)
• A rollback plan in case of problems
• Functionality testing after the change

The new passwords must follow a defined policy (minimum length, complexity, uniqueness per system) and must be managed with a password management tool, not in shared Excel spreadsheets.

Fourth phase: post-hardening monitoring

After changing the credentials, traffic monitoring makes it possible to verify that there are no systems still using the old credentials (repeated authentication failures from internal hosts are a sign that some integration was forgotten) and that there are no access attempts using the old default passwords (which would indicate someone who already has the previous credentials in hand).

The vendor account: the special case

A case that deserves separate attention is the vendor's access account. Almost all OT products have a support or service account, often with elevated privileges, that the vendor uses for remote maintenance and troubleshooting.

These accounts have problematic characteristics: they tend to have standard credentials that are identical across all installations of the product, to be shared among all the vendor's technicians, and to remain active even when no work is underway.

Proper management of vendor accounts in OT involves:

• Different credentials for each installation, generated and communicated to the vendor only for the duration of the intervention
• Disabling the vendor account at the end of each maintenance intervention
• Monitoring all sessions opened with the vendor account (when, from where, which operations)
• Periodic review of active vendor accounts and removal of those no longer needed

This management requires coordination with the vendor and may meet resistance ("but this makes our support work more complicated"). It is operationally understandable resistance, but unacceptable from a security standpoint: a shared vendor account with standard credentials is an open door that anyone with access to the product documentation can use.

The issue of default credentials in OT environments is one of those where the gap between the perception of risk and the actual risk is largest. The good news is that hardening, done methodically, is technically achievable without significant impact on production, and continuous traffic monitoring makes it possible to quickly detect both exploitation attempts and configurations that have not yet been corrected.

The MON5 angle

Detecting the use of default credentials without active scans is exactly the kind of problem that calls for a passive approach. The monitoring of MON5's PROTECT phase decodes native OT protocols and pinpoints anonymous authentication sessions, after-hours management access, and repeated attempts that indicate bruteforce, without ever querying the devices.

The account inventory, however, starts with the system inventory: the DISCOVER phase maps the devices and management interfaces present on the network, including those that no one had ever catalogued. To find out how many access interfaces really exist in your plant, book an OT assessment.

Analysis and commentary by MON5 based on public-domain research and data from the OT/ICS sector.