NIST's water-sector remote-access builds are reference designs—not production authorization

Treat the practice guide as a design input

SP 1800-45 is a practice-guide record for a specific sector and use case: remote access to operational technology in water and wastewater systems. NIST describes a build architecture and three reference designs demonstrated with commercially available technology. That gives owners a concrete source for architecture review, but the maintained object is still a reference design—not the topology, assets, process consequences, staffing, contracts, or authority record of a particular utility.

A useful local assessment begins by naming the business and operational purpose for remote access, the exact assets and functions in scope, the people and organizations that require access, the approved times and conditions, and the physical consequence of an erroneous or unavailable action. The NIST pattern can inform those questions. It cannot supply the missing site facts or make the utility's risk decision.

Separate laboratory demonstration from production evidence

NIST says the sample implementations were built and demonstrated in a lab environment. Laboratory evidence is valuable because the components, flows, and assumptions can be inspected without exposing a live process. It does not establish that the same products, versions, identities, configurations, network conditions, safety dependencies, maintenance practices, or failure responses exist at a production site.

Production acceptance therefore needs its own governed evidence. That record should include authorized architecture, asset inventory, data flows, access roles, identity lifecycle, session conditions, monitoring, change approval, vendor responsibilities, tested failure states, recovery, safety review, and retained logs. This article does not prescribe configurations or testing steps for a live control system; qualified utility, engineering, safety, and cybersecurity owners must define and authorize them.

Keep the access decision tied to an accountable session

A remote-access capability should not collapse every vendor, employee, device, and task into one approved path. Teams need to connect each session to a named identity, sponsoring owner, requested purpose, target asset, allowed action, approved window, authentication result, access decision, observed activity, termination, exception, and follow-up. Standing connectivity and emergency access need separately governed records.

The same discipline applies to operational constraints. Connectivity may support troubleshooting, monitoring, maintenance, or other authorized work, but each function can have different read, write, command, file-transfer, latency, availability, and safety implications. A successful login does not prove that the requested action was authorized, safely executed, fully monitored, or reversed when the session ended.

Evaluate the full operating system around the design

Technology components are only one part of remote-access control. Utilities also depend on inventory quality, network ownership, vendor contracts, personnel changes, credential issuance and revocation, maintenance windows, incident response, communications, backup and recovery, and safe operating procedures. A reference architecture should be evaluated with those surrounding controls rather than treated as a product shopping list.

OT Defense Review treats the official NIST publication page as primary evidence for the guide's date, water-sector scope, three reference designs, secure remote-access purpose, and use of commercial technologies. It does not infer independent product performance, a certification, regulatory compliance, site safety, control effectiveness, or production readiness. Those claims require exact local evidence and accountable authorization.

Enterprise buyer test

Translate this change into the exact population, record type, workflow stage, decision owner, effective date, and evidence that could be affected. Ask current or prospective providers to demonstrate the named workflow with representative data and an exception—not a polished feature tour. Record what official documentation establishes, what a provider states, what the team observes, and what remains unresolved.

A defensible review also identifies the dependency outside the product. Authority interpretation, policy configuration, data quality, integrations, human judgment, approval rights, release governance, training, and retained evidence may remain customer or service responsibilities. The evaluation should preserve those boundaries instead of treating a technology claim as the complete operating model.

What we will watch next

OT Defense Review will watch the named source and affected market records for later evidence that changes status, scope, availability, implementation timing, workflow consequence, or the limits of the initial report. A later announcement does not silently overwrite this dated account; the change ledger preserves the sequence.