TL;DR: Water utilities face elevated cyber risk because remote vendor access, default credentials, shared accounts, and limited centralised control still create easy paths into operational technology, according to StrongDM’s discussion of the NIST NCCoE water and wastewater reference design. The governance problem is not connectivity itself but whether access can be bounded, monitored, and revoked without weakening operations.
At a glance
What this is: This is a security analysis of water and wastewater OT access, showing that vendor remote access and default credentials remain the most exposed control points.
Why it matters: It matters to IAM practitioners because the same access patterns that weaken OT environments also affect NHI governance, third-party access, and privileged session control across broader identity programmes.
By the numbers:
- Only 5.7% of organisations have full visibility into their service accounts.
- 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface.
👉 Read StrongDM’s guide to water utility cybersecurity and OT vendor access
Context
Water utility cybersecurity is fundamentally an access problem. When vendors maintain remote entry into operational technology, the environment inherits the same trust, credential, and oversight risks seen in other high-value identity systems. The first question is not whether access exists, but whether it is tightly governed end to end.
The primary failure mode is familiar to IAM teams: shared credentials, default accounts, and over-provisioned remote paths create standing access that is difficult to audit or revoke. In critical infrastructure, that weakness becomes an operational resilience issue as well as an identity issue, which is why the water sector is now being treated as a control-design problem rather than only a network-security problem.
Key questions
Q: How should security teams control vendor access in water utility OT environments?
A: Treat vendor access as privileged identity governance, not as a convenience layer. Every remote path should have a named owner, a scoped purpose, session logging, and a revocation trigger. If access cannot be attributed and reviewed, it should not reach OT assets.
Q: Why do default credentials remain dangerous in operational technology?
A: Default credentials are dangerous because they often survive device deployment, are reused across fleets, and create a predictable foothold for attackers. In OT, that foothold can persist far longer than in IT because devices are harder to reimage, patch, or replace.
Q: How do you know whether privileged remote access is actually under control?
A: Look for unique identities, session-level logging, clear approval boundaries, and a documented revocation process. If operators or vendors can connect without attribution or if access persists after the task ends, control is only partial.
Q: Who is accountable when vendor access causes a breach in critical infrastructure?
A: Accountability sits with the utility, the supplier, and the control owners who approved the access model. Frameworks such as NIST CSF and NIST’s water-sector reference design expect traceable governance, not informal trust in support relationships.
Technical breakdown
Remote vendor access in OT environments
Operational technology environments often rely on external vendors for maintenance, patching, and support. That support frequently arrives through VPNs, jump hosts, or other mediated remote pathways that become persistent trust channels if they are not bounded by strong identity controls. The real risk is not remote access itself, but remote access that is indistinguishable from routine internal privilege and therefore hard to govern at session level. In water utilities, that creates an identity perimeter that extends beyond the organisation’s direct control.
Practical implication: treat every vendor remote path as a privileged access pathway that requires explicit session governance and recorded accountability.
Default credentials and shared accounts
Default credentials remain a structural weakness because they turn device access into a reusable secret rather than a governed identity. Shared accounts add another layer of ambiguity by breaking attribution, which makes it difficult to know who performed an action, when, and under what approval. In OT, where devices can be difficult to patch or replace, that combination can persist for years. The governance gap is not just weak authentication, but weak identity ownership across the device lifecycle.
Practical implication: eliminate shared and default accounts from OT support flows and tie every privileged action to a unique, reviewable identity.
Continuous privileged session control and logging
The article’s strongest control theme is that access should be governed during the session, not only at login. Continuous, actions-based risk assessment means evaluating commands, context, and session behaviour as access unfolds, then enforcing policy in real time. That model is especially relevant in critical infrastructure because initial authentication alone does not tell you whether an operator or vendor is behaving within scope. Centralised logging then becomes the evidence layer for investigation, compliance, and incident reconstruction.
Practical implication: use session-level policy enforcement and centralised logs to detect drift, constrain misuse, and support forensic review.
Breaches seen in the wild
- MongoBleed breach — MongoBleed exposed secrets across 87K MongoDB servers.
- IOS app secrets leakage report — iOS apps leaking hardcoded secrets and credentials endangering user privacy.
Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Water utility security is an identity governance problem before it is an OT problem. The article describes remote vendor access, default credentials, and shared administrative paths, all of which are identity control failures expressed in industrial systems. That means water-sector resilience depends on who can act, under what identity, and with what auditability. Practitioners should treat OT access as privileged identity infrastructure, not as a separate network exception.
Standing vendor access is the hidden failure mode this article exposes. The governance assumption behind traditional remote support is that access can remain available because operators will use it responsibly. In practice, standing access persists beyond the narrow task that justified it, which broadens exposure and weakens accountability. The implication is that water utilities need to re-evaluate how they define necessity, not just how they authenticate support staff.
Centralised control matters because distributed exceptions make compliance unverifiable. When every site, device class, or vendor relationship creates its own access pattern, the organisation loses a single source of truth for privilege and session evidence. That problem is amplified in regulated critical infrastructure, where demonstrable control matters as much as control intent. The practitioner takeaway is that access governance must be standardised across plants, vendors, and device families.
Identity blast radius: Remote access in critical infrastructure expands quickly when one credential can reach many operational assets. That is the real structural risk in vendor-supported OT environments, because the same secret can become both a maintenance enabler and an incident multiplier. Once access is over-broad, the response problem is no longer containment alone but limiting the number of systems reachable through any single identity. Practitioners should map and shrink that blast radius before an incident forces the issue.
Water-sector access controls now sit at the intersection of critical infrastructure and NHI governance. The article’s NIST framing shows that this is not a niche plant-floor issue. It is part of the broader shift toward treating every non-human or third-party credential as a governed identity with lifecycle, monitoring, and revocation requirements. Security teams should align OT support access with the same lifecycle discipline used for NHIs and privileged service accounts.
From our research:
- Only 5.7% of organisations have full visibility into their service accounts, according to Ultimate Guide to NHIs.
- 79% of organisations have experienced secrets leaks, with 77% of these incidents resulting in tangible damage.
- Water-sector vendors should also read Ultimate Guide to NHIs , Key Challenges and Risks for the broader visibility and rotation pattern behind these failures.
What this signals
Identity blast radius: Water utilities and their suppliers should assume that every remote support path can become a high-impact identity corridor if it is not explicitly bounded. The practical shift is toward measuring reach, revocation, and auditability rather than just authentication success. For the broader control model, see NIST Cybersecurity Framework 2.0 and the NIST water-sector reference design.
Third-party access in critical infrastructure is now a governance issue, not a niche operational exception. The more support work is routed through reusable credentials or uncoupled vendor accounts, the more the organisation loses visibility into who can act on its behalf. That makes lifecycle control, logging, and offboarding the deciding factors in resilience, not optional hygiene.
The strongest programmes will standardise OT support access the same way they standardise service-account governance in IT. That means one identity per actor, narrow privilege, and a revocation path that is tested before an outage proves the gap. The same discipline that limits NHI sprawl also reduces the chance that one vendor relationship becomes a sector-wide exposure.
For practitioners
- Inventory all vendor remote paths Map every VPN, jump host, shared account, and support channel that reaches OT assets. Classify each path by business purpose, privileged scope, and revocation owner so no access route remains undocumented.
- Remove default and shared OT credentials Replace default credentials and shared support accounts with individually attributable identities and per-session approval. Where device constraints block immediate replacement, isolate the asset and track compensating controls until the credential model is retired.
- Enforce session-level policy for privileged support Apply real-time command and context checks during the session, not only at login. Log actions centrally, alert on scope drift, and require explicit justification for any elevated support activity.
- Tie offboarding to vendor relationship changes When a supplier contract ends, changes scope, or loses a maintenance role, revoke every associated credential and access route. Verify the revocation against plant inventories and support runbooks before closing the record.
Key takeaways
- Water utility OT risk is driven by identity weakness, especially vendor access, default credentials, and shared support paths.
- The scale of the governance gap is visible in low service-account visibility and persistent secrets exposure across enterprises.
- Utilities should move to attributable, session-governed, revocable access before support relationships become incident paths.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AC-4 | The article centres on controlled remote access and privilege boundaries in OT. |
| NIST Zero Trust (SP 800-207) | Remote access into critical infrastructure needs continuous verification, not trust by location. | |
| OWASP Non-Human Identity Top 10 | NHI-03 | Default and shared credentials in OT are a classic non-human identity lifecycle failure. |
Apply zero-trust principles to support paths and verify every privileged action during the session.
Key terms
- Operational Technology Access: Operational technology access is the path used to reach systems that run physical processes, such as pumps, valves, and control platforms. In security practice, it must be treated as privileged access because misuse can affect safety, uptime, and public services, not just data confidentiality.
- Standing Access: Standing access is privilege that remains available outside a specific task or approval window. In OT and NHI governance, it creates durable exposure because the identity can be reused long after the original maintenance need has passed, weakening accountability and increasing the attack surface.
- Session-level Enforcement: Session-level enforcement is the practice of evaluating and constraining actions while access is active, not only at login. It matters for privileged and remote support work because authentication alone does not prove the operator is still acting within approved scope or intent.
- Identity Blast Radius: Identity blast radius is the amount of systems, data, or operational capability reachable through one credential or account. The larger the blast radius, the more a single compromise, misuse event, or offboarding failure can affect an organisation's security and resilience.
Deepen your knowledge
Water utility vendor access governance is covered in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are aligning OT support access with identity controls, it is a practical place to start.
This post draws on content published by StrongDM: Water Utilities Cybersecurity Guide: Challenges & Solution. Read the original.
Published by the NHIMG editorial team on 2025-06-25.
NHI Mgmt Group — the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org