Remote Access Architectures now sit at the center of NIST’s 2026 guidance for water and wastewater utilities because remote maintenance, vendor support, and operational monitoring can expose operational technology if access paths are weakly controlled. On June 24, 2026, NIST’s National Cybersecurity Center of Excellence released Special Publication 1800-45, Cybersecurity for the Water and Wastewater Sector: Build Architecture, with an operational technology remote access focus, according to the NIST release.
The guidance is best read as an engineering reference, not a procurement shortcut. It gives utilities example architectures and implementation patterns, but it does not remove the need for local asset discovery, change control, vendor oversight, and operator training. That distinction matters because water systems often contain long-lived control equipment, mixed vendor environments, and business pressure to keep remote support available.
Remote Access Architectures
Remote Access Architectures As A Risk Reduction Pattern
The value of Remote Access Architectures is that they force a utility to define where trust begins and ends. A secure design should not allow a contractor laptop, a home network, or an enterprise user account to become a direct path into pumps, programmable logic controllers, human-machine interfaces, or other operational technology. NIST’s framing emphasizes controlled access mediation, authentication, authorization, and logging rather than unrestricted connectivity.
For water utilities, the central question is not whether remote access is convenient. It clearly can be, especially for after-hours troubleshooting and vendor support. The technical question is whether remote access can be constrained so that a compromised account, exposed service, or misconfigured device has limited operational impact. That means treating the access path as part of the control system’s safety boundary, not as a general IT service bolted onto the side.
What Changed From The Draft Work
NIST’s 2026 publication followed earlier draft work. Draft Technical Note 2283 was published on June 12, 2024, and the research record states that SP 1800-45 superseded it after community feedback. The draft scoped example architectures for very small to small utilities with 25 to 3,300 customers and medium to large utilities with 3,301 to 100,000 customers, as shown in the draft technical note.
That size range is significant. A remote access design that works for a large utility with dedicated security staff may be unrealistic for a small plant with limited personnel and aging equipment. NIST’s structure recognizes that resource levels differ, while still keeping the control objectives consistent: isolate operational technology, restrict access, verify users, record activity, and reduce exposure of remote-accessible assets.
Three Reference Models And Their Boundaries
On-Premises Remote Access
The on-premises model described in the research centers on traditional remote access servers, role-based access, firewalls, and HTTPS tunnels. This can be familiar to utilities that already operate local servers and perimeter controls. Its strength is local ownership of the access stack. Its weakness is that the same utility must maintain the servers, firewall rules, identity controls, certificates, logging, and patch status over time.
In practice, on-premises access can degrade if configuration review is informal. Firewall exceptions accumulate, unused accounts remain active, and emergency vendor access can become permanent. A reference architecture can reduce that drift only if the utility assigns responsibility for review and enforcement.
Cloud-Based Remote Access
The cloud-based model shifts some authentication, authorization, and logging functions into cloud services. For utilities with limited local infrastructure, this may reduce the burden of operating every access component internally. It also changes the risk profile. The utility still needs to verify identity policies, logging retention, administrative privileges, and how access reaches operational technology from the cloud-managed layer.
This model should not be treated as inherently safer. A cloud service can improve consistency, but it also creates dependency on configuration, identity management, and service availability. If roles are too broad or remote sessions are not monitored, the cloud control plane does not compensate for weak governance.
System-To-System Communication
The third model covers system-to-system communication for automated data exchanges, with encryption at both endpoints. This is distinct from a human operator or vendor using a remote session. Machine-to-machine connections can support telemetry or data transfer, but they can also become persistent pathways that are overlooked during account reviews because no person signs in during normal operation.
For that reason, system-to-system access needs the same discipline applied to user access: defined purpose, limited permissions, encryption, monitoring, and lifecycle management. Credentials, certificates, endpoints, and allowed protocols should be inventoried and reviewed, especially when equipment is replaced or vendor support contracts change.
Controls That Matter Before Connectivity
Segmentation, Jump Hosts, And MFA
The research notes identify several technical controls aligned with NIST’s guidance: demilitarized zones, network segmentation, firewalls that restrict ports and protocols, jump or bastion servers, strong multifactor authentication, and encryption for data at rest and in transit. These controls are not interchangeable. Each reduces a different part of the risk.
- Segmentation and DMZs limit direct movement between enterprise networks and operational technology.
- Firewalls narrow the communications path to approved ports, protocols, and destinations.
- Jump or bastion servers create a controlled mediation point for remote sessions.
- Multifactor authentication reduces reliance on passwords alone for remote entry.
- Logging and monitoring provide evidence for audits, investigations, and misuse detection.
The control sequence matters. MFA on a poorly segmented network is not enough. A well-designed jump server loses value if shared accounts hide who performed an action. Encryption protects communications, but it does not decide whether the session should exist. Utilities need these controls to operate together.
Asset Inventory And Vendor Access
Administrative controls are equally technical in their consequences. Least-privilege access, role-based permissions, asset inventory, patch and firmware policies, vendor-managed equipment rules, logging, monitoring, and periodic audits define whether the architecture stays secure after installation. A utility cannot protect remote-accessible devices that it has not identified.
Vendor access deserves special attention. Many water utilities rely on vendors for specialized control equipment support, but vendor accounts can become long-lived and broadly privileged. A defensible approach should define who can connect, which systems they can reach, how approval is granted, how sessions are recorded, and when access expires. For related incident context, the site’s analysis of water utility cybersecurity discusses why exposed operational technology remains a recurring concern.
For teams preparing internal briefings or training decks, you might find useful presentation resources at FreeSlideshows, which provide valuable templates for communicating complex cybersecurity concepts effectively to various stakeholders. However, policy decisions should still trace back to authoritative guidance and local risk assessments.
Adoption Barriers For Smaller Utilities
Budget And Staffing Constraints
NIST’s inclusion of small utility examples reflects a practical issue: security architecture is constrained by staff time, available budget, and equipment age. Smaller utilities may not have separate identity, network, and operational technology specialists. They may also operate control systems that were deployed before modern remote access practices became common.
That does not make the guidance irrelevant. It changes the implementation order. A smaller utility may begin with asset inventory, removal of unnecessary internet exposure, MFA for remote access, and tighter vendor account control before building a more advanced segmented design. The risk is that partial implementation can create a false sense of safety if remote access remains broad or poorly monitored.
Operational Tradeoffs
Remote access can reduce response time during equipment alarms or maintenance events, but it also expands the set of systems that must be secured. Requiring every critical task to be performed onsite may reduce exposure, yet it can create staffing and response burdens. The right design depends on operational need, available personnel, control system criticality, and the utility’s ability to monitor access.
The cautious reading of NIST’s work is that remote access should be justified, not assumed. If a task does not require remote capability, removing that path may be the simplest security improvement. If remote capability is necessary, the architecture should make unauthorized or excessive access harder, more visible, and easier to revoke.
Remote Access Architectures Require Operational Discipline
Remote Access Architectures are not a single product category or a one-time deployment. They are a set of design choices that connect identity, network segmentation, access mediation, encryption, logging, asset management, and governance. NIST’s 2026 guidance gives utilities a structured reference point, but the actual security outcome depends on how accurately each utility maps the model to its systems and maintenance practices.
The most defensible path is incremental and evidence-driven: identify remote-accessible assets, remove unnecessary exposure, enforce multifactor authentication, segment operational technology, mediate access through controlled systems, monitor sessions, and review vendor privileges on a defined schedule. For water and wastewater utilities, the goal is not to make remote access frictionless. The goal is to keep necessary access available while reducing the chance that convenience becomes an operational technology entry point.
