Why do shared accounts create such a large risk in industrial remote access?

Why This Matters for Security Teams

Shared accounts are not just an audit nuisance. In industrial remote access, they erase operator attribution, make approval boundaries blurry, and turn every session into a dispute about who actually executed a command. That matters in OT because remote access often touches safety-critical systems, vendor support paths, and time-sensitive maintenance windows. Once a shared login exists, least privilege becomes difficult to prove and even harder to enforce consistently.

The practical risk is that a compromise or misuse can spread across multiple people, vendors, and shifts before anyone can reconstruct the timeline. Guidance from the NIST Cybersecurity Framework 2.0 and the OWASP Non-Human Identity Top 10 both point toward stronger identity accountability, because access that cannot be attributed is access that cannot be governed. NHIMG research also shows the scale of the broader identity problem: the Ultimate Guide to NHIs notes that 80% of identity breaches involved compromised non-human identities such as service accounts and API keys. In practice, many security teams discover the weakness only after a maintenance event, outage, or incident has already made the account’s shared nature visible.

How It Works in Practice

The risk emerges from how industrial remote access is usually operationalised. A shared account may be used by contractors, plant engineers, and control-system specialists across multiple sites, often through VPNs, jump servers, or remote support tools. That creates a single credential with broad standing access, weak attribution, and little session-level accountability. If the password is reused, written down, or embedded in a support workflow, compromise becomes a systems problem rather than a single-user problem.

Current best practice is to replace shared human credentials with named identities, per-user MFA, and session recording, then combine that with role-based access and just-in-time elevation. For industrial environments, the control plane should also preserve who requested access, who approved it, what asset was touched, and what command path was used. That is the minimum needed for auditability and incident response. The identity model should align with NIST SP 800-63 Digital Identity Guidelines for authentication assurance, while NHI lifecycle controls should follow the operational patterns described in NHIMG’s Top 10 NHI Issues.

• Use individual accounts for every operator, contractor, and vendor.
• Issue time-bound access for maintenance windows instead of permanent shared credentials.
• Record session metadata, commands, and approvals for forensic reconstruction.
• Separate break-glass access from routine support access.
• Rotate and revoke credentials immediately after remote work completes.

These controls tend to break down when legacy OT assets only support one login path or when vendors insist on a single “service” account that bypasses session controls.

Common Variations and Edge Cases

Tighter remote-access control often increases operational overhead, so organisations have to balance availability against accountability. That tradeoff is real in 24/7 plants, where downtime for access changes can affect production, maintenance, and safety workflows. There is no universal standard for every OT environment yet, but current guidance suggests that convenience should never be the reason a shared account remains in place.

Some teams use a shared jump host account as a temporary exception, but that exception should be narrow, approved, monitored, and time-limited. Others rely on vendor-managed access, which can be acceptable only when the vendor is individually identified and every session is attributable. The stronger pattern is to treat shared credentials as a transitional risk, not an operating model. NHIMG’s 52 NHI Breaches Analysis shows how often identity failures become incident pathways, and the lesson maps directly to industrial remote access: when too many people share one account, containment, blame assignment, and remediation all slow down. In mature programs, shared access is eventually removed, not merely wrapped in more approval steps.

Related resources from NHI Mgmt Group

• Why do collaboration tools create such a large secrets risk?
• Why do third-party vendors create extra risk in industrial access models?
• Why do non-human identities create more audit risk than human accounts?
• When does JIT access create more risk than it reduces?