What breaks when internet-facing PLCs still use default credentials?

Why Default PLC Credentials Break More Than Login

Default credentials on an internet-facing PLC do not just weaken authentication, they remove the first control that stands between remote access and the control logic that drives equipment, conveyors, pumps, valves, or safety interlocks. Once that login barrier is gone, the device can be treated as an exposed control endpoint rather than a protected asset, which is why the consequence is usually availability loss or process disruption.

In OT, the blast radius is often physical as well as digital. A successful login can enable parameter changes, command injection through legitimate interfaces, or communication disruption that looks like a reliability fault until the root cause is investigated. That is why default credentials on PLCs should be read as an exposure to operations, not just an authentication flaw.

When the PLC is reachable from outside the plant, the problem is amplified by weak segmentation and by the assumption that the device will not be actively targeted. Internet exposure turns a local maintenance shortcut into a remotely reachable control plane, and that changes both the likelihood of abuse and the speed at which an attacker can move from access to impact. OT and ICS Identity and Access Guide is the most direct starting point for that trust-boundary problem, while OWASP Non-Human Identity Top 10 gives a useful control lens for default secrets and overprivilege in machine-access scenarios.

What an Attacker Can Change After They Get In

The main failure modes are simple and damaging: they can alter setpoints, disable alarms, interrupt communications to supervisory systems, or change how the PLC interacts with attached equipment. Even when the attacker does not fully shut the process down, subtle changes can create unsafe behavior, degraded output quality, or intermittent faults that are harder to diagnose than a clean outage.

Default credentials also make the device a foothold for broader OT abuse. If the PLC shares trust with engineering workstations, remote maintenance paths, or flat network segments, the attacker may use that access to enumerate nearby systems, pivot into other controllers, or persist through configuration changes that survive routine operations. That makes the weakness attractive because it converts a single password problem into a durable access path.

Because PLC activity often blends with ordinary plant traffic, abuse may be detected late. A controller that still responds normally at the protocol level can still be functionally compromised if the logic, timings, or communication relationships have been changed beneath the surface. The issue is therefore not just whether the attacker can log in, but whether the organisation can tell that the logged-in device is no longer trustworthy.

What to Fix First on Exposed Controllers

Internet-facing PLCs should be treated as an exception condition, not a standard deployment. The first remediation priority is to remove direct exposure, then replace shared or default credentials with unique credentials, and then verify that any remote access path is segmented, logged, and limited to the minimum required function. OWASP Cheat Sheet Series is useful here for implementation discipline around authentication and secret handling, while CISA Secure by Design reinforces the expectation that default-secure settings should not depend on operators remembering to harden them later.

If the PLC cannot be taken offline immediately, treat the exposed interface as high-risk and reduce the blast radius around it. That means constraining who can reach it, confirming whether it supports separate roles or maintenance modes, and checking whether changing credentials actually invalidates old sessions or cached access paths. Default-password remediation is incomplete if old access still works through another management channel.

For organisations that manage many controllers, the practical question is not only “have we changed the password?” but “have we proved the controller is no longer reachable in the clear, no longer using shared access, and no longer trusted for unrestricted command execution?” In this setting, the hardest part is usually inventory and ownership, not the password reset itself. Guide to the Secret Sprawl Challenge is relevant because hardcoded or default credentials are often part of a wider secrets-sprawl problem, and API Key Management Guide usefully mirrors the lifecycle discipline needed for any credential that can directly authorize access.

Practitioner Guidance

What to verify: Confirm whether the PLC is reachable from the internet, whether the login is still a default or vendor-supplied credential, and whether any dependent HMI, SCADA, or remote maintenance workflow still assumes that account exists.

Decision rule: If the controller can alter a physical process, priority should be removal of exposure and credential replacement before deeper forensic work, because continued reachability keeps the risk active even if no abuse has yet been observed.

What practitioners underestimate: The most important consequence is often availability erosion, not obvious sabotage. A small change to control logic or communications can look like an equipment fault, which delays detection and increases operational impact.

Practitioner takeaway: Treat default PLC credentials on the internet as direct process risk, not a housekeeping issue, because the real failure is the loss of trustworthy control over a live physical system.

Related resources from NHI Mgmt Group

• What breaks when a platform still relies on default credentials?
• What breaks when weak credentials and exposed admin consoles are left in place on internet-facing WebLogic servers?
• What breaks when RDP access is still governed mainly through an internet-facing gateway?
• What are the risks of using static credentials in MCP servers?