When legacy OT devices cannot verify users or applications, the control point moves outside the device. Security then depends on the access path, not the controller, so weak authentication, shared logins and broad remote reach can all turn into physical process risk. The answer is to govern access before the asset is reachable.
What breaks in control architecture when legacy PLCs and HMIs cannot enforce identity controls?
Legacy PLCs and HMIs usually were not built to authenticate users, distinguish applications, or enforce per-actor policy. When that control is missing, the device itself cannot be the trust boundary. Access governance has to move to the surrounding path, which means remote access, jump hosts, engineering workstations, and network segmentation become the real control plane.
That shift matters because the security question changes from “who is logged into the controller?” to “who can reach the controller, through what path, and with what privileges?” In practice, OT and ICS Identity and Access Guide is most useful here because it frames PLC and HMI access as a path-control problem, not a device-native login problem.
Without device-native identity controls, shared operator accounts, vendor access, and broad remote connectivity become high-impact design choices rather than convenience features. That is why the broader lifecycle problem described in NHI Lifecycle Management Guide still matters in OT: if accounts, credentials, or access routes are not owned, reviewed, and retired cleanly, the plant inherits standing access that the controller itself cannot police.
The practical implication is that legacy OT environments often end up enforcing identity at the boundary instead of at the asset. That can work, but only if remote access is tightly brokered, segmentation is real rather than nominal, and application of least privilege is consistent across operators, maintenance staff, and third parties. When those guardrails are weak, the controller becomes reachable by people or tools that the device cannot distinguish.
For teams trying to map the broader identity problem across accounts, access paths, and stale credentials, Top 10 NHI Issues is a useful companion because it highlights how overbroad access, shared secrets, and weak ownership become governance failures before they become incidents.
Why this becomes an operational and physical risk, not just an IAM gap
When a PLC or HMI cannot enforce identity controls, compromise at the access layer can translate directly into process manipulation. A weak remote session, reused password, or overpermitted engineering path can let an attacker or insider change setpoints, disable alarms, or interrupt sequencing without ever needing to defeat the controller’s own logic. The risk is not only unauthorized access, but loss of confidence in the physical process that the device controls.
The same weakness also expands blast radius. If many assets rely on one access path, one remote vendor channel, or one engineering workstation, then a single compromise can reach multiple controllers. The absence of per-device identity enforcement means you are depending on surrounding controls to do the work of several layers at once.
OWASP Non-Human Identity Top 10 is relevant because the same failure pattern appears whenever credentials, shared access, or overprivilege become the real mechanism of control. In OT, the consequence is sharper: the exposed path may alter physical operations, not just data.
Failure mechanism: The controller cannot verify the actor, so enforcement shifts to the network path, remote access tooling, and credential hygiene. If those layers allow shared logins, excessive privilege, or long-lived access, compromise of one account can become operational control of the asset.
Impact: Unauthorized changes may reach safety-relevant or production-relevant functions, creating downtime, quality loss, or unsafe process states before the issue is detected.
What good governance looks like when the device cannot help you
The right response is to treat identity as an external control for the legacy device, not an internal feature of it. That means binding access to named users or strongly governed service paths, limiting which jump hosts can reach the controller, and making sure vendor connectivity is time-bound and observable. If the device cannot distinguish sessions, the surrounding architecture must do the distinguishing.
This is also where standards and control guidance become useful. CIS Controls v8 supports the operational discipline needed to inventory accounts, restrict administrative reach, and log access to critical systems, while NIST SP 800-53 Rev 5 Security and Privacy Controls reinforces the need for identification, authentication, access enforcement, and auditability around the systems that front the controller.
The most important architectural judgement is whether the access path is specific enough to be controlled and reviewed at the same level as the process asset itself. If it is not, then the organization has merely displaced the identity problem from the PLC or HMI to a less visible part of the stack. That usually improves convenience, not security.
ISO/IEC 27001:2022 Information Security Management is useful where teams need a governance model for access control, supplier access, and operational accountability, while the CSA Cloud Controls Matrix is most helpful when OT environments borrow cloud-style brokered access, logging, and identity controls for remote administration.
Risk and Threat Considerations
Legacy PLCs and HMIs that cannot enforce identity controls are attractive targets because the attacker does not need to defeat the controller directly. They only need a reachable path, a shared credential, or a trusted maintenance channel. Once inside that path, the attacker can often blend into legitimate operator or vendor activity, which makes detection slower and containment harder.
Failure mechanism: The environment relies on upstream trust assumptions that are easier to abuse than device-native enforcement. A compromised remote access account, stolen session, or broadly permitted engineering connection can be used to reach multiple assets and alter process behavior before the weakness is visible.
Impact: The likely consequences include unauthorized process changes, degraded safety margins, production disruption, and wider lateral movement through connected OT segments.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-9 — Identification and Authentication (Non-Organizational Users) | Legacy PLC/HMI access often depends on third-party and remote users. |
| AC-6 — Least Privilege | Overbroad remote access is a core failure mode when devices lack native identity controls. | |
| AU-2 — Audit Events | Path-based control depends on logging who reached the controller and when. | |
| Recommendation — Enforce strong authentication for external and service access paths to OT assets. Limit OT access paths to the minimum privileges needed for each role. Log remote sessions and administrative actions that reach critical OT devices. | ||
| CIS Controls v8 | CIS-6 — Access Control Management | The subject is governed by controlling access before legacy devices are reached. |
| CIS-8 — Audit Log Management | Path-centric OT security needs evidence of who accessed the asset and through which route. | |
| Recommendation — Restrict, review, and remove access paths to PLCs and HMIs. Centralize and review logs for OT remote access and administrative sessions. | ||
Practitioner Guidance
What to verify: Confirm which access paths can actually reach each PLC or HMI, who owns them, and whether any shared account or vendor path can touch more than one critical asset. If you cannot map that clearly, you do not yet have control of the access boundary.
Decision rule: If the controller cannot enforce identity, require compensating controls at the access layer: brokered remote access, short-lived authorization, strong session logging, and segmentation that prevents casual lateral movement. If those cannot be enforced, treat the asset as exposed until they can.
Practitioner takeaway: Legacy OT identity gaps are not solved by hoping the controller will compensate, they are solved by making the surrounding path precise enough that every meaningful action is attributable, bounded, and reviewable.
Related resources from NHI Mgmt Group
- What breaks when legacy identity governance cannot enforce least privilege effectively?
- What breaks when legacy service accounts are left outside modern identity controls?
- What breaks when identity governance cannot reach legacy and core systems?
- What breaks when DSPM only finds sensitive data but cannot enforce controls?