What breaks when industrial remote access still depends on shared vendor accounts?

Why shared vendor access breaks accountability in OT

Industrial remote access depends on being able to tie an action to a person, prove the access path, and remove that path when the work is finished. Shared vendor accounts erase that chain of custody. Once multiple technicians use one login, attribution becomes weak, scope is harder to bound, and revocation turns into a blunt change that can disrupt unrelated support work.

That is why OT teams treat vendor access as a control problem, not just a convenience problem. A single shared account can mask who entered, what system they reached, and whether they were supposed to touch that asset at all. OT and ICS Identity and Access Guide is useful here because it frames vendor remote access around ownership, segmentation, and explicit access governance rather than informal account sharing.

When access is not individually attributable, the organisation also loses a clean audit trail. That matters in industrial environments because remote support often spans HMIs, engineering workstations, historians, jump servers, and maintenance tools. Shared credentials collapse those boundaries and make it much harder to distinguish legitimate maintenance from overreach or misuse. CISA Industrial Control Systems guidance is relevant because it repeatedly treats remote access, segmentation, and monitoring as core ICS security concerns.

Why revocation and scope control fail together

Shared vendor accounts create a coupled failure mode: if one vendor leaves, a password change may be the only reliable way to remove access, and that change affects everyone else using the same account. In practice, organisations delay revocation because they do not want to break support arrangements, which means access persists longer than intended. That lingering access is especially dangerous when the account can still reach multiple plants, zones, or maintenance interfaces.

Scope control fails for the same reason. If one account is allowed through a remote access path, the organisation often cannot limit that session to a single asset or maintenance ticket with enough precision. The result is an all-or-nothing trust model, which is the opposite of what industrial environments need. NIST SP 800-207 Zero Trust Architecture matters because it pushes least privilege and explicit verification instead of implicit trust in a shared login.

OT programmes usually need granular controls such as time bounds, asset bounds, and session oversight. Without those, a shared account becomes a standing exception that is easy to reuse across vendors, sites, and incidents. The practical issue is not only unauthorized access, but also inability to prove that access stayed inside its intended operational scope.

What this means for support, auditing, and blast radius

Shared vendor access tends to expand blast radius. If one password leaks, every person and system behind that account is exposed at once, and the compromise can blend into routine maintenance traffic. That is why industrial environments often pair remote access governance with monitored sessions, unique accounts, and segmentation. Privileged Session Management Guide is a good fit when the concern is controlling and recording high-impact remote sessions rather than just authenticating entry.

At the same time, the support model becomes harder to run safely. Vendors may prefer one shared login because it is easy to hand off internally, but that convenience hides ownership, weakens reviews, and makes offboarding incomplete. Third-Party, B2B and Contractor Access Guide helps because it treats suppliers and contractors as governed identities with sponsorship, time limits, and reviewable access, not as a pooled credential.

For industrial organisations, the real question is whether the remote access model can survive an audit, a personnel change, and a compromise without collapsing into emergency password resets. If it cannot, the account design is already too weak for the operational risk involved.

Risk and Threat Considerations

Shared vendor accounts create a high-confidence exposure path for both misuse and compromise. Once a password is shared across people, an attacker who steals it, buys it, or inherits it through poor offboarding can look like any other approved user, which reduces detection quality and increases the chance of lateral movement into OT-adjacent systems.

Failure mechanism: A single shared login removes per-user attribution, so one compromise or insider misuse event can be indistinguishable from normal maintenance activity and can persist until the account password is changed everywhere it is reused.

Impact: The organisation can lose the ability to isolate the affected person, contain the access path quickly, or prove which asset was touched, which increases operational disruption, forensic uncertainty, and the chance of wider plant access than intended.

Practitioner Guidance

What to prioritise: Replace shared vendor logins with individually assigned access first, then add session control and asset scoping. If you cannot name the human who used a remote session, you do not yet have a defensible industrial access model.

What to verify: Confirm that every vendor connection is tied to a named person, a bounded approval, and a revocation path that does not depend on changing one password for many users. Verify that support sessions can be reviewed after the fact without relying on tribal knowledge from the vendor.

Common mistake: Treating a shared account as acceptable because the vendor is trusted. Trust in the vendor does not replace attribution, and it does not reduce the blast radius when credentials leak or staff change.

Practitioner takeaway: In OT, shared vendor access is not just inefficient, it is a structural control failure because it prevents clean ownership, clean offboarding, and clean containment at the same time.

Related resources from NHI Mgmt Group

• What breaks when remote access still depends on persistent VPN credentials?
• Why do shared accounts create such a large risk in industrial remote access?
• What breaks when industrial access still depends on standing credentials?
• What breaks when remote workstation access still depends on manual administration and static records?