How Should Utility Vendors Manage Remote Access Controls in 2026?

What Are Utility Vendor Access Controls?

Utility vendor access controls are the technical and administrative rules that determine which employees, contractors, consultants, and software services can connect to utility networks, operational technology, control systems, remote-support tools, or associated data. They commonly combine identity verification, multifactor authentication, conditional access, least-privilege permissions, time-limited credentials, session approval, activity logging, network segmentation, and documented access reviews. The objective is not simply to stop every remote user; it is to ensure that legitimate access is attributable, temporary where possible, limited to the required systems, and reviewed continuously.

Also worth reading: What Are Multi-Site Utility Billing Controls for Distributed Portfolios in 2026? · How Should Organizations Govern Virtual Utility Vendors and Vendor Operations? · How Should Organizations Manage Third-Party Compliance Controls Without Slowing Procurement?

This matters because remote access creates a direct path between a vendor and operational infrastructure. A water utility may expose a supervisory control and data acquisition system, programmable logic controller, historian, building-management platform, or remote terminal interface. Electric utilities face additional reliability and regulatory concerns, while workplace and facilities teams may manage vendors with access to electrical rooms, mechanical systems, access-control platforms, or energy-management software. If credentials are shared, permanently assigned, or connected to unrestricted remote-management software, a vendor account can become an attack path even when the utility itself has a capable security team.

Controls should therefore be designed around the identity, device, task, location, and risk—not just the vendor’s company name. A laptop used for ordinary office work should not automatically receive the same trust as a dedicated maintenance tablet. A vendor supporting a pump controller may need access to one approved subnet for two hours, not a permanent network-wide role. A useful access-control system makes that narrow connection possible and records who requested it, who approved it, what occurred, and when it expired.

Why Remote Vendor Access Is a Growing Risk

Attackers increasingly target identities and remote-management services because they can be less visible than attempts to penetrate a protected control environment. Exposed internet-accessible interfaces, stolen passwords, compromised vendor devices, and unmanaged support software may provide a route into systems that are otherwise segmented. Research focused on small U.S. water and electric utilities has highlighted exposed PLCs and remote-access weaknesses, while NERC-related compliance discussions have placed renewed attention on vendor remote access. The exact obligations depend on the utility’s size, market participation, system classification, jurisdiction, and applicable contracts.

The risk is not identical across the sector. A small water district using commercially hosted metering and billing services may have fewer direct operational systems than an investor-owned electric utility, but it may also have fewer dedicated cybersecurity resources. A facilities vendor connecting to a building automation system might present less immediate bulk-power-system risk, yet the device could still control HVAC, access doors, cameras, or electrical equipment. Conversely, a remote-support connection to a substation or generation facility can carry consequences extending beyond the individual utility.

Regulatory references should be interpreted carefully. NIST cybersecurity publications provide a widely used framework for identifying, protecting, detecting, responding to, and recovering from incidents. NERC CIP requirements apply to responsible entities and applicable bulk electric system assets, but a requirement should not be assumed to apply automatically to every municipal water utility or facilities SaaS customer. DORA applies primarily to the European Union financial sector and is not a general utility-vendor mandate. Organizations should work with their compliance, legal, and security advisers to map specific systems to applicable obligations rather than treating a framework name as a substitute for a risk assessment.

How Effective Utility Vendor Access Controls Work

A mature control model begins with an inventory of every vendor connection, integration, account, supported device, and privileged pathway. The inventory should distinguish remote desktop tools, vendor-hosted cloud services, application programming interfaces, cellular or serial gateways, shared remote-support accounts, and physical keys. Each entry needs an owner, business purpose, permitted system, authentication method, expiration date, and review cadence. If the organization cannot state who has access to what and why, it cannot reliably remove that access when a project ends.

Identity controls should be centralized where feasible. Individual accounts are preferable to shared accounts because they create attributable activity and permit immediate suspension. Privileged access should be role-based and limited to the functions required for the assignment. Multifactor authentication is a strong baseline, but it is not enough if the underlying account remains permanently privileged. Time-bound access, approval workflows, just-in-time elevation, and monitored sessions can reduce the time available for misuse. Where a vendor cannot support modern identity controls, a mediated access gateway can provide an alternative to direct connectivity.

Technical enforcement should then constrain that identity. Network policies can limit a vendor to particular destinations and ports, while host controls can restrict which files, applications, or administrative functions are available. Dedicated gateways can broker connections, record sessions, block clipboard or file transfer features, and terminate the session at the last responsible moment. Logs should be synchronized to a protected central system, and alerts should be generated for unusual hours, repeated failures, new-device registration, privilege changes, or attempted access outside the approved asset. A control that produces logs nobody reviews is evidence generation, not effective risk reduction.

A Practical Implementation Process for Utilities and Facilities Teams

Start by identifying the systems that genuinely require vendor connectivity, especially PLCs, historians, SCADA platforms, remote terminals, building automation systems, and energy-management services. Classify each system by consequence rather than relying only on whether it is called operational technology. For one utility, loss of pump telemetry may be an inconvenience; for another, it may affect safe operation of a treatment process. A facilities organization should include any vendor pathway that can control electrical equipment, mechanical plant, doors, cameras, or life-safety-adjacent systems.

Next, establish a small set of access patterns instead of designing a custom workflow for every incident. A common pattern is a supervised temporary session: the vendor submits a request, the system owner approves it, multifactor authentication is completed, an approved device is registered, and the connection is limited to a defined target for a defined period. Another pattern is a standing read-only integration for a billing or monitoring service. Emergency access should be more restricted and more observable, not a permanently open bypass. Naming the accountable owner for each pattern makes implementation and review easier.

