What breaks when OT teams keep using permanent privileged accounts?

Why This Matters for Security Teams

Permanent privileged accounts are especially dangerous in OT because they turn maintenance convenience into standing authority. That is a poor fit for environments where availability, safety, and change control matter as much as confidentiality. Once a single account can log in at any time with broad rights, incident response becomes slower, revocation becomes riskier, and the organisation inherits a long-lived trust path that is hard to observe and harder to prove necessary. NHI Management Group’s Ultimate Guide to NHIs - Key Challenges and Risks notes that 97% of NHIs carry excessive privileges, which is exactly the kind of condition permanent OT accounts tend to create and preserve.

The core issue is not just privilege level, but persistence. A permanent account can be reused across shifts, vendors, emergency changes, and remote support paths without a fresh authorisation decision. That makes it much easier for malware, insiders, or compromised contractor access to move from one system to another. The OWASP Non-Human Identity Top 10 treats overprivileged and poorly governed non-human access as a structural weakness, not an edge case. In practice, many security teams discover the problem only after a plant outage, a vendor compromise, or an audit finding forces a review of who really had standing access.

How It Works in Practice

The practical failure mode is simple: a permanent privileged account becomes the default answer for everything, so access is never tightly scoped to a task, a window, or a device state. In OT, that often means shared admin logins, embedded service accounts in engineering tools, and vendor accounts that remain active long after a project ends. Once those identities exist, they are difficult to correlate to one person, one purpose, or one control owner. A stronger model uses short-lived, task-bound access with clear identity proof and runtime policy checks. For OT teams, that usually means combining workload identity, just-in-time access, and explicit approval for high-risk actions. Current guidance suggests the following pattern:

• Issue access only for the maintenance window or change ticket, then revoke it automatically.
• Bind access to the device, session, or workload performing the task, not to a permanent shared credential.
• Separate read-only diagnostics from write operations so routine troubleshooting does not inherit full control rights.
• Log every privileged action with strong identity, purpose, and asset context for post-incident review.

The OT-specific point is that “least privilege” must be operational, not theoretical. The Schneider Electric credentials breach illustrates how credential exposure can extend beyond a single user account and affect broader operational trust. Where possible, align privileged access with the controls described in OWASP Non-Human Identity Top 10, especially around lifecycle management, secret hygiene, and access minimisation. These controls tend to break down when legacy controllers require static credentials and cannot support per-session authentication without compensating architecture.

Common Variations and Edge Cases

Tighter privileged access often increases operational overhead, requiring organisations to balance safety and uptime against speed of recovery and maintenance convenience. That tradeoff is real in OT, where some assets cannot tolerate frequent authentication changes, agent installs, or network re-segmentation. Best practice is evolving here, and there is no universal standard for every plant class or vendor stack yet. A few common exceptions matter:

• Emergency break-glass access may remain permanent in design, but it should be isolated, heavily monitored, and tested under controlled conditions.
• Legacy PLCs and historians may require static credentials, but those credentials should be wrapped with compensating controls such as jump hosts, session recording, and strict network allowlisting.
• Vendor remote support often needs elevated access, but that access should be time-bound and approval-driven rather than always on.

The main decision is whether a permanent account is truly unavoidable or simply convenient. In many environments, permanence survives because no one has mapped who owns the account, what it can touch, or how quickly it can be revoked. The safest operational posture is to treat standing privilege as an exception that requires documented justification, not as a default entitlement. This is also where the broader governance gap appears: without lifecycle control, permanent accounts become invisible technical debt that survives audits, outlives projects, and widens blast radius over time.

Related resources from NHI Mgmt Group

• What breaks when manufacturers keep shared OT accounts after convergence?
• How should teams secure non-human identities across cloud and SaaS?
• How should security teams decide whether JIT access is safe for non-human identities?
• How should teams reduce the risk from exposed NHI secrets?