# How Should Utilities Control Vendor Access to Critical Systems in 2026?

vuti.app · October 1, 2026

> Direct Answer: Treat Utility Vendor Access as Managed Remote Privileged Access Utilities should control vendor access through a documented...

## Direct Answer: Treat Utility Vendor Access as Managed Remote Privileged Access

Utilities should control vendor access through a documented, time-limited privileged-access system rather than shared administrator accounts, permanent VPN memberships, or unrestricted remote-control software. Effective controls usually combine identity verification, multifactor authentication, approval workflows, just-in-time elevation, session recording, application allowlists, network segmentation, and a reliable offboarding process. The objective is not to block legitimate maintenance; it is to make every external connection attributable, limited to an approved task, and reviewable afterward.

**Also worth reading:** [What Is Virtual Utilities Vendor Ops SaaS and Is It Worth the Cost?](https://vuti.app/knowledge/what_is_virtual_utilities_vendor_ops_saas_and_is_it_worth_the_cost.php) · [What Are the Best Third-Party Risk Controls for Business Utilities and Vendor Operations?](https://vuti.app/knowledge/what_are_the_best_third-party_risk_controls_for_business_utilities_and_vendor_operations.php) · [How Do You Build a Vendor Software TCO Template for Utilities?](https://vuti.app/knowledge/how_do_you_build_a_vendor_software_tco_template_for_utilities.php)

This matters because utility environments may combine office IT, billing platforms, supervisory control and data acquisition systems, building systems, and other operational technology. A vendor who only needs to update a monitoring display can potentially receive broader access than intended if permissions are granted through a shared account or a broadly connected remote-support tool. NIST SP 1800-45 identifies remote-access security as a priority for water and wastewater organizations, while sector guidance continues to emphasize that operational technology can be exposed through ordinary remote-support arrangements. Access control should therefore be based on the system being touched, the privileges required, the reason for access, and the expected duration—not merely on the vendor’s contract status.

A defensible baseline is to require named individual identities, phishing-resistant multifactor authentication for privileged access, approval by an accountable utility employee, and automatic expiration when maintenance is complete. Administrative sessions should be recorded, and commands or screen activity should be retained under a policy approved by legal, security, privacy, and operations teams. Restricted accounts should be used when full administrator rights are unnecessary. Access must also be separated between production and test systems so that support for a lower-risk environment does not become a path into an operational environment.

## How Utility Vendor Access Controls Work

Most mature programs use a gateway between vendors and utility resources. The gateway authenticates the individual, checks the requested role and system, obtains the required approval, and opens only the permitted connection. The utility can then apply time limits, recording, command logging, and emergency shutdown controls. This arrangement is stronger than giving a vendor direct access to a virtual private network because the gateway can enforce conditions continuously instead of trusting the vendor or workstation to behave correctly.

The access path commonly has four layers. First, identity controls establish which employee or contractor is connecting. Second, authorization determines which assets and actions are permitted. Third, technical enforcement segments the connection and limits available tools. Fourth, oversight records and reviews the session. Removing one layer can still leave useful protection, but a recording tool without restricted privileges only documents excessive access; multifactor authentication without prompt revocation can leave a valid credential exposed indefinitely.

Controls can be different by vendor function. A meter-reading integration may need a service identity restricted to a data interface, while a firmware engineer troubleshooting a substation device may require temporary access to a jump host and a tightly defined maintenance window. A cybersecurity incident-response company should be prepared to operate under a separate emergency procedure, but emergency access should not become a routine method of bypassing normal approval. The desired pattern is to preconfigure named responders, required authenticator types, customer-authorized domains, and escalation contacts before an incident occurs.

For virtual utility platforms and vendor-operations software, access policies can be translated into roles such as requester, approver, service-desk coordinator, vendor technician, platform administrator, and auditor. Each role should have different permissions. A requester can submit a ticket but cannot approve it; a coordinator can schedule work but cannot silently elevate privileges; a vendor technician can connect only during approved windows; and an auditor can review logs without changing systems. Separation of duties is particularly important where one person could otherwise request, approve, and use privileged access.

## A Practical Implementation Process

Begin by inventorying every vendor, integration, remote-support tool, service account, shared account, and connection route. Include contractors, software-as-a-service providers, equipment manufacturers, consultants, cloud administrators, and temporary emergency technicians. Record the business purpose, systems involved, privileged actions, frequency of use, data accessed, geographic location, and contractual owner for each connection. This inventory frequently reveals forgotten tools that were installed for a short repair and never removed.

Next, classify systems by sensitivity and business impact. Billing and customer-information systems may require privacy and financial controls, while control systems may require additional segmentation and operational change procedures. Access can then be matched to risk: read-only support may be sufficient for routine work, restricted command-line access may support diagnostics, and full administrative access should be reserved for exceptional tasks with technical justification. Organizations should be able to explain why a vendor needs a particular privilege and why a less powerful alternative is inadequate.

The workflow should require a ticket or maintenance record before access is granted. The requester should identify the vendor technician, purpose, target system, required role, start time, expected duration, and approving utility owner. Access should default to expire—often within a defined maintenance window—rather than remain open until someone remembers to remove it. Just-in-time elevation should issue rights only after approval and return them to baseline when the session ends. For higher-risk systems, a second authorization from operations, cybersecurity, or a named system owner may be appropriate.

Technical enforcement must follow the approved task. Connections should enter through a managed gateway or hardened jump host, not through unrestricted direct remote desktop access. Network policy should limit the vendor to named destinations and ports, while endpoint or application policy should restrict installed tools and available commands where feasible. Clipboard transfer, file upload, local drive mapping, printing, and screen viewing may need separate controls. Session recording should capture administrative activity without becoming an indiscriminate copy of every document handled during ordinary work.

Finally, test offboarding. Remove a sample user immediately after a simulated engagement and verify that cached credentials, active sessions, API keys, VPN access, shared folders, and identity-provider groups are all disabled. The expected result should be visible within minutes for urgent terminations, although some downstream systems may require up to 24 hours to synchronize. Quarterly reviews should confirm that dormant accounts are removed, active privileged accounts still have owners, service accounts are not shared, and vendor access matches current contracts and maintenance needs.

## Comparing Access-Control Alternatives

There is no single product category that solves the entire problem. A basic remote-support application can provide convenience, a privileged-access management platform can centralize policy and recording, and a network access management platform can control reachability. Utilities often need a combination rather than assuming any one product is sufficient.

| Feature | Standalone Remote-Support Tool | Privileged-Access Management Platform | Network Access Management | Combined Program |
| --- | --- | --- | --- | --- |
| Core strength | Fast, on-demand assistance | Identity, approvals, temporary privilege, recording | Segmentation and destination-level policy | Coordinated governance across people, privileges, and networks |
| Typical users | Small IT teams | Security and operations organizations | Network and security operations | Utilities with several vendors and mixed IT/OT systems |
| Approval workflow | Often limited | Usually configurable | Often separate from identity workflow | Can require owner, security, or operations approval |
| Best fit | Noncritical, infrequent support | Privileged vendor sessions | Restricting which systems can be reached | Regulated, multi-vendor environments |
| Main limitation | May grant broad interactive access | Cost and deployment complexity | May not govern actions inside a system | Requires governance, ownership, and process discipline |
| Audit evidence | Session video or logs | Detailed session and command records | Connection and policy logs | Stronger end-to-end evidence when configured well |
| Cost profile | Lowest to moderate | Moderate to high | Moderate to high | Highest platform cost, but potentially lower operational risk |

A standalone tool may be acceptable for routine, nonprivileged assistance if identities are verified, access is approved, and the connection cannot reach sensitive systems. It is weaker when it allows an unattended code, persistent account, arbitrary file transfer, or direct network access. Privileged-access management is generally better for administrator sessions because it can join identity, ticket approval, credential vaulting, temporary elevation, and recording. Network controls remain necessary because privileged-access software may authorize a user without sufficiently limiting what that user can reach.
Buyers should evaluate the existing environment before purchasing another platform. Compare capabilities against requirements rather than feature totals: check whether the product supports named identities, approval expiration, phishing-resistant authentication, API or command logging, session termination, private or dedicated gateways, role design, and integrations with the utility’s identity provider, ticketing system, and security monitoring. Remote screen-sharing utilities can be useful during a narrow incident, but they should not become a shadow administration channel.

## Common Mistakes and Why They Fail

One common mistake is treating vendor status as an authorization. Being under contract or passing a background check does not determine whether a technician needs administrator rights to a particular system on a particular day. Authorization must be task-specific and system-specific. Shared administrator accounts are especially problematic because they erase attribution, undermine individual revocation, and make incident review less reliable. A service account may be appropriate for a machine-to-machine integration, but its owner, scope, credential storage, rotation date, and permitted endpoints still need documentation.

Another mistake is relying on a password reset as the entire offboarding plan. Changing one directory password may not terminate an active VPN session, API token, remote-support code, cached browser credential, SSH key, or locally installed agent. Termination should propagate through identity, gateway, network, application, and vendor processes, with an owner responsible for confirming closure. Organizations sometimes set access expiration in the ticketing system but never enforce it in the system that actually grants connectivity.

Recording is also frequently misunderstood. A recording proves that a session occurred, but it does not prevent a harmful action. Conversely, recording every ordinary interaction can create privacy, employee-monitoring, data-retention, and storage concerns. The better approach is risk-based session policy: record and potentially retain command-level evidence for privileged activity while applying narrower capture to routine support. Recording should not expose sensitive information more widely than the underlying system permits.

Finally, utilities may either overreact or underreact. Blocking all vendor support can delay restoration and create pressure for less secure workarounds. Allowing access first and documenting it later defeats preventive control. A measured program defines low-risk self-service, standard approved remote support, privileged maintenance, and emergency access as distinct paths. Each path has different approval, authentication, monitoring, and expiration requirements.

## When to Act and How Quickly

Immediate action is warranted when vendor accounts are shared, former employees retain access, default passwords remain active, remote connections bypass security monitoring, or one vendor can reach many production systems. The same day should be enough to disable a clearly unauthorized or terminated account when business ownership confirms it is no longer needed. Urgent containment should include gateway sessions, VPN accounts, privileged groups, API credentials, and active remote-control sessions rather than just the primary login.

For a broader program, a 30-day discovery phase can identify all access paths, account owners, sensitive systems, and unmanaged tools. By day 60, organizations can define roles, approval rules, and emergency procedures. By day 90, they can deploy controlled access for the highest-risk vendors, test revocation, and begin periodic reviews. These are planning targets, not regulatory safe harbors; the timeline depends on the number of systems, vendors, legacy equipment, and operational constraints.

A utility should act before its next major vendor engagement when possible. Waiting until a control-room outage or data breach occurs turns access management into an incident-response problem. Regulatory and customer expectations increasingly favor demonstrable governance, but compliance language varies by jurisdiction and sector. Utilities in the United States should assess applicable cybersecurity, reliability, privacy, procurement, and state requirements with qualified counsel and sector specialists. Water and wastewater organizations can use NIST methods as a practical basis, while electric organizations may also need to consider FERC-related reliability and cybersecurity obligations.

Routine reviews should occur at least quarterly for privileged vendor access and whenever contracts, roles, or system criticality change. Access should also be triggered for immediate termination, loss of a required authenticator, suspected credential exposure, unusual activity, or completion of maintenance. Logs should be retained long enough to investigate incidents and support contractual or regulatory reviews; the exact period requires a documented policy rather than an arbitrary universal number. For contracts, vendors should be required to support individual authentication, prompt revocation, cooperation with investigations, and restrictions on subcontractor access.

## Cost, Ownership, and Operational Fit

Pricing varies considerably because some tools charge per administrator, technician, asset, connection, or feature module. A lightweight remote-support subscription may cost substantially less than a privileged-access platform deployed across many business units and regulated environments. Network access management, identity integration, logging, and long-term evidence storage can add implementation and subscription costs. The cheapest option is not necessarily the one with the lowest license fee, since an unmanaged tool may introduce outage time, investigation expense, compliance exposure, or security risk.

For small utilities, a practical starting point may be a managed gateway, named accounts, multifactor authentication, ticketing approval, short-lived credentials, and recording for administrative sessions. Larger utilities can add role-based privileged-access management, separate IT and OT gateways, API discovery, automated account reviews, and integration with security information and event management tools. If a utility already owns capable platforms, configuration and governance may deliver more value than immediate procurement.

Ownership must be explicit. The business system owner decides whether access is necessary, operations approves operational impact, cybersecurity sets technical requirements, identity or network teams enforce access, procurement manages contractual obligations, and internal audit tests the controls. A vendor-operations team can coordinate the process, but it should not be the only control. No single tool can compensate for unclear asset ownership, an unpatched system, poor configuration, or an employee bypassing the approved channel.

The right design is proportionate to the utility’s size and risk while preserving a few non-negotiable controls: named identities, multifactor authentication, least privilege, approval, expiration, monitoring, and rapid termination. Those controls reduce risk without assuming that vendors are untrusted or that every maintenance task should be delayed. They also create evidence that management can use when customers, regulators, insurers, or internal auditors ask how third parties are protected.

In short, utility vendor access should be treated as privileged remote access by default and downgraded only when a documented task permits it. Start with the highest-risk systems and connections, remove persistent shared access, require individual accountability, and test the offboarding process before scaling across the enterprise. The goal is controlled operational availability: vendors can perform approved work when needed, but they cannot roam across utility systems or retain invisible access after the engagement ends.

## Quick answers

### What is the safest way for a utility vendor to connect remotely?

The safest general pattern is a named individual account through a managed gateway, protected by multifactor authentication and limited to approved systems and time windows. The utility should require approval, record privileged activity, restrict unnecessary privileges, and revoke access when maintenance ends. A shared password or direct remote desktop connection should not be the default.

### How long should temporary vendor access last?

Temporary access should normally cover only the approved maintenance window, such as a scheduled few-hour session, rather than remain open indefinitely. Higher-risk work may require shorter permissions and additional approval. The appropriate duration depends on the task, system sensitivity, and the utility’s change-management and incident-response procedures.

### Are remote desktop tools acceptable for utility vendors?

They can be acceptable for controlled support when the tool uses named authentication, approval, restricted destinations, session monitoring, and rapid termination. Unattended access, broad file transfer, persistent codes, or unrestricted connectivity create avoidable risks. Utilities should compare the tool’s actual permissions with the vendor’s task requirements.

### Should vendors use their own accounts or utility-issued accounts?

Each technician should authenticate as an individually attributable identity, whether the identity is issued by the utility or federated by an approved vendor identity system. Sharing one account defeats attribution and makes revocation less reliable. Machine-to-machine service accounts may also be necessary, but their scope, owner, credentials, and rotation schedule must be documented.

### What is the first step in improving utility vendor access controls?

Start with an inventory of vendor connections, remote-support tools, service accounts, shared credentials, and system owners. Identify any access that persists after a contract ends or can reach operational technology without approval. Prioritizing the highest-risk connection paths usually produces faster risk reduction than trying to replace every tool at once.

Canonical: https://vuti.app/knowledge/how_should_utilities_control_vendor_access_to_critical_systems_in_2026.php
Markdown: https://vuti.app/knowledge/how_should_utilities_control_vendor_access_to_critical_systems_in_2026.php/index.md