Direct Answer: Build Controlled, Auditable Remote Access
Utilities should secure operational technology remote access by moving it away from shared passwords, unrestricted VPNs, and permanently assigned administrator accounts. The strongest practical model combines identity verification, multifactor authentication, just-in-time access, least privilege, approved endpoints, session recording, and rapid revocation. Access should connect to a specific asset for a defined maintenance or incident-response task, then expire automatically. A remote utility OT security platform can coordinate these controls, but software alone cannot compensate for poor asset inventories, unsupported equipment, unpatched Windows systems, or contractors who use unmanaged devices. CISA and the FBI have warned critical infrastructure operators about third-party risks, while reported attacks against water utilities show that remote-access paths remain an active concern.
Also worth reading: How Do Virtual Utilities Vendor Operations Software Platforms Work in 2026? · How do startups manage vendor operations for scaling facilities and workplace teams without burning cash or losing control? · How Should a Business Secure Contractor Access to Systems, Data, Facilities, and AI Agents in 2026?
The operating objective is not to eliminate remote work. Water, power, wastewater, and facilities teams often need vendors to diagnose equipment after hours, troubleshoot failed alarms, update firmware, or support compliance evidence without dispatching a technician. The objective is to make every remote session attributable, limited, visible, and reversible. For most organizations, a reasonable initial target is that 100% of privileged OT sessions use individual identities, multifactor authentication, and logging; 95% or more of sessions should be time-bound; and no vendor should retain standing administrative access between active work orders. These are governance targets rather than universal regulatory requirements, and they should be adjusted for a utility’s risk, staffing, and applicable rules.
How Remote OT Access Creates Risk
OT environments differ from conventional enterprise networks because an account may control pumps, valves, chemical dosing, switchgear, building systems, or supervisory software. A mistaken command or compromised credential can therefore have physical, environmental, or public-health consequences. NIST and other security authorities have specifically recommended stronger controls for remote-access tools used by water utilities, including stronger authentication, restricted connections, continuous monitoring, and removal of unnecessary pathways. The problem is amplified because operational components may have been designed before modern requirements such as internet exposure, encryption, account lockout, logging, and timely patching were routine.
Remote access also creates an indirect dependency on contractors and technology providers. A vendor laptop can become the path into a utility network, and a shared engineering-services account can conceal who performed an action. Recent reporting on foreign targeting of Colorado water utilities, Minnesota utility targeting, and attacks involving water-sector OT illustrates why utilities should treat vendor connectivity as part of operational risk rather than merely an IT convenience. None of these reports should be interpreted as proof that every remote-access deployment is unsafe. They do show that exposed credentials, weak segmentation, and third-party relationships can materially increase the attack surface.
Controls must account for older systems that cannot support modern authentication agents or endpoint security. A utility should not install an intrusive agent on a fragile controller merely to satisfy a corporate standard. Instead, it can place modern controls in a jump server, application proxy, firewall, or virtual private network concentrator located outside the OT zone. Security teams should also recognize the limitation of a VPN: it may encrypt traffic and authenticate a user, but it does not automatically determine whether that user should reach a particular controller or command.
A Practical OT Remote-Access Workflow
A workable workflow begins with a named user, an approved work order or incident ticket, a specific target, and a time window. The supervisor or asset owner approves the request, while the security system verifies identity through multifactor authentication and checks the device’s health. Access brokers can then open a connection to the required system without exposing a broad OT subnet. The session should begin with a recording and command-logging policy that is technically compatible with the equipment, and it should terminate when the approved window closes. Emergency access can be faster, but it should still use named identities, separate approval, and retrospective review.
For routine vendor maintenance, use a brokered connection rather than a persistent site-to-site tunnel. Least privilege means separating read-only observation from commands that change process state, and it may also mean separating engineering workstation access from historian or building-management access. A vendor troubleshooting a variable-frequency drive should not automatically receive access to the entire supervisory network. Where legacy protocols prevent strong separation, compensating controls can include application allowlists, protocol filters, rules based on source and destination, restricted maintenance accounts, and supervised local access during the session.
A defensible implementation sequence begins with inventorying remote users, vendor accounts, shared credentials, VPN profiles, dial-up lines, cloud tunnels, and maintenance tools. The second step is removing dormant accounts and disabling unused pathways. The third is requiring individual identities and multifactor authentication, followed by introducing just-in-time elevation and session review. Utilities should test the process with one noncritical system before expanding to treatment plants or remote stations. The program should be reassessed at least annually and after major architecture changes, while high-risk access should be reviewed quarterly.
Technical Controls That Matter Most
Identity is the control point. Each person should have a unique account, and privileged accounts should not be shared even when an organization calls them “temporary.” Multifactor authentication should use phishing-resistant methods for administrators where feasible, such as FIDO2 security keys or certificate-based authentication, rather than relying only on SMS or push approvals. Privileged access should be time-bound, approved for one task, and automatically disabled after use. Local emergency accounts should exist where necessary, but their passwords should be sealed in a controlled system and checked regularly.
Network restrictions determine what an authenticated user can reach. A remote-access service should terminate outside the OT security zone, authenticate every connection, and broker only approved routes to named assets. Firewalls can limit source addresses, destination addresses, ports, and protocols, while application gateways can narrow access further. Remote-access clients should be encrypted, supported, patched, and prevented from splitting traffic into alternate routes. A managed laptop that is encrypted at rest still needs endpoint protection, screen-lock enforcement, application restrictions, and a process for reporting loss or compromise.
Visibility and response complete the model. Logs should capture identity, source device, target asset, authentication method, approval, start and end time, and administrative actions. SIEM or security operations teams should alert on repeated failures, access from unusual locations, use of emergency accounts, changes to access policies, and attempts to reach prohibited addresses. OT protocols may not provide detailed user-level command logs, so teams should record at the jump host and, where practical, capture traffic with tools tested to avoid unacceptable load. The central risk is creating logging that consumes too much storage or interferes with operations; sampling and retention schedules should be designed with engineers rather than applied blindly.
Comparison of Remote-Access Approaches
| Feature | Brokered just-in-time access | Traditional persistent VPN | Direct vendor access |
|---|---|---|---|
| Authentication | Individual identity, MFA, approval, and time limit | Often individual or shared authentication | May rely on shared credentials |
| Network reach | Route to a specific approved asset | Broad route to an entire subnet | Direct or loosely filtered connectivity |
| Privilege | Temporary role or target-specific permission | Often broad standing privilege | Difficult to constrain consistently |
| Visibility | Session recording, command logs, and audit trail | Connection logs, but often limited command detail | Depends on local system logs |
| Revocation | Automatic at session or window expiry | Manual unless separately designed | May require local cleanup |
| Operational fit | Strong for routine vendor and support work | Useful for controlled broad access | Appropriate only for exceptional legacy cases |
| Main weakness | More workflow and legacy integration effort | Excessive reach and persistent exposure | Weak attribution and uncertain lifecycle |
Common Mistakes That Leave Utilities Exposed
One common mistake is treating a VPN as the entire security program. Encryption in transit protects data from interception, but it does not stop a valid user from reaching systems they should not operate. Another mistake is allowing vendors to use shared accounts because technicians say it is faster. Shared credentials defeat attribution, complicate revocation, and make it impossible to determine whether a harmful action came from an employee, a contractor, or an intruder using a stolen password. Utilities should also avoid allowing contractors to install personal remote-access software, retain default passwords, or use local administrator accounts without a documented exception process.
The second category of mistakes involves indiscriminate patching. OT components may be old, vendor-supported, or unable to tolerate a standard endpoint agent. Delaying every security update is not a sufficient strategy, but forcing intrusive tools onto fragile equipment can cause downtime. Risk-based maintenance windows, virtual patching, compensating controls, and documented end-of-life decisions are more credible than a policy that says “secure everything immediately.” A 2026 utility should know which devices cannot be patched, who is accountable for compensating measures, and when replacement funding is required.
A third error is assuming the cloud is inherently safe. Remote workers and vendors may be valuable, but cloud administration accounts, file shares, and collaboration tools can become bridges into operational systems. Cloud access should be separated from OT administration, protected by strong identity controls, and monitored for privilege changes. A useful acceptance test is whether the utility can answer, within minutes, who accessed a specific controller yesterday, why access was approved, which commands were issued, and how the connection was revoked.
When to Act and How to Prioritize
A utility should act immediately when remote access is internet-exposed, uses shared administrator credentials, has no session logs, or can remain open after a contractor leaves. The first 30-day period should focus on inventory, account ownership, access review, MFA for privileged users, and removal of unknown accounts. The next 60 to 90 days can introduce target-specific gateways, time-bound permissions, and centralized logs. By roughly six months, a mature program should test emergency access, incorporate vendor contracts, measure access volume, and verify that accounts are removed promptly when personnel or projects end.
Prioritization should follow consequence and exposure, not simply product visibility. A remote connection to a chemical dosing system or pressure-control device deserves faster review than a read-only connection to a facilities dashboard, although both may require controls. Internet-reachable remote desktop software, dormant accounts, and shared engineering workstations should be treated as high priority because they combine access with weak accountability. Smaller utilities may lack a dedicated OT security team, so managed service providers can help with monitoring, policy design, and response, but responsibility for approving access should remain with the utility.
Regulatory obligations vary by jurisdiction, system, and organization. Water utilities may face federal requirements, state cybersecurity requirements, sector standards, grant conditions, and obligations arising from drinking-water or environmental programs. Security teams should consult qualified legal and compliance personnel rather than treating a general framework as a complete legal determination. Even where remote access is not explicitly named, least privilege, access accountability, incident response, and third-party governance are defensible control objectives supported by guidance from NIST and CISA.
Cost, Vendor Selection, and Expected Outcomes
Cost depends heavily on whether a utility is buying software, managed access infrastructure, engineering services, or a full program. A small deployment using a hardened gateway, MFA, a password vault, and internal staff effort may cost tens of thousands of dollars, while enterprise brokered-access platforms, integration, continuous monitoring, and OT engineering can run into six figures. Managed detection and response or identity services add recurring fees. These are planning ranges, not universal price quotes; legacy equipment, site count, protocol compatibility, and staffing determine the final budget.
When evaluating vendors, ask for OT-specific evidence rather than accepting generic IT security language. Questions should cover protocol compatibility, support for isolated networks, local authentication during outages, time-bound elevation, session recording, audit exports, vendor offboarding, and behavior during loss of internet connectivity. A contract should state who operates the gateway, where logs are stored, how incidents are escalated, and whether the utility can retrieve its records. Support must include documented recovery procedures because a security control that cannot be restored after a failure can become an operational liability.
A platform such as vuti.app can be evaluated as part of this workflow for facilities and workplace teams that need vendor access to be approved, recorded, and revoked, but buyers should avoid selecting a product solely on a remote-control feature or a low per-user price. The product should be tested against the utility’s actual systems and operating model. Success is measured by fewer standing accounts, shorter approval times, complete session records, faster offboarding, and fewer unmanaged pathways. Those operational outcomes are more meaningful than the number of features displayed on a procurement checklist.