Cybersecurity is now part of functional safety

For most of industrial history, safety was mechanical. A door interlock that physically blocked a movement. A brake. A shear pin that broke before the shaft did. A relief valve that lifted at a set pressure because a spring said so.

None of those can be attacked from a keyboard. A relief valve has no password, no firmware and no network interface. Its safety function is a property of steel.

Most safety functions are no longer built that way.

What replaced them

The same functions now live in software and electronics: an electronic interlock driven by a safety PLC, Safe Torque Off on a drive, electronic overload and overtorque detection, computer monitoring of vibration, temperature and pressure, and safety instrumented systems for the high-consequence cases.

In most respects they are better. They diagnose themselves, they log, they can be proof-tested without dismantling anything, and they allow protection schemes far more refined than a spring ever could.

They also bring a property the mechanical devices never had: they can be reached. A safety function implemented in a computer is exposed to everything a computer is exposed to: a configuration change, a firmware downgrade, a parameter written from an engineering station, an operator account that should not exist.

Once a computer holds the safety limit, a cybersecurity failure and a safety failure become the same event.

Bremanger, April 2025

The clearest recent illustration is a small one, which is exactly why it is useful.

On 7 April 2025, intruders took control of the valve that sets the minimum water release at a dam on Lake Risevatnet, in Bremanger, western Norway. They opened it fully, and it stayed that way for about four hours before anyone noticed, adding roughly 500 litres per second to the flow. Nobody was hurt and nothing was damaged: the extra water stayed far below what the river below the dam can carry. The intrusion was reported in the summer of 2025, and in August the Norwegian Police Security Service (PST) attributed it to pro-Russian actors.

What makes it instructive is everything that was not needed. No custom industrial malware. No zero-day. No deep knowledge of hydropower. Reporting points to a weak password on a control panel reachable from the web. Someone logged in and changed a physical setting.

That is what the everyday case looks like. The engineered attacks (Stuxnet, TRITON) are real, and rare. The common version is an exposed interface, a credential, and a parameter that should never have been writable from outside.

What this changes in practice

The safety case has to consider deliberate action. A functional safety assessment asks what happens on random hardware failure and systematic design fault. It has not traditionally asked what happens when someone with valid credentials sets the limit wrong on purpose. IEC 61511 now requires a security risk assessment of the safety instrumented system and points to IEC 62443 for the security side. On most sites I know, though, the two analyses are done by different people, at different times, and nobody ever puts them side by side.

The alarm is part of the attack surface. A machine that stops is safe, and everybody on the floor can see it has stopped. What should worry an operations manager is the machine that keeps running while the screen says all is well. If monitoring and control go through the same compromised system, the display proves nothing.

Standard IT protections often do not apply. You cannot install endpoint protection on a safety PLC, and you will not be patching it on the second Tuesday of the month. Its protection has to come from the conduit around it (what can talk to it, from where, over which protocol), not from software running on it.

Changes to safety parameters need the rigour of safety changes, because that is what they are. Who can write a setpoint to a safety system, from which workstation, with what authorisation and what record, is a question for the safety management system. It should not be left to the IT change process.

The sentence worth taking away

Cybersecurity became a safety topic the day the safety limit moved from a spring into a computer. On most sites that happened years ago, and the safety case was never updated.

It is also the argument that works with people who have no interest in cybersecurity. Plant managers, EHS leads and operators rarely get excited about data breaches. Tell them a safety function can be disabled remotely and they are with you at once, because that is their subject and they already have a process for it.

References

• heise online, Cyberattack: Attackers open dam valves, 2 July 2025: valve, flow and duration of the Risevatnet incident.
• BleepingComputer, Pro-Russian hackers blamed for water dam sabotage in Norway, 14 August 2025: attribution by PST.
• IEC, IEC 61511-1:2016, Functional safety: Safety instrumented systems for the process industry sector, Part 1, clause 8.2.4 on the SIS security risk assessment.