Energy and Utilities Cyber Security

Energy and utilities cybersecurity: protect safe, reliable operation

Energy and utility security starts with the safety and continuity of the service being delivered. Cyber incidents can affect physical processes, operational visibility, engineering work and business systems. The right assessment must respect those consequences.

Treat IT, operational technology (OT), engineering and suppliers as connected responsibilities. Identify who owns each operational decision before selecting tests or changing a control.

Reviewed: 26 October 2026.

Understand the operation and its connections

Map the essential process, supporting assets, control and monitoring paths, remote access, data exchange and supplier dependencies. Include less visible connections such as engineering laptops, historians, maintenance tools and cloud services. Record which systems are safety-related and the approved operating limits.

NCSC’s OT guidance covers architecture, connectivity and third-party risks. Use it to improve a maintained understanding of the environment, not just produce a diagram for an assessment.

Prioritise risks by operational consequence

Do not blindly apply office-IT controls or update schedules to production OT. The risk of a change, the risk of delaying it and compensating safeguards need joint engineering, safety and security consideration. This is not a reason to leave exposure undocumented.

Apply controls according to the operational consequence

Know the assets, functions and support constraints

Record the physical process, supporting controllers and monitoring systems, engineering workstations, communications, remote access and dependencies on enterprise services. Include remote sites, temporary connections and supplier equipment. For each relevant asset, identify its purpose, owner, supported version, configuration source and recovery requirements.

Confirm that diagrams describe the real operating environment. Use approved information sources and observation methods before considering active discovery. A device that rarely changes can still become exposed when a gateway, remote support route or shared identity service changes.

Reduce exposure and govern connections

Identify the information and administration that must pass between enterprise IT, suppliers and operational zones. Authorise those flows for a defined purpose and use appropriate controlled paths. Record who can approve, review and remove them. Do not assume a label such as “air-gapped” describes all temporary or indirect connectivity.

The NCSC secure connectivity principles address exposure, controlled boundaries, monitoring and isolation planning. Use them to question the design, with engineering input on safe operation. Changes require validation for the particular process; network segmentation is not achieved simply by drawing zones.

Manage patching and protection with engineering

Track vulnerabilities and vendor guidance against the actual assets and their role. Plan approved maintenance, compatibility checks, recovery material and rollback. When immediate remediation is not feasible, document the constraint, restrict exposure where suitable, monitor the relevant risk and set a review and replacement/remediation plan.

Endpoint agents, application controls, encryption or scanning may be useful where supported, but their suitability cannot be assumed for every controller or operational device. Assess performance, protocol, safety and vendor constraints. Business approval of a delay does not remove a legal or contractual requirement.

Plan for cryptography across long equipment lifetimes. Identify where certificates, encrypted connections and signed software or firmware support the operational service. Ask suppliers about support periods, key and certificate replacement, and their migration plans for post-quantum cryptography. Include these dependencies in procurement and replacement planning.

NCSC guidance sets a target of 2028 for discovery, assessment and an initial migration plan. Treat this as a planning activity with engineering and suppliers, not an instruction to change live controllers immediately. Validate compatibility, performance and recovery before deployment; a new algorithm alone does not establish that the complete operational service is secure.

Further guidance: NCSC: Timelines for migration to post-quantum cryptography.

Make monitoring useful to operators and responders

Choose signals that help identify consequential change: new remote access, unexpected engineering activity, altered configurations or failed boundary controls. Correlate technical events with approved maintenance and operational context before deciding what to do.

Agree who investigates and who may isolate a connection or affected system. Protect relevant logs and time information, and test that events reach the responsible team using approved, non-disruptive methods. An alert that nobody can interpret or act upon offers limited protection.

Choose safe assessment methods

Intrusive scanning or exploitation is not a universal starting point for OT. Define excluded systems and actions, involve manufacturers where necessary and identify who can stop work. A claim of complete coverage is inappropriate where safety constraints prevent testing.

Control supplier access and shared dependencies

Record each remote support route, the systems it reaches, who authorises its use and how access ends. Check identity, session logging and emergency arrangements without assuming every vendor can support the same technology.

Understand subcontractors, common infrastructure and concentrations. Ask how the supplier will help investigate, isolate and recover the service, and what evidence or configuration exports you can obtain. Test contact and escalation routes before an incident.

