Executive Summary
The July 30, 2026 U.S. warning on water-sector PLC attacks is a timely reminder that cyber risk can cross into physical operations when operational technology is reachable and changeable. [1] Critical-infrastructure resilience therefore needs more than perimeter defense. It requires an operating model that connects essential-service ownership, asset visibility, secure connectivity, privilege, segmentation, operational monitoring, isolation, recovery, third parties, and executive governance.
CyberTech Intelligence Perspective
CyberTech Intelligence defines critical-infrastructure cyber resilience as the ability to preserve the safe delivery of an essential service when a digital path becomes untrusted. The organization should know what matters, reduce avoidable exposure, control access, observe material change, isolate the affected path, sustain the minimum safe service, rebuild trust, and record the decision to return.
Evidence Base for the Framework
Current guidance supports this systems view. [2] The April 2026 zero-trust guidance adapts security principles to OT constraints and emphasizes shared accountability, safety, remote-access risk, procurement, and compensating controls. [3]
Why Network-Only Security Breaks at Scale
A firewall cannot explain whether a changed controller still reflects the approved process. A strong identity control cannot keep a service running if the only remote-management path is disconnected and no local procedure exists. Monitoring cannot restore a trusted configuration if backups are stale. The control system must be designed as a sequence of mutually reinforcing operational capabilities.
From Cyber Controls to an Operational Resilience System
A resilience system separates normal connectivity from emergency operating modes. In normal conditions, external access is justified, attributable, limited, and observed. Under heightened threat or incident conditions, teams can progressively isolate vital systems, preserve evidence, operate locally or manually, and restore from known-good states. Governance sets the thresholds for those transitions.
Eight Operating Layers and Seven Control Questions
Seven questions make the framework executable: Which essential service must continue? Which assets and dependencies enable it? Which external or privileged paths can change it? What evidence reveals unauthorized change? Where can the path be isolated? How does the service continue while isolated? What evidence proves the service is ready to return?
1. Essential Service, Impact, and Safe State
Define the service, critical customers, safety or environmental consequence, minimum safe state, maximum tolerable disruption, regulatory obligations, and accountable owner. The risk tier should reflect operational consequence, not the age or brand of the technology.
2. Asset and Dependency Visibility
Maintain a current view of controllers, HMIs, engineering stations, network infrastructure, remote-access systems, vendors, identities, communications, cloud dependencies, safety functions, and recovery sources. Visibility should support both incident response and architecture decisions.
3. Connectivity, Identity, and Privilege
Treat connectivity as a controlled business capability. Secure-connectivity guidance recommends careful design of OT connections in environments where safety and uptime are primary. [2] Remote and third-party access should be attributable, purpose-limited, monitored, and revocable, with compensating controls for legacy devices.
4. Segmentation and Isolation
Segment according to process function and trust. Then test the design under operational conditions. Zero-trust guidance for OT recognizes that network segmentation and other compensating controls may be necessary where conventional mechanisms are impractical or disruptive. [3] The important measure is whether the boundary can be used safely during a real incident.
5. Observability and Change Integrity
Detect changes that matter to the process: new connections, altered configurations, privileged access, project-file changes, unexpected protocols, or changes to engineering logic. NERC CIP-010-4 illustrates the importance of configuration change management and vulnerability assessment in a regulated electric-sector context. [6]
6. Recovery and Controlled Return
Recovery requires trusted sources and an explicit decision sequence. Restore configurations and credentials, validate communications and process behavior, reconnect dependencies in stages, monitor the service, and retain a rollback path. The return decision belongs to both cyber and operations leadership.
7. Third Parties and Supply Chain
Vendors often provide legitimate engineering support, managed communications, remote maintenance, or common architectures across sites. That means supplier access and shared design patterns are part of the operational attack surface. Contracts should define access, logging, incident notification, evidence preservation, software or configuration changes, and recovery participation.
8. Governance and Continuous Validation
Governance should reconcile cyber, safety, reliability, legal, compliance, engineering, and operational priorities. These are useful inputs, but neither proves a local control is effective until it is tested in the organization’s environment. [4] [5]
Operational Scenario Testing
Test scenarios that cross digital and physical boundaries: a public-facing controller is changed; a vendor credential is misused; a remote-access gateway is unavailable; an engineering workstation becomes untrusted; an OT zone must be isolated; central monitoring is lost; a controller configuration must be restored; or a third-party architecture issue appears across multiple sites. Each exercise should produce evidence, owners, due dates, and a retest decision.
Strategic Roadmap for Maturity
First, establish essential-service ownership and visibility. Second, remove avoidable exposure and standardize remote-access patterns. Third, implement segmentation and isolation plans. Fourth, strengthen monitoring and trusted configuration management. Fifth, exercise manual operation and recovery. Finally, make test results and exception aging part of recurring executive investment decisions.
Executive Recommendations and Conclusion
Start with a bounded set of high-consequence services. Trace the complete path from external connectivity to operational outcome and recovery. Fund the controls that change the consequence of an attack: fewer reachable paths, stronger access boundaries, tested isolation, trusted configurations, manual continuity, and accountable return-to-service decisions. A critical-infrastructure cyber program is mature when leaders can explain how the service continues when the network cannot be trusted.
Standards and Threat Mapping
The framework is informed by current secure-connectivity and zero-trust guidance for OT, ISA/IEC 62443 context, MITRE ATT&CK for ICS data, and NERC configuration-management requirements. These sources serve different purposes: architecture guidance, governance, threat modeling, and regulated control requirements. None is treated as a certification of another organization’s environment. [2] [3] [4] [5] [6]
Visual Decision Architecture
The following decision models convert the campaign thesis into a repeatable sequence for executive review, operational containment, continuity, recovery, and governance. They are CyberTech Intelligence synthesis tools, not claims that every incident follows the same path.
Critical Infrastructure Cyber Attack Path
Figure 1. Critical Infrastructure Cyber Attack Path - From Reachable OT to Verified Recovery
|
Stage |
Operational Meaning |
|
1. Find a reachable path |
An internet-facing OT device, remote-access service, vendor connection, or weakly protected pathway makes operational technology reachable. |
|
2. Gain operational access |
The actor reaches a device or supporting system with enough access to view, change, or disrupt operations. |
|
3. Change trusted state |
Passwords, addresses, configurations, project files, logic, or other trusted settings are changed or misused. |
|
4. Degrade visibility or control |
Operators lose monitoring, control, or confidence and must determine what remains safe to operate. |
|
5. Protect the essential service |
Teams isolate the affected path, preserve evidence, and use approved manual or fallback procedures. |
|
6. Restore and validate |
Teams restore known-good settings and access, verify changes, strengthen monitoring, and stage normal operations. |
Operational Isolation and Recovery Decision Workflow
Figure 2. Operational Isolation and Recovery Decision Workflow
|
Decision Step |
Required Outcome |
|
1. Define the essential service |
Confirm the service, minimum safe state, dependencies, and accountable incident authority. |
|
2. Isolate the risky path |
Separate affected OT and enabling systems at preplanned isolation points without unnecessary service loss. |
|
3. Preserve evidence |
Retain configurations, access logs, network records, change history, vendor activity, and operator observations. |
|
4. Sustain operations |
Use approved manual operations, local control, alternate communications, or other continuity procedures. |
|
5. Restore trust |
Restore known-good configurations, rotate credentials, validate communications and logic, and reconnect in stages. |
|
6. Improve the system |
Close root causes, update architecture and procedures, assign owners, and retest response and recovery. |
Critical Infrastructure Cyber Resilience Maturity Model
Figure 3. Critical Infrastructure Cyber Resilience Maturity Model
|
Maturity |
Operating Pattern |
Leadership Priority |
|
Reactive |
Exposure and recovery dependencies emerge during an incident. |
Identify vital services, exposed assets, owners, and isolation options. |
|
Defined |
Policies exist, but IT, OT, vendors, and continuity remain separate. |
Standardize inventory, access, segmentation, monitoring, response, and recovery. |
|
Connected |
Cyber, operations, engineering, safety, vendors, and executives share evidence. |
Use one resilience model around essential-service outcomes. |
|
Measured |
Exposure, access, isolation, recovery tests, and exceptions are measured by service. |
Prioritize investment using operational impact and tested evidence. |
|
Adaptive |
Controls evolve from incidents, exercises, architecture changes, and threat intelligence. |
Scale proven patterns and retest assumptions as dependencies change. |
Governance and Decision Rights
Figure 4. Critical Infrastructure Cyber Resilience Governance Framework
|
Decision Stage |
Accountable Owner |
Required Evidence |
Exit Criteria |
|
Critical-Service Scope |
Business / Operations Owner |
Essential service, safe state, dependencies, impact tolerance, and fallback method. |
Service priority and continuity requirements approved. |
|
Architecture and Access |
OT / Engineering / Security |
Asset inventory, exposure, remote access, identities, segmentation, vendors, and change controls. |
Material paths are owned and constrained. |
|
Detection and Response |
CISO / Incident Commander |
OT telemetry, network records, change events, escalation criteria, isolation, and communications. |
Detection, escalation, and containment tested. |
|
Continuity and Recovery |
Operations / Engineering Owner |
Manual operations, backups, known-good configurations, recovery sequence, validation, and rollback. |
Return-to-service evidence and authority recorded. |
|
Improvement and Investment |
Executive Risk Committee |
Exercises, incidents, exceptions, corrective actions, regulatory duties, and investments. |
Actions are funded, owned, and closed with evidence. |
CyberTech Intelligence Critical Infrastructure Cyber Resilience Framework™
Eight operating layers connect essential-service purpose to reduced exposure, controlled access, observable operations, reliable isolation, trusted recovery, and evidence-led governance.
Figure 5. CyberTech Intelligence Critical Infrastructure Cyber Resilience Framework™ - Eight-Layer Architecture
|
Layer |
Name |
Operating Requirement |
|
01 |
Know |
Identify essential services, OT assets, owners, dependencies, remote connections, vendors, and minimum safe states. |
|
02 |
Reduce Exposure |
Remove unnecessary internet exposure, retire unused pathways, secure gateways, and eliminate insecure defaults. |
|
03 |
Control Access |
Use named identities, strong authentication where feasible, least privilege, time-limited vendor access, and rapid revocation. |
|
04 |
Segment |
Separate business IT, OT zones, safety functions, remote-access paths, and management networks by operational need. |
|
05 |
Observe |
Monitor access, configuration change, network behavior, privileged actions, and service conditions for reconstruction. |
|
06 |
Isolate |
Predefine and test graduated isolation so teams can contain a cyber path without improvising. |
|
07 |
Recover |
Maintain tested backups and known-good configurations, manual alternatives, integrity checks, and staged restoration. |
|
08 |
Govern |
Align cyber, operations, engineering, safety, legal, compliance, vendors, and executives around service continuity. |
Critical Infrastructure Cyber Resilience Readiness Score™
Table. Critical Infrastructure Cyber Resilience Readiness Score™
|
Domain |
Executive Assessment Question |
Ready-State Evidence |
|
Asset Visibility |
Can leaders identify OT assets and support systems for each essential service? |
Current inventory, owner, function, criticality, version, dependencies, and review evidence. |
|
Internet Exposure |
Are public-facing OT devices and services known, justified, and minimized? |
Exposure inventory, approved exceptions, secure gateways, rules, and recurring verification. |
|
Remote Access |
Is every remote-access path attributable, approved, monitored, and revocable? |
Named accounts, approved methods, strong authentication where feasible, limits, logs, and revocation tests. |
|
Network Segmentation |
Can compromise in business IT or one OT zone be contained? |
Documented zones, conduits, access rules, third-party paths, diagrams, and isolation tests. |
|
Identity and Privilege |
Do users, services, and vendors have only required operational access? |
Role-based access, unique credentials, privileged controls, reviews, and termination procedures. |
|
OT Monitoring |
Can teams detect and reconstruct unauthorized access or configuration change? |
Network telemetry, device-change records, time synchronization, retention, alerts, and investigation procedures. |
|
Response and Isolation |
Can teams isolate an affected path without unmanaged operational risk? |
Graduated isolation plan, decision rights, test evidence, alternate communications, and preserved forensic data. |
|
Manual Operations and Continuity |
Can essential service continue if remote connectivity or central monitoring is unavailable? |
Manual/local procedures, trained operators, dependency map, alternate communications, and exercises. |
|
Backup and Recovery |
Are configurations, logic, and support data recoverable from trusted copies? |
Versioned backups, change integration, restore tests, known-good baselines, validation, and rollback. |
|
Third-Party Access |
Are vendor connections and shared support paths governed as operational exposure? |
Vendor inventory, contract controls, access windows, monitoring, notification, and offboarding evidence. |
|
Executive Governance |
Are operational cyber risks, exceptions, exercises, duties, and investments owned? |
Risk register, service metrics, exception aging, exercises, corrective-action closure, and executive decisions. |
How to Calculate the Score
Rate each domain from 0 to 4: 0 = absent; 1 = informal; 2 = documented; 3 = implemented and tested; 4 = measured and continuously improved. The maximum is 44 points. Divide the total by 44 and multiply by 100. Suggested bands are Critical (0-24%), Developing (25-49%), Defined (50-69%), Managed (70-84%), and Adaptive (85-100%). The score is an internal readiness aid. It is not a certification, a statement of compliance, or a prediction of incident likelihood.
Continue the Critical Infrastructure Cyber Resilience Journey
Use this asset to review one essential service end to end. Confirm the service owner, vital OT assets, exposed and remote-access paths, identities, segmentation, monitoring, isolation choices, manual operating method, backup and recovery evidence, vendor dependencies, and executive risk decision. CyberTech Intelligence can support a facilitated executive resilience assessment or working session built around organization-specific evidence.
Continue the Cyber Resilience Journey
Move From Framework to Execution. Schedule a Critical Infrastructure Resilience Working Session to Map Priorities, Ownership, Response Decisions, and Recovery Requirements.
About CyberTech Intelligence
CyberTech Intelligence provides research-led cybersecurity intelligence, executive content, and market engagement programs. This publication is vendor-neutral and intended for education and decision support.
Research and Citation Governance
This asset uses public sources current through August 21, 2026. Incident statements are limited to what the cited organizations published within their stated scope. CyberTech Intelligence does not infer local exposure, customer impact, actor identity where authorities have not attributed an incident, control effectiveness, or incident probability without organization-specific evidence. Framework and scorecard content are CyberTech Intelligence analysis and are presented as decision aids rather than external proof points.
References
[1] FBI Internet Crime Complaint Center, “2026 Public Service Announcements,” accessed August 21, 2026. https://www.ic3.gov/PSA Accessed August 21, 2026. Relevance: Lists the July 30, 2026 public warning about attacks against internet-facing water-sector PLCs.
[2] International cybersecurity partners, “Secure Connectivity Principles for Operational Technology (OT),” January 14, 2026. https://www.ic3.gov/CSA/2026/260114.pdf Accessed August 21, 2026. Relevance: Explains secure-connectivity principles for OT with emphasis on safety, uptime, operational continuity, remote access, and third-party connectivity.
[3] CISA, Department of War, DOE, FBI, and Department of State, “Adapting Zero Trust Principles to Operational Technology,” April 29, 2026. https://www.ic3.gov/CSA/2026/260429.pdf Accessed August 21, 2026. Relevance: Adapts zero-trust principles to OT while recognizing safety, availability, legacy, remote-access, and break-glass constraints.
[4] International Society of Automation, “Advancing Industrial Cybersecurity,” 2023. https://www.isa.org/getmedia/1d25e9c7-15b0-4397-b4ee-d034f6611d5e/ISA-Position-paper-Advancing-Industrial-Cybersecurity.pdf Accessed August 21, 2026. Relevance: Explains the role of ISA/IEC 62443 as a flexible framework for industrial automation and control-system cybersecurity.
[5] MITRE, “ATT&CK Data & Tools - ICS dataset,” accessed August 21, 2026. https://attack.mitre.org/resources/attack-data-and-tools/ Accessed August 21, 2026. Relevance: Provides the current ATT&CK for ICS datasets for behavior-based threat modeling and defensive planning.
[6] North American Electric Reliability Corporation, “CIP-010-4: Configuration Change Management and Vulnerability Assessments,” modified November 25, 2025. https://www.nerc.com/standards/reliability-standards/cip/cip-010-4 Accessed August 21, 2026. Relevance: Defines requirements intended to prevent and detect unauthorized changes to Bulk Electric System cyber systems.