Skip to content
HACKTECH

For utilities, renewable and grid operators, oil and gas, water, manufacturers and makers of industrial equipment

Security testing for energy and industrial operators

In energy and manufacturing a breach can move physical equipment, so the test plan starts from safety. We assess the path from the office network or a supplier's remote access into operational technology, the exposure of controllers and HMIs, and the separation between IT and OT, using passive methods wherever live process equipment is involved.

What an attacker wants from energy and industrial operators

An attacker usually starts in ordinary IT, then either reaches operations because the networks were never really separated, or the business stops production itself because it can no longer trust what its systems show. Both end in stopped production, counted in lost output, safety reviews and missed contracts. Controllers exposed to the internet add a more direct risk: an attacker who can change the logic in a programmable controller is changing the physical process it runs.

How energy and industrial operators are attacked

  • Internet-exposed controllers on default passwords

    CISA advisory AA23-335A (opens in a new tab), issued with partner agencies including Israel's, described attackers logging in to internet-exposed controllers made in Israel that had default passwords or none, then replacing their logic and defacing their HMI screens. The pattern is not limited to one manufacturer, and search engines that index internet-connected devices make such controllers easy to find.

  • Ransomware in IT that stops OT

    Ransomware encrypts business systems, and operations stop either because they depend on them (scheduling, historians, billing) or because nobody can confirm the OT network is clean. Separation that exists on a diagram but not in the firewall rules makes the second case likely.

  • Vendor and integrator remote access

    Equipment makers and integrators often keep remote access into plants for support, sometimes through tools installed years ago and forgotten. Each connection is a path around the perimeter, and an attacker who compromises the vendor inherits all of them.

  • Engineering workstations and shared credentials

    The workstation that programs controllers is the most valuable machine on an OT network. Shared accounts, old operating systems and project files moved by USB stick or email make it a soft target.

  • Industrial protocols without authentication

    Modbus, and many deployments of DNP3 and vendor protocols, carry commands with no authentication because they were designed for closed networks. Anyone who reaches the segment can read or write values unless something in between stops them.

  • Cloud-connected equipment

    Inverters, meters, chargers and connected machines report to vendor clouds and accept commands from them. A flaw in that cloud, or in the device's update mechanism, reaches every installed unit at once.

Frameworks that shape a test for energy and industrial operators

Energy (electricity, district heating and cooling, oil, gas and hydrogen) is among NIS2's sectors of high criticality, and the manufacture of machinery, electronics and vehicles is among its other critical sectors, with a 24-hour early warning and a 72-hour notification for significant incidents. If you make connected industrial products for the EU market, the Cyber Resilience Act's reporting obligations have applied since 11 September 2026 and its main obligations apply from 11 December 2027. For the OT itself, the IEC 62443 series is the common reference for zones, conduits and security levels, and a test is the evidence that the zones you drew are the zones you have.

What we test for energy and industrial operators

The scoping call settles which of these apply to your systems.

  • Internet exposure of OT: controllers, HMIs, remote terminal units and gateways reachable from the internet, found with the same search engines attackers use
  • IT to OT separation: firewall rules and routes between corporate, DMZ and control networks, tested from a compromised office workstation
  • Remote access into plants: vendor and integrator connections, jump hosts and remote support tools, and whether sessions are approved, recorded and time-limited
  • Engineering workstations and historians: patch levels, shared accounts, project file handling, and what an attacker on them could change
  • Industrial protocol exposure: which segments can send Modbus, DNP3, OPC UA or vendor commands, confirmed passively before anything active is attempted
  • Active Directory shared between IT and OT: trusts and accounts that let an IT compromise reach control systems
  • Connected products: device firmware, update signing, and the vendor cloud that manages the fleet and the commands it can send
  • Recovery: offline copies of controller logic and configuration, and whether a site could rebuild without the network it lost

Services we scope for energy and industrial operators

  • Internal and external network testing, including Active Directory. Where scope allows we go from an unauthenticated foothold to domain-wide impact and document the whole chain: the exposed service or sprayed credential that got us in, each privilege escalation on the way, and the accounts and hosts it reached.

    Duration: 5 to 12 working days

  • Objective-based adversary simulation: we agree the objectives, try to reach them over several weeks and measure what your detection and response do along the way. Purple mode runs the same scenarios with your defenders in the room, tuning detection as each technique is replayed.

    Duration: 3 to 6 weeks

  • An IAM-first review of AWS, Azure or GCP. We map what an attacker reaches after compromising one workload or one developer laptop, then rank those paths by the data at the end of each and write the Terraform or policy change that cuts it.

    Duration: 4 to 8 working days

  • Facilitated workshops that map how a system or feature could be attacked before it is built or shipped. We draw the data flows with your engineers, walk them with STRIDE, rank the threats by likelihood and impact, and turn the result into backlog items and test cases your team owns.

    Duration: 2 to 5 days per system, remote or on site

  • Hands-on help when an attacker is already inside: triage on the first call, containment that does not destroy evidence, forensic scoping of what was touched, and recovery that we verify before calling it complete. Outside a crisis we run retainers, tabletop exercises and compromise assessments, so your team has practised the first hour before it happens.

    Duration: Live incidents until recovery is verified; readiness work in days

Closest written-up engagement

Removing anonymous control access from clinical devices

Healthcare IoT · Under two weeks

Hospital customers were reporting device API instability. The cause was not load.

  • Cloud
  • Device firmware
  • Management API
Read the redacted write-up

Questions about testing energy and industrial operators

Will active scanning disrupt our control systems?

It can, which is why OT work starts passively: architecture review, firewall rule analysis and traffic captures from span ports. Active testing happens only on systems you approve, in agreed windows and preferably against a spare or a test rig, with your operations staff able to stop it at any moment.

Can you test our equipment before it ships to customers?

Yes. A product test covers the firmware, its update and signing process, local and network interfaces, default credentials, the companion app and the cloud service that manages installed units. Findings are written so your engineers can fix them and your customers' security teams can read the result.

We already test our IT. Why scope OT separately?

Because the assumptions differ. In IT a patch or a scan is routine; in OT the safe answer may be to isolate rather than patch, and the test has to respect that. Scoping OT on its own also forces the question that decides how bad an incident gets: whether an attacker in IT can reach the control network at all.

Turn the checklist into a written scope

We pick the checks that apply to your systems and the frameworks you answer to. A 45-minute scoping call ends with a fixed quote and a proposed start date; the written scope follows by email.