Why critical infrastructure is different

“Critical infrastructure” is not one sector with one rulebook. The EU NIS2 Directive’s high-criticality list covers energy, transport, banking, financial market infrastructure, health, drinking water, waste water, digital infrastructure, ICT service management, public administration and space. CISA’s advisory on Volt Typhoon focused on communications, energy, transportation systems, and water and wastewater. What these have in common is that failure harms people and other organizations, and the owner of the risk is not the only one who pays.

Operational technology changes the rules. NIST SP 800-82, its guide to OT security, frames the task as securing systems that interact with the physical world while meeting their distinct performance, reliability and safety requirements. In practice that means long equipment lives, rare maintenance windows and a stronger preference for availability and safety than for the usual IT trade-offs. The ISA/IEC 62443 series addresses this with requirements for four groups, asset owners, product suppliers, system integrators and service providers, built on shared responsibility. No single party in that chain can secure the system alone.

Five priorities at a glance

PriorityWhat is at stakeLeadership decision
Pathways from IT to OTLateral movement from business networks into control systemsWho owns the boundary, and whether every route across it is known
Edge devices and remote accessInternet-facing appliances, VPNs and end-of-life routers as the way inWhat is inventoried, patched, replaced or isolated
Dependencies beyond the fencePower, communications, vendors and peers the service relies onThe minimum operating level and the fallback for each dependency
Recovery to a safe stateReturn to a known-good, safe operating conditionWho may isolate OT, on what evidence, and what is rehearsed
Reporting and accountabilityRegulatory clocks that start while containment is under wayWho reports, from what template, and what the board sees

1. Pathways from IT to OT

The joint advisory on Volt Typhoon assessed with high confidence that the actors were pre-positioning on IT networks to enable lateral movement to OT assets and disrupt functions, with concern about disruptive or destructive action during a major crisis or conflict. It stated that the pattern of behavior was not consistent with traditional espionage. Observed activity was mostly reconnaissance, credential theft and maintaining access, with little data exfiltration, and some intrusions had lasted at least five years.

The techniques matter as much as the intent. The actors relied mainly on native tools such as PowerShell and wmic, rarely used malware, and used valid accounts for persistence, repeatedly taking Active Directory data from domain controllers and moving by RDP. The interpretation is straightforward: a detection program that waits for malware will miss this. The signal is legitimate tools used in unusual ways, by valid accounts, over a long time.

The decision is to map every route from IT to OT. That includes jump hosts, shared identity services, remote access, historians and vendor connections. Segment OT from IT and monitor the connections between them, as the advisory recommends. Treat the directory that spans both environments as a crown jewel. And name one owner for the boundary, because a boundary that belongs to IT, OT engineering and security at once tends to be maintained by nobody.

2. Edge devices and remote access

According to the same advisory, initial access typically came from exploiting public-facing appliances such as routers, VPNs and firewalls, including products from several widely deployed vendors. The actors also used end-of-life small-office routers, infected with KV Botnet malware, to proxy command-and-control traffic. Its mitigations are plain: patch internet-facing systems, plan to replace technology past manufacturer end-of-life, use phishing-resistant MFA, centralize logs, and keep credentials off edge devices.

Inventory every internet-facing appliance, including those at remote sites and installed by contractors. Decide what happens to equipment past end-of-life: replace it, or isolate it with compensating controls and an owner who accepts the residual risk. Send device logs to a central store, because an intruder who clears logs on the device removes the evidence with them. The advisory notes that the actors cleared event logs.

3. Dependencies beyond the fence

NIS2 makes top management accountable for cybersecurity risk-management measures. The harder problem is that critical services depend on each other. Water treatment needs power. Remote telemetry needs communications links. Vendor-hosted platforms and remote-support arrangements connect operators to suppliers who serve many of their peers. When several operators depend on the same product or provider, a single failure can hit them together. That is analysis, not a measured finding.

List the external services without which the operation drops below its minimum level: power, communications, fuel or parts, cloud or vendor-hosted platforms, and remote support from equipment manufacturers and managed service providers. Define the minimum operating level. For each dependency, record the alternative, the manual fallback and the contact path to the provider, the regulator and sector peers. Know in advance who you would call, and who would call you.

4. Recovery to a safe state

OT recovery is not IT recovery. The goal is a safe, known-good operating condition, not just restored servers. That calls for offline copies of controller logic and configurations, engineering workstation images, vendor tools and licenses, and network configurations, along with staff who have practiced running the process manually.

Hypothetical scenario. Ransomware encrypts the business network, and the operator cannot yet tell whether the control network is clean. Isolating OT protects it, but the site must then run manually. Staying connected preserves efficiency and gambles on an assumption nobody has verified. Who decides, on what evidence, and within what time?

Agree those criteria and that authority in advance, not on the night. Exercise manual operation for a defined period. Test restoring a known-good configuration to a representative system. Report resilience to the board in operational terms: hours the site can run manually, and hours to restore a safe state.

5. Reporting and accountability

Under NIS2, a significant incident requires an early warning within 24 hours of becoming aware, stating whether unlawful or malicious acts are suspected and whether cross-border impact is possible. An incident notification follows within 72 hours, with an initial assessment of severity and impact and indicators of compromise where available. A final report is due within one month of the notification. The clock starts while responders are still containing.

Operators outside the EU face different regimes, and many face several at once. Map every clock that applies to each site. Then protect the response team: pre-assign a regulatory liaison, pre-approve notification templates and decide who signs, so that containment staff are not drawn into paperwork in the first hours.

Decisions for leadership

  1. Name one owner of the IT/OT boundary and map every pathway across it.

  2. Treat the identity directory that spans IT and OT as a crown jewel, and require phishing-resistant MFA on remote access and administration.

  3. Inventory internet-facing devices, then replace or isolate those past end-of-life and send their logs off the device.

  4. Document the minimum operating level and the dependencies that sustain it, with fallback and contact paths for each.

  5. Decide isolation criteria and authority in advance, and rehearse manual operation and known-good restoration.

  6. Pre-stage incident reporting, with a named liaison and approved templates, so containment is not interrupted.

What to track

Five measures show whether these decisions are holding:

  • IT-to-OT pathways documented and monitored, as a share of those discovered.

  • Internet-facing devices past manufacturer end-of-life.

  • Remote-access and administrative paths using phishing-resistant MFA.

  • Hours the site can run manually, as demonstrated in an exercise.

  • Time to produce a first regulator notification in a rehearsal.

NEXT STEP

A good first exercise is to trace one critical service from the control room outward to every system, vendor and utility it needs, and to mark where the trace passes through something nobody owns.

Sources

How we label evidence

Facts carry a source. Analysis and recommendations are marked as ours. Examples that are hypothetical are labeled as hypothetical.