Restored PLC access is not restored operational trust.

Federal agencies warned in April 2026 that Iranian-affiliated actors were exploiting internet-connected programmable logic controllers across U.S. critical infrastructure, including drinking-water and wastewater systems. The public record describes interaction with PLC project files, manipulation of information shown through HMI and SCADA systems, and operational disruption at some victims. Those facts create a recovery problem that a password reset cannot solve by itself.

• Memo code: TV-AM-2026-08-01-06
• Sector: Water and Wastewater Systems / Critical Infrastructure
• Memo type: Current incident and trust-restoration analysis
• Source freeze: August 1, 2026, 11:33 PM PDT
• Incident posture: Active and evolving campaign

Holding: Restoring operator login or network connectivity after unauthorized interaction with a programmable logic controller does not establish that operational trust has been restored. Where an actor may have modified project files, reusable code, controller logic, communications settings, HMI or SCADA displays, credentials, or remote-access paths, the utility must validate the affected control environment against known-good technical and operational evidence before treating normal operation as trustworthy.

• Determination: Post-intrusion operational-trust gap demonstrated at the campaign level.
• Evidence sufficiency: Sufficient to establish an ongoing Iranian-affiliated campaign against internet-connected PLCs, interaction with PLC project files and operator-visible data, and disruption at some victims. Insufficient to treat all reported Minnesota incidents as one verified event chain.
• Severity: High.
• Confidence: High for the campaign-level finding; Medium for the Minnesota reporting layer.

Source authority: This article is a faithful public projection of the approved TensileVue memorandum. Primary government and manufacturer sources control. Secondary reporting is used only within the limits stated below.

Executive Triage

Who this is for

This memorandum is for water and wastewater utility executives, operations leaders, control-system engineers, security teams, identity and access management owners, incident responders, integrators, vendors, legal counsel, public-information staff, and government partners responsible for deciding when an affected control environment may safely return to normal operation.

What to do if this sounds like your environment

• Separate restored access from restored trust.
• Preserve controller, HMI, SCADA, network, gateway, and engineering-workstation evidence before unnecessary changes erase the incident state.
• Compare running project files, logic, reusable code, configuration, and communications settings with an approved known-good baseline.
• Validate operator-visible values against independent process indicators and field observations.
• Inventory and restrict every remote, cellular, vendor, integrator, VPN, and engineering path that can reach the affected environment.
• Use staged return-to-service criteria with named approval owners, rollback conditions, and heightened monitoring.

What to check now

• Does the running controller logic match the approved engineering copy?
• Were reusable modules, project files, device names, ports, addresses, or communications settings changed?
• Do HMI and SCADA values agree with field instruments, local indicators, manual readings, and laboratory or process evidence?
• Which credentials, service identities, vendor accounts, sessions, tokens, and remote-support paths may have been exposed?
• Were engineering workstations, project repositories, jump hosts, gateways, historians, and remote-support tools reviewed?
• What remains manual, isolated, degraded, under investigation, or accepted as residual risk?

What appears to have gone wrong

The federal record establishes an ongoing campaign against internet-connected PLCs, interaction with PLC project files and operator-visible data, and disruption at some organizations. It does not establish one uniform initial-access path, one affected device model, or one technical effect across every victim. The public evidence also does not support a claim that water contamination occurred or that a specific product vulnerability was exploited in every case.

Who to involve internally

Operations, control engineering, security operations, incident response, identity and access management, network engineering, physical-process owners, safety, laboratory or quality functions, vendor management, procurement, legal, communications, continuity planning, and executive risk owners should participate in the restoration decision.

Why continue reading

A utility can regain login access while still lacking answers about the running logic, displayed data, engineering source files, credentials, remote paths, and process state. The meaningful decision is not merely whether operators can reconnect. It is whether the evidence supports trusting the environment again.

Quick Facts and Scope

• Federal agencies described an urgent and ongoing Iranian-affiliated campaign targeting internet-connected PLCs across U.S. critical infrastructure, including water and wastewater systems.
• The campaign-level record includes malicious interaction with PLC project files and manipulation of information displayed through HMI and SCADA systems.
• A limited number of affected organizations experienced operational disruption and financial loss.
• The July 2026 update expanded observed targeting to additional PLC manufacturers and added detection guidance for malicious reusable-code changes.
• Manufacturer targeting does not establish exploitation of a manufacturer product vulnerability.
• Current reporting concerning more than 30 Minnesota water and wastewater systems remains a secondary reporting layer because the underlying sector communication and complete utility-specific evidence are not public.

Material unknowns and boundaries