Use frameworks and regulation within their scope

The NCSC Cyber Assessment Framework groups outcomes around managing risk, protecting systems, detecting events and minimising incident impact. It can structure evidence and improvement discussions. It is not a universal certification or, by itself, a statement that an organisation meets all legal duties. NCSC CAF guidance.

UK network and information systems obligations depend on the relevant service, operator status and competent authority. Energy and water organisations, suppliers and overseas operations may have different requirements. Confirm the applicable regime and current regulator guidance rather than describing every business in the sector as identically regulated.

Map each applicable obligation to an owner and evidence. Keep the safety case, operational risk decisions and cyber assessment aligned, while recognising that they answer different questions.

Address supplier, cloud and human risks across IT and OT

A supplier may support both an ordinary business service and a critical operational component. Record those roles separately: privileges, remote entry routes, approved users, subcontractors, support windows and the effect of losing the service. A standard supplier questionnaire does not show whether a particular engineering session is controlled.

• Require an identifiable owner and approval route for remote support. Limit duration and reach where feasible, observe relevant activity and confirm revocation after work or contract termination.
• Review cloud-hosted monitoring, analytics and management dependencies. Establish who controls identities, permissions, configuration, logs, data export and recovery; include the effect of a provider or connectivity outage.
• Verify consequential requests independently, including changes to supplier accounts or operational access. A plausible email, voice or video instruction should not bypass the normal authority chain.
• Treat alleged leaked credentials or hostile activity reports as evidence to assess. Use controlled specialist channels and examine local exposure rather than assuming every threat report proves intrusion.
• Apply access decisions to the relevant identity, device, resource and action; do not grant blanket trust because a connection originates inside the corporate network.

Prioritise credible disruption, unauthorised change and loss of operational visibility. Long-term espionage, ransomware and accidental configuration changes can require different investigation paths but may expose the same weak identity or remote-access boundary. Threat labels should guide planning rather than replace understanding of the process.

Plan isolation and recovery with operations

An illustrative scenario is the loss of a remote monitoring connection during suspected compromise. Operations need to know which functions remain safe, whether local control is available and who can approve isolation. Security needs to preserve evidence and determine whether the connection is the only affected path.

Before restoration, validate configurations, access, process visibility and dependencies with the relevant owners. Reconnecting a device is not the same as restoring safe operation. Record unresolved risks and monitor the resumed service.

Rehearse isolation and recovery before an emergency

Prepare an approved isolation plan with operations and engineering. Record the intended effect of restricting each important connection, dependencies that must remain available, decision authority and the criteria for safe return. Do not wait for an incident to discover that an apparently optional IT service supports an operational function.

1. Choose a plausible scenario such as a compromised remote-support identity or loss of an engineering workstation. Start with a tabletop exercise or representative test environment where live activity would create unacceptable risk.
2. Confirm trusted communications between the control room, engineering, IT/security, management and suppliers. Test who can make urgent decisions if the usual approver is unavailable.
3. Check access to validated configurations, software, credentials, keys and appropriate replacement equipment. Protect recovery material from the same compromise affecting production.
4. Plan restoration order according to the process and its dependencies. Verify configuration, communications and operational behaviour with the responsible engineers.
5. Record the authority for reconnection, additional monitoring and any remaining restrictions. Revisit the plan after important architecture, supplier or process changes.

A technically successful rebuild is not sufficient evidence that a physical process is safe to resume. Keep safety and operating decisions with the authorised personnel, and capture the evidence and unresolved assumptions from the exercise. Use the findings to improve both cyber response and business continuity.

Common questions

Should we scan every OT asset?

No universal scanning method is safe for every environment. Start with the operational risk, asset characteristics and approved assessment plan; use laboratory or passive approaches where appropriate.

Can IT security own OT risk alone?

No. Technical expertise must be combined with operational, engineering and safety authority. Assign decisions explicitly.

What is a useful first step?

Choose an important process and establish an accurate view of assets, connections, remote access, recovery dependencies and owners. Use that evidence to prioritise safe improvements.

Prepare a proportionate assessment

Provide architecture, asset/support information, supplier access, safety constraints, maintenance opportunities and previous findings. ProCheckUp can help scope relevant reviews and tests with operational stakeholders. See configuration review, penetration testing and maturity assessment.

Energy and utilities assessment options.