# How Should Utility Vendors Control Remote Access in 2026?

vuti.app · September 27, 2026

> What Utility Vendor Access Control Actually Means Utility vendor access control is the set of administrative, technical, and contractual controls used...

## What Utility Vendor Access Control Actually Means

Utility vendor access control is the set of administrative, technical, and contractual controls used to grant, monitor, restrict, and terminate third-party access to operational technology, industrial control systems, business systems, and supporting infrastructure. For a small water or electric utility, a vendor may need temporary access to a supervisory control and data acquisition system, programmable logic controller, historian, meter platform, network device, or maintenance workstation. That access should be treated as privileged access because a vendor account can cross boundaries between an office network and an operational environment. The central question is not simply whether an authenticated user can log in, but whether the utility can prove why the person needed access, what systems were affected, what actions occurred, and when access ended. As of September 27, 2026, cyber risk is rising because utilities are combining operational technology, cloud services, remote support, and distributed infrastructure. A defensible control model therefore combines identity verification, least privilege, multifactor authentication, session recording, approval workflows, network segmentation, and documented review.

**Also worth reading:** [How Do Virtual Utility Vendors Improve Facilities and Workplace Operations?](https://vuti.app/knowledge/how_do_virtual_utility_vendors_improve_facilities_and_workplace_operations.php) · [How Do B2B Teams Automate Utility Invoice Processing Without Losing Control?](https://vuti.app/knowledge/how_do_b2b_teams_automate_utility_invoice_processing_without_losing_control.php) · [Contractor Access Compliance: How Should Organizations Control External Partner Access Without Slowing Operations?](https://vuti.app/knowledge/contractor_access_compliance_how_should_organizations_control_external_partner_access_without_slowing_operations.php)

The term covers both physical and logical access. Logical access includes vendor portals, remote-support tools, shared administrator accounts, vendor-hosted services, and APIs, while physical access includes entering a utility facility, attaching equipment, or working in a substations or pump-station area. It also includes indirect access, such as a cloud provider, software reseller, integrator, consultant, or remote support team that can administer a service used by the utility. The correct unit of control is usually the vendor-person-system relationship, not the company account alone. A large supplier may have several technicians with different jobs, and one incident-response specialist may legitimately require a different permission set from a firmware engineer. Utilities should document those relationships and avoid assuming that a contract automatically creates an appropriate access path.

## Why Remote Vendor Access Is a High-Risk Business Process

Remote access creates a direct path from an external identity to systems that may control water treatment, electric distribution, billing, customer records, or emergency communications. The risk is especially serious when a utility exposes a PLC or other controller directly to the internet, uses a permanent vendor VPN, permits shared credentials, or leaves a support tunnel active after maintenance is complete. Exposed control devices are not ordinary web servers: an attacker or mistaken technician may change operating states, interrupt service, alter telemetry, or create conditions that are difficult to detect until physical consequences occur. Small utilities can be particularly attractive targets because staffing, security resources, and legacy equipment may be limited, although the absence of a large security department does not make the environment low consequence.

The risk is not limited to malicious outsiders. Insiders and ordinary vendors can make destructive changes through an authorized session, especially when an update procedure lacks rollback instructions, configuration backups, or independent review. A compromised contractor laptop can also provide a route into the utility if the vendor network is trusted more broadly than necessary. This is why vendor governance should connect to supply-chain risk management, incident response, and operational change control. Federal attention to energy cybersecurity, including Executive Order 14420 and evolving reliability requirements, reinforces the expectation that third-party connectivity is part of the utility’s risk environment rather than an exception handled informally. The exact obligations depend on the utility’s sector, ownership, jurisdiction, and equipment, so legal counsel and the applicable reliability or regulatory authority should determine whether a specific rule applies.

## A Practical Control Model for Utility Vendors

A workable model begins with a request that identifies the individual, vendor company, business purpose, target systems, required permissions, planned dates, and approving utility owner. The utility should verify the request through a known contact rather than relying solely on an email thread initiated by the vendor. Access should be time-bound, with a default duration of 30 days for routine work unless a documented exception supports a longer period. High-impact or emergency access may be approved quickly, but it should still have a named owner, a post-event review, and an expiration time. The system should not automatically renew access merely because the technician did not close a ticket; renewal should require evidence that the work remains necessary.

Least privilege should be applied to the actual task. Read-only access to a historian is different from permission to change a PLC set point, restart a server, modify firewall rules, or access customer information. Where possible, vendors should use separate accounts for monitoring, support, and administration, and the utility should prohibit shared accounts. Multifactor authentication is a minimum expectation for administrative and remote access, with phishing-resistant methods preferred for privileged accounts. Session controls should include recording, command or activity logs, file-transfer restrictions, clipboard controls where appropriate, and the ability to terminate a session immediately. These controls should be supported by network segmentation: a vendor support path should reach only the required jump host or application, not an entire flat operational network.

A practical review cycle can use three thresholds. At 30 days, the utility should confirm that the access is still required. At 90 days, it should require the manager to reapprove continued access and examine recent activity. At 180 days, it should remove the entitlement unless a current contract, active project, and documented risk acceptance justify retention. These are governance defaults, not universal regulatory limits. Smaller utilities may set shorter periods, while emergency or seasonal operations may need carefully monitored extensions. The key is measurable accountability: the utility should be able to report how many vendor accounts exist, which are privileged, which are inactive, and which have not been reviewed in the last 90 days.

## Technology Options and Comparison

Utilities can combine several controls instead of selecting one product. The right choice depends on the systems being protected, existing network architecture, staffing, and whether the utility needs to secure an IT network, an OT network, or both. A managed virtual private network can make access easier to monitor, but it does not automatically protect a controller that is directly exposed or stop a legitimate user from performing harmful actions. A privileged access management platform can record and approve sessions, yet it may require agents or integrations that are difficult to deploy on older industrial equipment. A zero-trust access service can reduce network trust, but it does not replace vendor identification, maintenance procedures, or contract requirements. A software-defined perimeter can mediate connections, but its usefulness depends on correct segmentation and logging.

| Feature | Option A: VPN with MFA | Option B: Privileged access management | Option C: Zero-trust access proxy |
| --- | --- | --- | --- |
| Typical use | Controlled remote network connection | Approve, record, and administer vendor sessions | Broker access to selected applications or hosts |
| Main strength | Familiar and comparatively easy to deploy | Strong visibility into privileged actions | Reduces broad network trust and can hide internal addresses |
| Main weakness | Broad network access may remain if rules are poorly designed | Can be costly and complex for small utilities | Requires reliable identity, policy, and compatible applications |
| OT suitability | Useful with strict segmentation | Useful for jump hosts and critical systems | Useful for web applications and modern infrastructure |
| Small-utility fit | Often a practical starting point when configured narrowly | Best where compliance evidence and session control are priorities | Helpful when retiring legacy VPN access or limiting application reach |
| Expected cost | Often lower to moderate; approximately $20-$100 per user per month for basic managed VPN capacity | Commonly priced per user, session, or protected endpoint; approximately $10-$50 per user per month for basic offerings | Often $5-$30 per user per month, with enterprise and OT integrations costing more |
| Main test | Can the utility prove that only approved resources are reachable? | Can reviewers inspect activity and terminate sessions quickly? | Can policies apply without exposing the underlying network? |

The table illustrates why “remote access” is not a single product category. A utility may use MFA-protected VPN access for a managed service provider, privileged session recording for a control-room contractor, and a zero-trust proxy for a vendor portal. The least expensive option is not automatically the safest, and the most feature-rich platform is not automatically suitable for an unsupported PLC. Before buying anything, the utility should identify every vendor connection, classify the target system, and test whether the proposed tool can operate without placing a new agent on a fragile device. A product demonstration should include a failed login, an expired account, a session termination event, and an audit export.

## Implementation Steps for Small Utilities

The first step is to create a vendor-access register. It should include the vendor, named user, role, system, connection method, data sensitivity, approval owner, start date, expiration date, and last review date. The utility can begin with a spreadsheet if it has no dedicated system, but the spreadsheet must have restricted access, version history, and a clear owner. The second step is to remove unknown or dormant accounts. Accounts that have not been used for 90 days should be reviewed, while accounts that have not been used for 180 days should ordinarily be disabled. The third step is to identify shared credentials and internet-facing remote services, including vendor portals, TeamViewer-style support tools, SSH gateways, and cloud administration interfaces.

After inventorying access, the utility should create three access tiers: monitored read-only access, approved administrative access, and emergency access with enhanced approval. Each tier should have different authentication, recording, and review requirements. For example, read-only access might use MFA, a managed device, and 30-day expiration. Administrative access might use a named privileged account, command logging, a change ticket, and a 7-day expiration. Emergency access should be disabled by default, activated only through a documented incident procedure, and reviewed within 24 to 72 hours. These intervals are recommended operating practices, not claims about a specific statute. They provide a repeatable way to limit the period in which credentials or sessions can be abused.

The utility should then test the process with a low-risk vendor. During the test, measure the time from request to approval, the time required to remove access, whether the reviewer can see the actual actions taken, and whether the vendor can access resources outside the approved list. A useful target is to complete routine approvals within one business day, revoke access within four hours of a termination or suspected compromise, and review privileged sessions within seven days. The utility should also confirm that logs are retained long enough to investigate an incident but protected from unauthorized alteration. A 12-month retention period is a reasonable planning assumption for many organizations, though the utility should align retention with regulatory, contractual, legal, and operational requirements rather than treating that number as a universal rule.

## Common Mistakes That Weaken the Program

One common mistake is confusing an authenticated connection with controlled access. MFA proves that a user presented an approved factor, but it does not establish that the user needed access to a particular PLC, that the session was authorized, or that the activity stayed within scope. Another mistake is giving a vendor permanent access because a project deadline is uncertain. Temporary access can become permanent by default when automation extends it, so every extension should be visible to a utility owner. A third mistake is allowing vendors to connect through a utility employee’s workstation or a permanently enabled remote-support tool. This makes attribution difficult and can turn one compromised account into a broad path across multiple systems.

Utilities also make the mistake of treating all vendor activity as the same. A billing-system consultant may not need the same protection as a relay-protection engineer, and a cloud provider’s account may require different contractual and monitoring controls from a local contractor. Excessive restrictions can delay emergency work, while insufficient restrictions can expose critical operations. The program should therefore use documented risk categories and compensate for the absence of a universal vendor standard with strong internal governance. Shared administrator accounts, unlogged configuration changes, unencrypted file transfers, and access reviews based only on a vendor-wide list are additional warning signs. They should be corrected before adding more tools.

A subtle mistake is buying a platform without testing OT compatibility. A security appliance that scans normal business traffic may misclassify industrial protocols, create latency, or be unable to support a legacy operating system. Before deployment, the utility should document the device model, firmware, protocol, available processing capacity, maintenance window, and rollback method. The security control should not be placed in a position where it can prevent safe operation or obscure a failure. A pilot on a noncritical environment is preferable to a production-wide rollout. The pilot should last at least 30 days and include a simulated maintenance task, a failed authentication, and an attempted access to an unauthorized address.

## When to Act and How to Estimate Cost

Immediate action is appropriate when a utility has internet-exposed control equipment, an unknown vendor account, a shared administrator credential, a remote-support session that cannot be logged, or evidence of unexplained configuration changes. A utility should also act when a vendor has recently ended a contract, when personnel have changed, or when an incident has occurred elsewhere in the supply chain. These conditions can be addressed first by disabling unused accounts, changing exposed credentials, requiring MFA, and blocking direct external access to OT devices. Emergency measures should be followed by a documented plan rather than becoming the permanent operating model.

For budgeting, small utilities should separate one-time implementation from recurring service costs. A basic internally managed MFA or VPN improvement may cost little in software but still require staff time, configuration, and training. A managed VPN or access proxy may range from roughly $5 to $30 per active user per month for basic service, while privileged access management and identity tools commonly range from about $10 to $50 per user per month, with OT, logging, and enterprise features increasing the total. Prices vary by region, contract length, support requirements, and included modules, so these figures are planning estimates rather than quotations. A 20-person vendor program might therefore cost from about $200 to $1,000 per month before infrastructure and labor, while a more capable enterprise deployment can exceed that range.

The return on investment is primarily reduced exposure and faster verification, not guaranteed prevention of every incident. The utility should measure the number of vendor accounts, privileged accounts, average access lifetime, review completion rate, and time to revoke access. A target of 100% review completion for privileged accounts within 30 days is more meaningful than a vague claim that the program is secure. Cost justification should also include avoided downtime, reduced audit preparation work, and lower likelihood that an old account contributes to a reportable event. Utilities should not purchase an expensive platform simply to satisfy a trend; they should first determine the highest-risk connection and the minimum control needed to govern it.

## The Recommended 2026 Position

The strongest approach is a named, time-limited, monitored, and segmented vendor-access program backed by a current register and accountable utility owner. In practice, start by eliminating direct internet exposure of PLCs and other controllers, require MFA for remote access, disable shared accounts, and create an emergency path that does not depend on an undocumented permanent tunnel. Give each vendor person only the permissions needed for the named task, and make approvals expire automatically. Record administrative sessions where feasible, protect logs from alteration, and retain evidence long enough for an investigation. Review privileged accounts every 30 days and ordinary vendor accounts at least quarterly, with immediate removal when employment or contracts end.

This position is neither “lock vendors out” nor “give vendors unrestricted access.” It recognizes that qualified vendors can be necessary for safe, efficient maintenance, especially when a small utility has limited internal engineering capacity. It also recognizes that the vendor is part of the utility’s attack surface. As of September 27, 2026, utilities should assume that remote support, cloud administration, and supply-chain compromise will remain active concerns, while avoiding claims that one product or one federal document guarantees compliance. The practical standard is evidence: a reviewer should be able to identify the person, purpose, approval, systems, session, files or commands, expiration, and closure of every material vendor connection. That standard is achievable for a small utility and scales better than informal trust.

## Quick answers

### What is the safest way to give a utility vendor remote access?

Use a named user account, multifactor authentication, least-privilege permissions, an approved connection window, and a monitored path to only the required system. A utility-managed jump host or zero-trust proxy can reduce direct exposure, while privileged session recording improves accountability. Avoid permanent shared accounts and direct internet access to PLCs.

### How often should utility vendor accounts be reviewed?

Review privileged accounts at least every 30 days and ordinary accounts quarterly, or according to the utility’s risk and regulatory requirements. Disable or remove accounts after a contract or employment ends, and investigate any account inactive for 90 days or more. Thirty-, 90-, and 180-day periods are practical governance defaults rather than universal legal deadlines.

### Does multifactor authentication make vendor remote access safe?

No. MFA reduces credential theft risk, but it does not prevent misuse by an authorized user, excessive permissions, unsafe network paths, or unlogged changes. It should be combined with time limits, approval workflows, segmentation, session monitoring, and a tested account-removal process.

### Should small utilities allow vendors to connect directly to PLCs?

They generally should avoid direct internet exposure of PLCs and other controllers. When maintenance requires access, use a controlled intermediary such as a segmented jump host or approved remote-support platform with MFA, limited permissions, and logging. Compatibility and safe-operation testing are important because some legacy industrial devices cannot support modern security agents.

### What should a utility do after discovering an unknown vendor account?

Disable it after preserving necessary evidence, identify its owner and activity, review connected systems, and determine whether credentials or configurations were changed. Reset related secrets, review logs, notify the responsible manager, and document the incident or near miss. Immediate containment should not wait for a complete investigation.

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