The control gap is that external support becomes a standing access path instead of a task-specific exception. That breaks accountability, makes revocation slow and leaves utilities unable to prove who touched which OT asset during routine maintenance or incident response.
How vendor access changes the OT operating model
In OT, vendor support is not just another remote login. It creates a third-party control plane over assets that often cannot tolerate broad, persistent, or poorly attributed access. Without OT identity governance, the utility loses the discipline needed to make vendor access time-bound, scoped to the task, and tied to an accountable sponsor and asset owner.
That matters because OT environments usually mix long-lived equipment, fragile maintenance windows, and safety-sensitive changes. A vendor account that is approved once and then left in place becomes an operational dependency, not a controlled exception.
A practical way to think about it is that the access path should exist only for the duration of a specific job and should be removed or revalidated when the job ends. If the organisation cannot express that rule consistently, it is relying on trust rather than governance.
What breaks when access is not identity-governed
The first thing that breaks is accountability. When support is shared, inherited, or never recertified, the utility cannot reliably answer who accessed which PLC, HMI, historian, or engineering workstation, under whose approval, and for what change.
The second break is revocation. If access lives across vendor folders, remote tools, local exceptions, and one-off passwords, removing it becomes slow and error-prone. That is how temporary support quietly turns into standing privilege.
The third break is auditability during maintenance and incident response. Without clean identity records, teams struggle to separate authorised service activity from suspicious activity, especially when the same vendor path is used across multiple sites or assets. OT and ICS Identity and Access Guide is useful here because it frames vendor remote access, shared accounts, and OT segmentation as one control problem rather than three disconnected ones.
Why the failure matters beyond access management
In water utilities, the operational consequence is larger than an IAM hygiene issue. Ungoverned vendor access can widen blast radius, blur change ownership, and make it harder to contain a fault, because the organisation no longer knows which remote path is legitimate and which path must be cut first.
It also weakens incident reconstruction. If a control set has no clear owner, expiry, or access record, responders cannot confidently trace whether a configuration change, vendor action, or malicious misuse caused the event.
OT guidance from NIST SP 800-82 Rev 3, OT Security Guide and CISA Industrial Control Systems both reinforce the same practical reality: remote access must be bounded, monitored, and integrated with OT-specific operational constraints, not treated like ordinary IT support.
The security issue is therefore not vendor access itself, but vendor access without lifecycle control. Once that happens, the utility loses both preventive control and forensic confidence.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5, CIS Controls v8, NIST CSF 2.0 and NIST Zero Trust (SP 800-207) set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-2 — Identification and Authentication (Organizational Users) | Vendor support access needs strong identity proofing and accountability. |
| IA-5 — Authenticator Management | Standing vendor access depends on credential issuance, rotation, and revocation. | |
| AC-2 — Account Management | The question is about governance of third-party access lifecycle and revocation. | |
| Recommendation — Enforce distinct identities for vendor support users and remove shared logins. Rotate and revoke support credentials on a defined schedule and after each task. Maintain approval, expiry, and disablement records for every vendor access account. | ||
| ISO/IEC 27001:2022 | A.5.18 — Access rights | Vendor access without governance is fundamentally an access-rights control failure. |
| A.5.15 — Access control | OT vendor access must be scoped and constrained to the task and asset. | |
| Recommendation — Review and remove vendor access rights after the authorised maintenance window ends. Apply task-scoped access control with explicit approval and least privilege. | ||
| CIS Controls v8 | CIS-5 — Account Management | Vendor access governance hinges on controlled account lifecycle and review. |
| Recommendation — Inventory, review, and disable third-party accounts that no longer have a valid support need. | ||
| NIST CSF 2.0 | PR.AA-05 — Identity and Access Management | The issue is a failure to govern access paths and privileges to OT assets. |
| Recommendation — Implement identity governance for support access, including approval, scope, and revocation. | ||
| NIST Zero Trust (SP 800-207) | PR.AA — Identity and Access Management | Zero trust requires vendor access to be explicitly authenticated and continuously constrained. |
| Recommendation — Use explicit verification and least privilege for every vendor support session. | ||
Practitioner Guidance
What to prioritise: Start with the accounts and access paths that can reach production OT assets, especially remote support channels, shared credentials, and emergency access routes. Those are the places where standing privilege most quickly becomes a safety and availability problem.
What to verify: Confirm that every vendor session has a named business sponsor, a defined maintenance purpose, an expiry condition, and a revocation path that actually works. If any of those are missing, the access is not task-specific, it is just temporary in name.
Decision rule: If the utility cannot prove who accessed the asset, when they accessed it, and why they were authorised, treat the access model as uncontrolled and pause expansion until governance is in place.
Practitioner takeaway: In OT, the goal is not to eliminate vendor support, but to ensure that support never becomes a permanent, unowned pathway into production control.