Energy and utilities: where a security control can be a safety hazard

In an office network, a security control that causes an outage is embarrassing. On a grid, a pipeline or a water treatment plant, it can be a safety event. That single difference reverses many of the assumptions IT security is built on, and it is why energy and utilities programmes cannot simply extend the corporate control set into the plant.

The inverted priorities

IT security optimises for confidentiality, then integrity, then availability. Operational technology inverts it: safety first, then availability, then integrity, with confidentiality last. Nobody is much troubled by an attacker reading a pressure reading; everyone is troubled by one changing it, and by a control that stops the operator seeing it at all.

Practical consequences that surprise IT practitioners:

• You may not be able to patch. Availability requirements and vendor certification mean patching windows arrive once or twice a year, and applying an uncertified patch can void the vendor's safety validation.
• You may not be able to scan. Active scanning has knocked over fragile industrial devices. Passive network monitoring is the standard alternative, and it is a genuinely different discipline.
• Equipment lifespans run to decades. Devices designed before network security existed, with no authentication in the protocol, cannot be upgraded - only compensated for.
• Account controls work differently. A control room operator cannot re-authenticate during an incident; shared, always-logged-in consoles exist for sound operational reasons and need compensating controls rather than removal.
• Safety instrumented systems are the last line of physical protection and are typically kept separate from everything, including your security tooling.

The regulatory load

Utilities usually sit under several regimes at once, which is itself the compliance problem. Depending on where you operate, expect some combination of:

• Critical infrastructure legislation imposing risk management, incident reporting and, increasingly, management accountability - NIS2 in the EU, sector regulators elsewhere, and national schemes in the Gulf.
• Sector-specific technical standards - IEC 62443 for industrial automation, with regional equivalents for grid operators.
• Incident reporting duties with short clocks, often shorter than general data protection timelines and running to a different regulator.
• Supply chain obligations covering equipment vendors and maintenance contractors.
• General data protection law for the customer side of the business, which behaves like any other utility retailer.

Build one control set mapped to every applicable regime rather than a programme per regulator. Utilities that run parallel programmes end up evidencing the same segmentation control three times in three formats.

Zones, conduits and the IT/OT boundary

IEC 62443 organises the environment into zones of similar security requirements, connected by defined conduits where traffic is controlled and monitored. It is network segmentation with a vocabulary suited to plant engineers, and it is the right structuring concept for the whole programme.

The boundary between corporate IT and operations is where attention belongs, because it is where real incidents propagate. What matters there:

• A controlled path - historically a demilitarised zone, increasingly with unidirectional gateways where data only needs to flow outward.
• No direct routing from corporate to control networks, and no shared identity domain that lets a phished office credential reach a plant.
• Remote vendor access brokered, time-limited, supervised and recorded. Standing vendor VPN access is among the most common serious findings in the sector.
• Removable media control, which remains a genuine infection route in air-gapped environments.
• Monitoring at the conduit, since you often cannot instrument the devices themselves.

Note the pattern in publicly reported incidents: attackers frequently entered through IT - phishing, remote access, a supplier - and reached operations because the boundary was weaker than assumed. Several disruptive events involved no compromise of control systems at all; operations were suspended because the operator could not distinguish what was affected.

Making a programme work here

1. Inventory first, and expect it to hurt. Passive discovery usually finds devices nobody documented and connections nobody authorised.
2. Engineering owns the risk decisions. Security proposes; the people accountable for safe operation decide. A control imposed over engineering objection will be worked around.
3. Compensate where you cannot remediate. An unpatchable controller behind a monitored conduit with strict access control is a defensible position - document it as an accepted risk with the compensating controls named.
4. Use maintenance outages. Planned shutdowns are your patching and upgrade windows; security work must be in the outage plan months ahead or it waits a year.
5. Exercise the scenario that actually happens - an IT compromise forcing an operational decision under uncertainty, with the regulator to notify and a public to inform.

Key takeaways

• Safety and availability outrank confidentiality - IT practice transplanted directly will be rejected.
• The IT/OT boundary is where real incidents propagate; vendor remote access is a recurring weak point.
• Compensate what you cannot patch, and document it as an accepted risk.
• Map one control set to every regime instead of running a programme per regulator.