How should security teams control vendor access in water utility OT environments?

Treat vendor access as privileged identity governance, not as a convenience layer. Every remote path should have a named owner, a scoped purpose, session logging, and a revocation trigger. If access cannot be attributed and reviewed, it should not reach OT assets.

Why This Matters for Security Teams

Vendor access in water utility OT is not just remote support, it is a privileged pathway into systems where safety, uptime, and regulatory exposure all converge. A vendor session that is over-broad, unlogged, or difficult to revoke can outlast the maintenance task and become a standing foothold. That is why NHI Management Group treats vendor accounts, service links, and remote tooling as identity governance problems, not convenience features.

Industry research shows how often the basics fail: in The State of Non-Human Identity Security, 85% of organisations reported incomplete visibility into third-party vendors connected via OAuth apps. In OT, that visibility gap is more dangerous because remote access often bridges segmented environments and legacy systems. The practical question is not whether a vendor can connect, but whether every connection is attributable, scoped, and revocable before it reaches the control network. The same governance discipline described in Ultimate Guide to NHIs applies here: inventory, ownership, lifecycle control, and revocation must be explicit.

OWASP’s Non-Human Identity Top 10 reinforces the same pattern: unmanaged secrets, excessive privilege, and weak monitoring are recurring failure modes. In practice, many security teams discover vendor overreach only after an incident review or plant outage, rather than through deliberate access design.

How It Works in Practice

Effective control starts by treating each vendor as a separately governed identity, with a named business owner, a defined purpose, and a time-bound access path. For water utility OT, that usually means remote access brokers, jump hosts, or controlled maintenance windows rather than direct connectivity into PLCs, HMIs, or historians. Every session should be attributable to a person or service account, logged end to end, and tied to a ticket or change record so the purpose can be reviewed later.

Current guidance suggests three control layers work best together:

• Identity binding: the vendor must authenticate with strong identity assurance, not shared credentials.
• Session control: access is approved for a specific task, for a limited duration, with recording where feasible.
• Revocation trigger: access expires automatically, or is cut off when the job closes, the contract ends, or behaviour deviates.

This is where NHI governance becomes operational. Vendor accounts often behave like non-human identities because they are used by tools, scripts, integrations, and remote support platforms. The 52 NHI Breaches Analysis shows how quickly weak identity controls turn into lateral movement and persistence. Pair that with the Ultimate Guide to NHIs — Key Challenges and Risks, and the operational lesson is clear: long-lived credentials, poorly monitored vendor portals, and shared admin access are incompatible with resilient OT governance.

For water utilities, the best practice is evolving toward zero standing privilege, just-in-time elevation, and continuous session oversight. These controls tend to break down when vendors demand persistent VPN access to legacy OT assets because the environment cannot support per-session authorization or reliable logging.

Common Variations and Edge Cases

Tighter vendor controls often increase operational friction, so organisations must balance plant availability against administrative overhead. That tradeoff becomes especially sharp during emergency repair work, when waiting for full approval chains can slow restoration. The answer is not to relax governance, but to pre-approve emergency paths with shorter TTLs, stronger monitoring, and explicit post-event review.

There is no universal standard for every OT edge case yet, but current guidance suggests the following variations are common:

• Break-glass access should be separate from routine vendor access and heavily monitored.
• Third-party managed services should use distinct identities and secrets per customer environment.
• Shared vendor jump boxes should be phased out where individual attribution is possible.
• Legacy OT systems that cannot support modern identity controls should be isolated behind compensating controls, not exposed directly.

Utilities also need to distinguish between human vendor technicians and non-human vendor tooling. Scripts, collectors, and remote management agents should follow the same lifecycle rules as other NHIs, including rotation, logging, and offboarding. NHI Management Group’s research shows that poor offboarding and weak rotation are not edge cases but common conditions, which is why the state of NHI security matters directly to OT vendor governance. Where OT environments cannot support attribution, revocation, and logging, the access path should remain closed until those controls exist.

Related resources from NHI Mgmt Group

• How should procurement teams evaluate access security tools in defence and government environments?
• How should security teams prioritise NHI remediation in cloud environments?
• How should security teams run access reviews for non-human identities?
• How should security teams govern non-human identities that have persistent access?