Organizations can phase the work. During the first 30 days, they can export account lists, identify shared credentials, close unknown remote tools, and document active vendor connections. During days 31–60, they can centralize multifactor authentication, require individual identities, and introduce approval and expiration for privileged sessions. During days 61–90, they can test gateway policies, alert routing, account termination procedures, and evidence retention. Larger utilities may need six to twelve months because asset classification, field equipment, vendor contracts, and legacy systems complicate deployment; the timeline should be driven by risk rather than an arbitrary software rollout date.

Comparing Access-Control Alternatives

There is no single product category that solves vendor access for every utility. A zero-trust access service may provide strong identity and policy controls, but it does not automatically understand the operational consequences of an industrial device. A privileged-access-management platform can record and approve administrative sessions, but it may not evaluate network paths or cover a vendor’s cloud application. A secure remote-support gateway can mediate connections, yet it still needs accurate asset inventories, disciplined approvals, and trained responders.

A managed service may be more practical for a small water district with limited staff, while a large utility may prefer to integrate enterprise identity, security operations, and incident-response systems internally. Some organizations combine all three: zero-trust for workforce identities, privileged access for administrative sessions, and a managed gateway for selected vendors. The comparison should be based on the organization’s risk, existing tools, staff, and required evidence—not on a feature count.

Common Mistakes That Leave Utilities Exposed

One common mistake is treating vendor access as an IT exception. Operational teams may approve a connection for an urgent repair while central security teams remain unaware of the remote path. Another is allowing vendors to connect directly to operational systems merely because a firewall rule was approved for a previous project. Rules tend to persist after the project ends, the device is replaced, or the responsible employee leaves. Permanent vendor accounts and shared passwords make attribution difficult and complicate termination, particularly when several technicians use the same support portal.

A second mistake is enabling remote-management features without defining when they are used. Screen sharing, file transfer, clipboard access, command-line tools, and support tunnels can be necessary for maintenance, but each capability should be considered separately. Disabling every feature may delay legitimate work and encourage users to seek less secure alternatives. The better approach is to permit a documented set of capabilities for a specific task and deny the rest by default. Access should be granted to a target system, not to an entire business network.

The third mistake is assuming that multifactor authentication completes the control. A valid second factor protects against some credential theft, but it does not prevent misuse by an authenticated insider or compromised vendor endpoint. The fourth is neglecting offboarding. At minimum, a utility should be able to remove access within one business day for a normal departure and immediately for a suspected compromise. A practical target is to review privileged vendor access monthly, high-risk standing access quarterly, and all access at least twice a year, with additional reviews after major incidents, contract changes, or system migrations. These are governance targets, not universal legal deadlines.

When to Act and What It May Cost

Immediate action is warranted when an internet-exposed control interface is discovered, a vendor uses shared credentials, an unknown remote-support account exists, or logs show access from an unapproved country or device. These situations should be placed in the incident or urgent-risk process rather than handled as routine ticket work. Organizations should preserve relevant logs and evidence, restrict the pathway, contact the vendor, and involve legal, operations, cybersecurity, and incident-response personnel as appropriate. Federal water-sector guidance has discussed the difficulty of restoring a controller while preserving evidence, so teams should not power off or reset equipment solely to make a symptom disappear before documenting the state and receiving qualified advice.

Pricing varies substantially because utility environments include legacy systems, field devices, regulatory evidence, and integration work. A small organization may spend approximately $3,000 to $15,000 per month on managed access monitoring, identity protection, logging, and support, while a larger deployment can reach six figures annually for software, gateways, engineering, and implementation. Privileged-access products may add per-user, per-session, or per-asset charges; managed services commonly add charges for enrollment, emergency support, reporting, and integrations. Budgets should include the cost of asset discovery and legacy remediation, not just licenses.

The return is difficult to express as a simple percentage, but reducing permanent privileged access and shortening unauthorized sessions lowers exposure. Measurement can include the percentage of vendor accounts using individual identities, the share of privileged sessions that expire automatically, mean time to revoke access, number of unknown remote connections, and proportion of high-risk sessions reviewed within 24 hours. Those measures are more informative than reporting the number of security tools purchased.

A Reasonable 90-Day Security Program

A utility or facilities team can begin with a defined 90-day program without pretending that every operational issue will be solved. In the first month, identify internet-facing remote-access services, shared accounts, dormant users, standing VPN profiles, and vendor devices. Confirm whether each connection can reach more systems than intended. The second month can prioritize a gateway for the most consequential systems, require individual identities and multifactor authentication, and create an approval path for emergency work. The third month can validate logging, test revocation, conduct a tabletop exercise with a vendor, and document gaps for funded follow-up.

The program should have an executive owner, an operational owner, a security owner, and a vendor-management contact. It should also define what happens when a vendor refuses to support required controls. Options include a mediated connection, a contractual security schedule, a restricted maintenance window, or termination of a pathway that presents unacceptable risk. Utility teams must balance safety and continuity: a control that prevents a qualified technician from addressing a critical fault may create its own operational problem. Emergency procedures should therefore be preapproved, short-lived, recorded, and reviewed after use.

A target state is not zero remote access. It is remote access that is justified, attributable, least-privileged, time-bounded, observable, and revocable. For most organizations, the best first investment is accurate inventory and a controlled session gateway, followed by stronger identity policy and centralized evidence. That sequence reduces the attack surface while preserving the flexibility vendors need to maintain water, electric, workplace, and facilities systems.