• The identity, number, duration, and technical impact of every affected utility.
• The initial-access path for each victim.
• Whether any specific Minnesota utility experienced a password change, IP-address change, outage, boil-water advisory, or manual operation because of the same actor or technique.
• Whether persistence remained after operator access was restored.
• Whether project files, reusable code, logic, displayed values, or network settings were compared with trusted baselines at each victim.
• Whether vendor, integrator, cellular, VPN, or engineering paths were fully reviewed.

Issue

May a utility treat restored operator login or network connectivity as restored operational trust after an unauthorized actor may have changed PLC project files, controller logic, communications settings, HMI or SCADA data, credentials, or remote-access paths?

No. Restored access demonstrates that an authorized operator can reach the environment again. It does not establish that the controller, logic, displays, identities, engineering systems, access paths, and physical-process state are trustworthy.

Rules and Authorities

• Campaign evidence: the joint federal advisory establishes the campaign-level threat, affected sectors, observed interaction with PLC project files and operator-visible data, and disruption at some victims.
• Water-sector context: EPA identifies the threat as urgent and ongoing for drinking-water and wastewater systems.
• Access-control guidance: federal and manufacturer guidance emphasizes removing direct internet exposure, changing default or weak credentials, restricting remote access, monitoring logs, and identifying exposed devices.
• Known-good validation: where project files, logic, reusable code, or communications settings may have changed, restoration requires comparison with trusted baselines and engineering verification.
• Historical comparison: the 2023 Unitronics campaign documents how unauthorized PLC access can replace ladder logic, rename devices, change ports, disable upload or download functions, and deny legitimate operator access. Those historical techniques are not silently attributed to the 2026 campaign.

Analysis

1. This is not merely a password event.

A password change is visible, but it may be only the outer edge of the incident. Project files, reusable code, controller logic, communications settings, and HMI or SCADA data can affect both what the physical process does and what operators believe it is doing. Regaining a credential does not answer whether those elements remain trustworthy.

2. Access restoration and trust restoration are different decisions.

Access restoration asks whether authorized personnel can reconnect and operate the equipment. Trust restoration asks whether the equipment, logic, displays, credentials, network paths, dependencies, and process state behave as intended and are free from known attacker influence. A utility may need to operate under constrained or manual conditions before every forensic question is closed, but that is a conscious risk decision, not proof of final restoration.

3. Operator-visible data is part of the control plane.

Manipulated HMI or SCADA values can cause operators to make physical decisions from false information. A normal-looking tank level, pressure, flow rate, pump status, or chemical-feed value may conceal abnormal process behavior. Recovery must therefore compare displayed values with independent field and process evidence.

Operational boundary: restoring the screen is not enough. The utility must establish that the screen is telling the truth.

4. Project files and engineering systems can preserve hidden risk.

Malicious changes can remain in the running controller project or be reintroduced from a compromised engineering workstation or repository. A known-good comparison should include the running state, approved engineering copy, recent change records, reusable modules, communications configuration, and vendor-supported validation methods. When no trustworthy baseline exists, that absence is itself a restoration-confidence gap.

5. Remote access is an identity and dependency problem.

Utilities may depend on integrators, vendors, cellular gateways, engineering laptops, VPNs, remote desktop tools, shared service accounts, and emergency support paths. Rotating a local PLC password does not resolve risk in the surrounding access chain. The organization must identify who and what can still reach the device and whether any path bypasses the controls applied during recovery.

6. Minnesota reporting is useful but remains bounded.

Credible secondary reporting describes a sector communication concerning more than 30 Minnesota water and wastewater systems. That reporting may identify an important cluster, but the underlying memo and complete utility-specific records are not public. The campaign-level finding therefore rests on the federal record, not on treating every Minnesota claim as confirmed.

Conclusion

After unauthorized PLC interaction, regained login or connectivity is a recovery milestone. It is not evidence that operational trust has been fully restored.

The defensible restoration decision asks what evidence shows that controller logic, project files, displays, identities, remote paths, engineering systems, and the physical process are trustworthy enough for normal operation. The public record supports that distinction with high confidence.

Relief Ordered

