What breaks when manufacturers keep shared OT accounts after convergence?

Why This Matters for Security Teams

Shared OT accounts are not just a hygiene issue after IT and OT converge. They collapse the evidence chain that security, operations and engineering rely on during change control, safety review and incident response. When multiple people use one login, RBAC, PAM and even basic session logging lose precision because the identity no longer maps to a single human or support function. That makes it harder to prove whether a PLC setpoint changed through an approved maintenance window or through an unauthorised remote session.

The risk is amplified when shared access is extended to vendors, contractors and system integrators. In practice, a compromised shared credential can look like routine operator activity until the process is already disrupted. This is why current guidance from NIST Cybersecurity Framework 2.0 and NHI governance both emphasise traceable identity, least privilege and auditable access paths. NHI Mgmt Group has also documented how identity failures become visible only after damage, as seen in the Schneider Electric credentials breach. In practice, many security teams encounter shared-account failures only after a controller is altered and no one can reliably prove who did it.

How It Works in Practice

Once convergence brings remote support, cloud monitoring and vendor maintenance into OT, the old habit of shared access starts to break incident reconstruction. A single account may be used by shift staff, integrators and automation engineers, but each session can have a different purpose, device and risk level. That means the control problem is not only authentication, it is attribution. Modern guidance is shifting toward per-person or per-workload identity, short-lived access, and intent-based approval at the moment access is requested.

Practically, organisations should separate three layers:

• Identity: give each operator, contractor or service tool a distinct account or workload identity.
• Authorisation: use JIT access and PAM so privileged access is approved for a specific task, not left standing.
• Evidence: log session start, command execution, asset touched and ticket reference so review can reconstruct who acted and why.

For OT environments, this often requires pairing RBAC with contextual checks such as device posture, engineering change record and time-bound approval. That approach fits the direction of NIST Cybersecurity Framework 2.0, which prioritises governance, access control and continuous monitoring. It also aligns with the breach patterns highlighted in the Schneider Electric credentials breach, where credential misuse can quickly become an operational issue rather than a pure IT problem. In this context, shared OT accounts tend to break down when third-party support is frequent, because no session can be tied cleanly to one accountable operator.

Common Variations and Edge Cases

Tighter access control often increases operational overhead, requiring organisations to balance traceability against uptime, shift turnover and emergency response. That tradeoff is real in plants that run 24/7, rely on legacy controllers or depend on vendor intervention for safety-related systems. Current guidance suggests that exceptions can exist, but they should be narrow, documented and compensating controls must be strong.

One common edge case is a legacy HMI or engineering workstation that technically supports only one local account. In that situation, best practice is evolving rather than settled: organisations may use a controlled jump host, time-bound access, session recording and named approval records to preserve accountability. Another edge case is disaster recovery, where emergency use accounts may be justified, but they should be vaulted, rotated and tested, not handed around informally. The broader lesson is that convergence makes “shared because it is convenient” much harder to defend, especially where auditability matters for safety or regulatory review.

The NIST Cybersecurity Framework 2.0 supports this by pushing organisations toward resilient access governance, while NHI Mgmt Group’s research shows how weak credential discipline persists until exposed by an incident. That pattern is familiar in the Schneider Electric credentials breach and similar cases, where shared access turns a technical event into an attribution gap.

Related resources from NHI Mgmt Group

• What breaks when organisations manage service accounts like human users?
• What breaks when service accounts are reused across pipeline environments?
• Who is accountable when OT remote access cannot be traced after the fact?
• Why do non-human identities create more audit risk than human accounts?