• Preserve controller configuration, running logic, project files, logs, device identity, firmware, communications settings, operator-display configuration, network telemetry, and engineering-workstation evidence.
• Identify the last approved project, logic, reusable modules, configuration, set points, network settings, and display configuration, with a recorded basis for trusting that baseline.
• Compare the running environment with the approved baseline and disposition every unexplained difference.
• Validate HMI and SCADA values against independent instruments, local indicators, manual readings, laboratory results, or other appropriate process evidence.
• Rotate affected credentials, eliminate defaults and shared access where feasible, review service and non-human identities, and validate vendor and integrator access.
• Review engineering workstations, repositories, jump hosts, remote-support systems, gateways, HMI servers, historians, and related systems.
• Remove direct internet exposure where operationally possible and restrict management interfaces through least-privilege, monitored access paths.
• Confirm that trained personnel, procedures, local controls, communications, safety checks, and staffing can support controlled manual operation.
• Return to service in documented stages with approval owners, rollback conditions, heightened monitoring, and explicit acceptance criteria.
• Record unresolved evidence gaps, temporary exceptions, compensating controls, owners, review dates, and expiration conditions.

Leadership questions this should trigger

• What evidence proves that the running controller state matches the approved state?
• How did we validate that operator displays reflect the physical process accurately?
• Which credentials and remote paths were exposed, rotated, disabled, or reapproved?
• Which engineering systems and repositories can modify or reintroduce controller logic?
• What remains manual, isolated, degraded, or under investigation?
• Who has authority to accept residual uncertainty and authorize each restoration stage?
• What conditions require renewed isolation or a return to manual operation?

Action Items / Meeting Close

• Operations and control engineering: define the process boundary, baseline, independent validation, and staged return-to-service criteria.
• Security and incident response: preserve evidence, review indicators, examine affected systems, and document persistence findings.
• Identity and network teams: inventory and remediate credentials, service identities, gateways, remote access, and vendor paths.
• Vendor and integrator owners: document access need, technical route, authentication, monitoring, approval, and expiration.
• Safety, laboratory, and process owners: verify physical-process indicators and define stop or rollback thresholds.
• Executive risk owner: approve residual risk, exceptions, monitoring, and closure criteria.

Meeting close: do not use “we can log in again” as shorthand for “the control environment is trustworthy.” Record the evidence, owner, exception, and acceptance decision for each restoration stage.

Verification and Acceptance Criteria

Acceptance rule: operational trust is restored only when the organization can demonstrate that the controller state, project files, reusable code, displayed values, identities, engineering systems, remote paths, process state, and residual risks meet documented acceptance criteria.

• The running controller logic and project files match an approved known-good baseline, or every difference is explained and approved.
• Reusable code, communications settings, device configuration, and exposed interfaces have been reviewed.
• HMI and SCADA values agree with independent process indicators.
• Remote, cellular, vendor, integrator, VPN, and engineering paths are inventoried and restricted.
• Credentials, service identities, sessions, secrets, and privileged access are reviewed and remediated where necessary.
• Engineering workstations and project repositories have been assessed.
• Relevant logs and indicators of compromise have been reviewed.
• Manual-operation procedures and staffing have been confirmed.
• Staged return-to-service monitoring shows no unexplained changes or abnormal process behavior.
• Residual risks and exceptions have named owners, review dates, and expiration conditions.

Residual risk

Residual uncertainty may remain because visibility into historical project versions, remote paths, credentials, upstream engineering systems, and attacker activity can be incomplete. A clean comparison at one point in time does not prove that every vendor connection, workstation, identity, or network dependency is trustworthy. Continued monitoring, configuration control, privileged-access review, and periodic comparison with approved baselines remain necessary.

Source Notes

1. CISA Joint Cybersecurity Advisory AA26-097A. Primary campaign authority for affected sectors, observed PLC interaction, operator-visible data manipulation, disruption, detection, mitigations, and attribution boundaries.
2. EPA, FBI, CISA, and NSA joint-advisory announcement, April 7, 2026. Primary water-sector statement establishing the urgent and ongoing threat posture.
3. EPA Cybersecurity Response. Primary government resource index connecting the advisory to water-sector response materials.
4. EPA, Iranian APT Actors Targeting PLCs: Impacts and Mitigations for Water and Wastewater Systems. Corroborating water-sector threat and mitigation context.
5. CISA Joint Cybersecurity Advisory AA23-335A. Historical Unitronics technique comparison only; not evidence that the same techniques occurred in every 2026 incident.

Public-record and confidence note

This article is a bounded current-incident analysis. Confidence is high for the campaign-level conclusion because federal sources describe an ongoing Iranian-affiliated threat involving internet-connected PLCs, project-file interaction, operator-visible data manipulation, and disruption at some organizations. Confidence is medium for the Minnesota reporting layer because the underlying sector communication and complete utility-specific evidence are not public. The article should be corrected or superseded if later evidence materially changes the affected-utility scope, attribution, access path, device scope, operational effects, restoration evidence, contamination claims, manufacturer-vulnerability posture, or final impact.